From waldi@debian.org Tue Feb 1 00:21:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 00:21:50 -0800 (PST) Received: from wavehammer.waldi.eu.org (postfix@wavehammer.waldi.eu.org [82.139.196.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j118LgLa010982 for ; Tue, 1 Feb 2005 00:21:43 -0800 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id B5C1E3C02A; Tue, 1 Feb 2005 09:21:39 +0100 (CET) Date: Tue, 1 Feb 2005 09:21:39 +0100 From: Bastian Blank To: linux-kernel@vger.kernel.org, pavlic@de.ibm.com Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: [RFC] device types for s390 network devices Message-ID: <20050201082139.GB31992@wavehammer.waldi.eu.org> Mail-Followup-To: linux-kernel@vger.kernel.org, pavlic@de.ibm.com, netdev@oss.sgi.com, davem@davemloft.net Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: waldi@debian.org Precedence: bulk X-list: netdev --H1spWtNR+x+ondvy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The s390 network devices specifies device types which does not match the reality. ctc =3D=3D=3D This device is currently specified as ARPHRD_SLIP. If I see it correctly, SLIP is an IP-only transport. ctc is more, the link level header contains the ethernet protocoll type, so it is some sort of pointopoint ethernet (which is sometimes crippled to IPv4-only for compatiblity reasons). qeth =3D=3D=3D=3D This device is currently specified as the corresponding real device type if it is a real adapter, or ARPHRD_ETHER if it is a virtual one. The virtual device behaves different in different modi: - "layer2": In this mode, the device behaves like a real layer 2 device. - "fake_ll": The kernel prepends a faked link level header. - default: The kernel processes the IP-packages. This is the most used mode, in whom it is impossible to use a standard libpcap as it parses the IP-headers as Ethernet. (IBM suggests to patch libpcap, but I think that changing the device type to something more matching is the correct solution.) At least the last part needs some fix, but I don't know how to fix if properly. Bastian --=20 The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8 --H1spWtNR+x+ondvy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iEYEARECAAYFAkH/PBMACgkQnw66O/MvCNF2kACfZfwLIsQfwOQN1FttPlez0RP1 1b4Ani15xbP7UoHepA/yvwXBP2a1Kxjy =38zD -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From au@unterluggauer.org Tue Feb 1 02:53:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 02:53:39 -0800 (PST) Received: from mail.unterluggauer.org (chello062178068189.23.11.vie.surfer.at [62.178.68.189]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11ArYZM019026 for ; Tue, 1 Feb 2005 02:53:35 -0800 Received: from litiusoft.usoft.at (litiusoft.usoft.at [192.168.2.5]) by mail.unterluggauer.org (8.12.11/8.12.11) with ESMTP id j11Ar3bf013171; Tue, 1 Feb 2005 11:53:03 +0100 From: Andreas Unterluggauer To: Herbert Xu Subject: Re: Fw: [Bugme-new] [Bug 4138] New: ipsec with racoon in transport mode with esp and ah hangs (problem is in xfrm_state_add) Date: Tue, 1 Feb 2005 11:53:02 +0100 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com, "David S. Miller" References: <200501311640.16118.au@unterluggauer.org> <20050131211102.GA20323@gondor.apana.org.au> In-Reply-To: <20050131211102.GA20323@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502011153.03284.au@unterluggauer.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: au@unterluggauer.org Precedence: bulk X-list: netdev Hallo Herbert, > On Mon, Jan 31, 2005 at 03:40:16PM +0000, Andreas Unterluggauer wrote: > > 2005-01-31 16:29:58: DEBUG: === > > 2005-01-31 16:29:58: DEBUG: get pfkey ADD message > > andi: libipsec/pfkey.c, pfkey_check: start (msg->sadb_msg_satype: 3) > > 2005-01-31 16:29:58: DEBUG: andi: in pfkey.c, pk_recvadd: > > msg->sadb_msg_seq 2, msg->sadb_msg_type: ADD 2005-01-31 16:29:58: INFO: > > IPsec-SA established: ESP/Transport 192.168.2.5->192.168.2.3 > > spi=103868257(0x630e761) 2005-01-31 16:29:58: DEBUG: === > > Does the machine hang at this point in time? If not, then this is > simply a racoon bug. Although the acquire message carries a policy > with it, it's really only acquiring a single SA. Therefore, only > the SA being acquired should be added with that sequence number. the machine (kernel) is not hanging! only the programm (e.g. ping ) is hanging until it gets a timeout. the kernel is acquiring a SA and racoon answers, and the kernel is acquiring and racoon answers ... until the user-programm stops. thanks for the information, that its a racoon (ipsec-tools) problem. I will contact the ipsec-tools developers. ciao andi From andy.furniss@dsl.pipex.com Tue Feb 1 03:32:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 03:32:21 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11BWF8c020548 for ; Tue, 1 Feb 2005 03:32:16 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 67097E0002A7; Tue, 1 Feb 2005 11:32:07 +0000 (GMT) Message-ID: <41FF68B8.5050208@dsl.pipex.com> Date: Tue, 01 Feb 2005 11:32:08 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Cc: netdev@oss.sgi.com Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> In-Reply-To: <1107123123.8021.80.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev I sent two replies to this thread last night, which haven't shown up yet - did anyone get them? Andy. From hadi@cyberus.ca Tue Feb 1 03:49:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 03:49:59 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11BnrWv021303 for ; Tue, 1 Feb 2005 03:49:54 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CvwXU-0003QR-9v for netdev@oss.sgi.com; Tue, 01 Feb 2005 06:49:48 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CvwXP-0003LR-G4; Tue, 01 Feb 2005 06:49:43 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <41FEB3AE.3090400@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107258578.1095.570.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 06:49:40 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2005-01-31 at 17:39, Andy Furniss wrote: > Jamal Hadi Salim wrote: > > 2) Allows for queueing incoming traffic for shaping instead of > > dropping. I am not aware of any study that shows policing is > > worse than shaping in achieving the end goal of rate control. > > I would say the end goal is shaping not just rate control. Shaping > meaning different things to different people and ingress shaping being > different from egress. I know for a while the Bart howto was mislabeling the meaning of policing - not sure about shaping. Shaping has a precise definition that involves a queue and a non-working-conserving scheduler in order to rate control. This doesnt matter where it happens (egress or ingress). Policing on the other hand is work conserving etc. > For me it's from the wrong end of a relativly narrow (512kbit) > bottleneck link that has a 600ms fifo at the other end. My aim to > sacrifice as little bandwidth as possible while not adding latency > bursts for gaming and per user bandwidth allocation (with sharing of > unused) and sfq within that for bulk tcp traffic. > > If I was shaping LAN traffic, then policers/drops would be OK for me - > but for a slow link I think queueing and dropping are better/give more > control eg. I get to use sfq which should not drop the one packet a 56k > user has managed to send me in the face of lots of incoming from low > latency high bandwidth servers. > > Even if it's possible I bet few can easily get policers to setup the > complex sharing/prioritisations that you can with HTB or HFSC. sfq has a built in classifier that can efficiently separate those flows so you can achieve semi-fairness; so its not the shaping perse that helps, rather you ended up using a clever scheme that can isolate flows and benefited from shaping as a result; the hashing function should prove weak when a lot of flows start showing up. You could write some interesting classifier (as an example steal the one that sfq has) and achieve the same end results with policing. This would be easier now with ematches .. > > But i wont go back to putting netfilter hooks in the device to satisfy > > this. I also dont think its worth it hacking dummy some more to be > > aware of say L3 info and play ip rule tricks to achieve this. > > --> Instead the plan is to have a contrack related action. This action > > will selectively either query/create contrack state on incoming packets. > > I don't understand exactly what you mean here - for my setup to work I > need to see denatted addresses and mark (connbytes - it helps me be > extra nasty to multiple simoultaneous connections in slowstart and > prioritise browsing over bulk) in prerouting mangle. Of course if I can > use netfilter to classify and save into contrack then I could do > evrything in netfilter and then use something like connmark to save it > per connection. > You may be refering to requirement #3 then? In other words what you are doing is best served by knowing the state? Are pre/post routing sufficient as netfilter hooks for your case? > > Packets could then be redirected to dummy based on what happens -> eg > > on incoming packets; if we find they are of known state we could send to > > a different queue than one which didnt have existing state. This > > all however is dependent on whatever rules the admin enters. > > > How does the admin enter the rules - netfilter or other? > Just like i showed in that post (It was long - so dont wanna cutnpaste here). cheers, jamal From hadi@cyberus.ca Tue Feb 1 04:02:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 04:02:58 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11C2qQT022537 for ; Tue, 1 Feb 2005 04:02:52 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Cvwk3-0008Bd-3w for netdev@oss.sgi.com; Tue, 01 Feb 2005 07:02:47 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cvwjz-0004aM-OQ; Tue, 01 Feb 2005 07:02:44 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050131225328.GI31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107259361.1095.584.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 07:02:41 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2005-01-31 at 17:53, Thomas Graf wrote: > I was thinking of the parameters to define what a flow consists of. > Extended SFQ basically allows you to define the hash function. I think > I misunderstood you before and you don't want allow adjustable > states on only a subset of the attributes, e.g. only L3 data. Why bother putting extra classifier functionality into a qdisc? you should be able to rip off the classifier from sfq so you dont depend on it; you can then select one of n queues (eaction meta set class 1:X based on result of sfq classifier - or you can have it set the classids based on resulting hash index) > > I think the eactions etc are adding a lot of value towards usability. > > Hasso Tepper was ealrier complaining about this same issue. > > As an example, I think u32 and ematches would improve a great deal now > > and be more understandable. True, work/time still needs to be invested. > > I'd guess that the basic classifier will make the race because the > documentation will be smaller due to the lack of parameters. ;-> Well, even if it is just being able to describe in english the u32 parameters and displaying them in english (by using a ID stored) its already huge progress. > But yes I agree, I think we're making small step forwards and hopefully > the network config shell/tool/whatever will ease the steps to configure > things. My primary goal is to allow using it without looking up > parameters all the time, given one is aware of the common terms and basic > concepts. Online easy to use help is always valuable. > I'll have some more time next week and will try to implement the > traffic control bits or at least some of them. The wind forecast is pretty > good for the next days so I won't have too much time. ;-> Weather is also predicted to be good here for the week; we are planning to get out of our igloos and go tobagoning;-> cheers, jamal From tgraf@suug.ch Tue Feb 1 04:51:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 04:51:36 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11CpUj5027701 for ; Tue, 1 Feb 2005 04:51:30 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7C07982; Tue, 1 Feb 2005 13:51:06 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 71E821C0EA; Tue, 1 Feb 2005 13:51:47 +0100 (CET) Date: Tue, 1 Feb 2005 13:51:47 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201125147.GK31837@postel.suug.ch> References: <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107259361.1095.584.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1146 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > Why bother putting extra classifier functionality into a qdisc? > you should be able to rip off the classifier from sfq so you dont depend > on it; you can then select one of n queues (eaction meta set class 1:X > based on result of sfq classifier - or you can have it set the classids > based on resulting hash index) Excellent idea, this would allow for various hash functions to be used in a single sfq. We can use skb->tc_index for it so we can easly combine it with a underlying dsmark. The hardest part is to find a intuitive form to define the hash, it should be possible to for example define a hash based on daddr + hproto only completely ignoring saddr. The perutrbation must be made optional, sometimes the hash will not produce any unwanted collisions (hash based on dscp for example) so modifying it wouldn't make sense. We can fork sfq and make a gsfq which takes the hash from tc_index and disabled perturbation if it is set to 0. Thoughts? > Well, even if it is just being able to describe in english the u32 > parameters and displaying them in english (by using a ID stored) > its already huge progress. True. I've some notes on paper describing a match definition db which basically defines a u32 like match and assigns a name and id to it, it is stored in a external database file so everyone can define their own pre defined matches without recompiling. I've put together some code printing a tc tree as a whole and added it to netconfig. It's just a start and still contains redundant information which can be removed but I think it's already a step forward because it all gets down to one command. Currently it's only possible to filter on the device but I'll extend this later so one can extract a part of the tree. One pretty ugly thing is that cbq creates a qdisc and class with the same handle which gets quite confusing if one wants list the filters attached to a certain handle because they will show up for both, the qdisc and the root class. Full output for a default ethernet device: lsx# tc tree full where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 txqlen 1000 weight 64 qdisc pfifo_fast irq 19 index 4 brd ff:ff:ff:ff:ff:ff pfifo_fast qdisc dev eth0 handle none parent none bands 3 refcnt 1 priomap [1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1] besteffort => 1 0x8 => 1 filler => 2 0x9 => 1 bulk => 2 0xa => 1 0x3 => 2 0xb => 1 interactive_bulk => 1 0xc => 1 0x5 => 2 0xd => 1 interactive => 0 0xe => 1 control => 0 0xf => 1 Brief output for some cbq classes: lsx# tc tree where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 cbq qdisc dev eth0 handle 10: parent none rate 11.92MiB/s (95Mbit) prio 8 cbq class dev eth0 handle 10: parent root rate 11.92MiB/s (95Mbit) prio 8 u32 cls dev eth0 handle none parent 10: prio 10 protocol ip u32 cls dev eth0 handle 8000: parent 10: prio 10 protocol ip divisor 1 u32 cls dev eth0 handle 8000:800 parent 10: prio 10 protocol ip target 10:12 cbq class dev eth0 handle 10:12 parent 10: rate 11.92MiB/s (95Mbit) prio 3 sfq qdisc dev eth0 handle 8003: parent 10:12 quantum 1514 perturb 0us Full output with stats for some cbq classes: lsx# tc tree stats where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 txqlen 1000 weight 64 qdisc cbq irq 19 index 4 brd ff:ff:ff:ff:ff:ff Stats: bytes packets errors dropped fifo-err compressed RX 46.65 MiB 42211 0 0 0 0 TX 1.91 MiB 16234 0 0 0 0 Errors: length over crc frame missed multicast RX 0 0 0 0 0 0 Errors: aborted carrier heartbeat window collision TX 0 0 0 0 0 cbq qdisc dev eth0 handle 10: parent none rate 11.92MiB/s (95Mbit) prio 8 refcnt 1 avgpkt 1400 mpu 64 cell 16 allot 1514 weight 95Mbit minidle 65535999us maxidle 2us offtime 0us level 1 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 44.02 KiB 380 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 114 0 cbq class dev eth0 handle 10: parent root rate 11.92MiB/s (95Mbit) prio 8 avgpkt 1400 mpu 64 cell 16 allot 1514 weight 95Mbit minidle 65535999us maxidle 2us offtime 0us level 1 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 44.02 KiB 380 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 114 0 u32 cls dev eth0 handle none parent 10: prio 10 protocol ip Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps u32 cls dev eth0 handle 8000: parent 10: prio 10 protocol ip divisor 1 Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps u32 cls dev eth0 handle 8000:800 parent 10: prio 10 protocol ip target 10:12 nkeys 1 ht key 0x800 hash 0x0 match u32 at 8 & 0x00ff0000 == 0x00010000 successful 34 Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps successful hits 34 379 cbq class dev eth0 handle 10:12 parent 10: rate 11.92MiB/s (95Mbit) prio 3 child-qdisc 8003: avgpkt 500 mpu 0 cell 8 allot 1514 weight 95Mbit minidle 65535999us maxidle 0us offtime 0us level 0 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 3.25 KiB 34 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 40 0 sfq qdisc dev eth0 handle 8003: parent 10:12 quantum 1514 perturb 0us refcnt 1 limit 128 divisor 1024 flows 128 Stats: bytes packets drops overlimits qlen backlog 3.25 KiB 34 0 0 0 0 0.00 B/s 0 pps From hadi@cyberus.ca Tue Feb 1 05:13:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 05:13:50 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11DDhdP029189 for ; Tue, 1 Feb 2005 05:13:44 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1Cvxqb-0006Ew-Dc for netdev@oss.sgi.com; Tue, 01 Feb 2005 06:13:37 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cvxqa-0005XU-7n; Tue, 01 Feb 2005 08:13:36 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050201125147.GK31837@postel.suug.ch> References: <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107263612.1095.598.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 08:13:33 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 07:51, Thomas Graf wrote: > > Why bother putting extra classifier functionality into a qdisc? > > you should be able to rip off the classifier from sfq so you dont depend > > on it; you can then select one of n queues (eaction meta set class 1:X > > based on result of sfq classifier - or you can have it set the classids > > based on resulting hash index) > > Excellent idea, this would allow for various hash functions to be used > in a single sfq. We can use skb->tc_index for it so we can easly combine Let the meta action do that. Just set the skb->tc_classid in my opinion; recall we can change classid now .. > it with a underlying dsmark. The hardest part is to find a intuitive > form to define the hash, it should be possible to for example define > a hash based on daddr + hproto only completely ignoring saddr. The > perutrbation must be made optional, sometimes the hash will not produce > any unwanted collisions (hash based on dscp for example) so modifying it > wouldn't make sense. We can fork sfq and make a gsfq which takes the > hash from tc_index and disabled perturbation if it is set to 0. > Thoughts? You can let the user define that via tc but have a default; eg: tc dev eth0 add sfq ematch tc dev eth0 set sfq pertub xxx match u32 ... ematch sfq ematch meta classid 1:2 eaction meta set tcindex 101 eaction meta set fwmark .. etc I have to run, havent looked at the rest of your email - will later. cheers, jamal From tgraf@suug.ch Tue Feb 1 05:31:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 05:31:25 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11DVK97030050 for ; Tue, 1 Feb 2005 05:31:20 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 4B45082; Tue, 1 Feb 2005 14:30:56 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4CB841C0EA; Tue, 1 Feb 2005 14:31:38 +0100 (CET) Date: Tue, 1 Feb 2005 14:31:38 +0100 From: Thomas Graf To: Andy Furniss Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201133138.GM31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FED514.7060702@dsl.pipex.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > >> X = ---------------------------------------------------------- > >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) > >> > >>Where: > >> > >> X is the transmit rate in bytes/second. > >> s is the packet size in bytes. > >> R is the round trip time in seconds. > >> p is the loss event rate, between 0 and 1.0, of the number of loss > >> events as a fraction of the number of packets transmitted. > >> t_RTO is the TCP retransmission timeout value in seconds. > >> b is the number of packets acknowledged by a single TCP > >> acknowledgement. > > WRT policers I never figured out where you would put the effects of > playing with the burst size parameter and it's effects with few/many > connections and any burstiness caused into an equasion like that. A burst buffer has impact on R on later packets, it can "smooth" R and X and thus results in more stable rates. Depending on the actual burst, it can avoid retransmits which stabilizes the rate as well. > This sounds cool. For me in someways I think it could be nicer (in the > case of shaping from the wrong end of a slow link) to delay the real > packets - that way the tcps of the clients get to see the smoothed > version of the traffic and you can delay udp aswell. It's impossible to never drop anything, for udp we can either drop it or use ECN and hope the other ip stack takes care of it or the application implements its own cc algorithm. Basically you can already do that with (G)RED. Most UDP users which provide a continous stream such as video streams, implement some kind of key datagram which contains the number of datagrams received since the last key datagram and the application throttles down based on that so dropping is often the only way to achieve a general working solution. Delaying UDP packets and then drop them if the buffer is full is very dangerous, often the protocols based on UDP rely on the assumption that datagrams get lost randomly and not succcessive. We can think about precicse policing for UDP again once the current poor application level cc algorithms have failed and the industry accepted ECN as the right thing. For now most of them still suffer from the NIH syndrom in this area. > How intelligent and how much, if any, per connection state do you/could > you keep? I keep a rate estimator for every flow on ingress in a hash table and lookup it up on egress with the flow parameters reversed. It gets pretty expensive on huge amounts of connection usually one doesn't want to do per connection policing on such boxes. ;-> From linville@bilbo.tuxdriver.com Tue Feb 1 06:25:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 06:25:50 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11EPhb7032035 for ; Tue, 1 Feb 2005 06:25:44 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j11EFcl23172; Tue, 1 Feb 2005 09:15:38 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j11EPYtw015189; Tue, 1 Feb 2005 09:25:34 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j11EPXWD015188; Tue, 1 Feb 2005 09:25:33 -0500 Date: Tue, 1 Feb 2005 09:25:33 -0500 From: "John W. Linville" To: Anton Blanchard Cc: Scott Feldman , jgarzik@pobox.com, netdev@oss.sgi.com, lunz@falooley.org Subject: Re: [PATCH 2.6] e100: remove reference to NAPI config option Message-ID: <20050201142533.GB15056@tuxdriver.com> Mail-Followup-To: Anton Blanchard , Scott Feldman , jgarzik@pobox.com, netdev@oss.sgi.com, lunz@falooley.org References: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> <20050201014358.GD15786@krispykreme.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201014358.GD15786@krispykreme.ozlabs.ibm.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev On Tue, Feb 01, 2005 at 12:43:58PM +1100, Anton Blanchard wrote: > > Hi Scott, > > > e100 is NAPI all the time, so the Kconfig option is wasting space. > > Speaking of NAPI... > > We have seen issues with NAPI on ppc64 on various cards in the past. Just curious...wanna try this patch I got from Intel? I think it may help... John --- linux-2.6.9/drivers/net/e100.c.napifix 2005-01-25 15:54:28.830937362 -0500 +++ linux-2.6.9/drivers/net/e100.c 2005-01-25 15:54:56.350257693 -0500 @@ -269,6 +269,12 @@ enum scb_status { rus_mask = 0x3C, }; +enum ru_state { + RU_SUSPENDED = 0, + RU_RUNNING = 1, + RU_UNINITIALIZED = -1, +}; + enum scb_stat_ack { stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, @@ -510,7 +516,7 @@ struct nic { struct rx *rx_to_use; struct rx *rx_to_clean; struct rfd blank_rfd; - int ru_running; + enum ru_state ru_running; spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; @@ -1417,12 +1423,18 @@ static int e100_alloc_cbs(struct nic *ni return 0; } -static inline void e100_start_receiver(struct nic *nic) +static inline void e100_start_receiver(struct nic *nic, struct rx *rx) { + if(!nic->rxs) return; + if(RU_SUSPENDED != nic->ru_running) return; + + /* handle init time starts */ + if(!rx) rx = nic->rxs; + /* (Re)start RU if suspended or idle and RFA is non-NULL */ - if(!nic->ru_running && nic->rx_to_clean->skb) { - e100_exec_cmd(nic, ruc_start, nic->rx_to_clean->dma_addr); - nic->ru_running = 1; + if(rx->skb) { + e100_exec_cmd(nic, ruc_start, rx->dma_addr); + nic->ru_running = RU_RUNNING; } } @@ -1473,7 +1485,7 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -ENODATA; /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1484,6 +1496,10 @@ static inline int e100_rx_indicate(struc pci_unmap_single(nic->pdev, rx->dma_addr, RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + /* this allows for a fast restart without re-enabling interrupts */ + if(le16_to_cpu(rfd->command) & cb_el) + nic->ru_running = RU_SUSPENDED; + /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); skb_put(skb, actual_size); @@ -1516,20 +1532,45 @@ static inline void e100_rx_clean(struct unsigned int work_to_do) { struct rx *rx; + int restart_required = 0; + struct rx *rx_to_start = NULL; + + /* are we already rnr? then pay attention!!! this ensures that + * the state machine progression never allows a start with a + * partially cleaned list, avoiding a race between hardware + * and rx_to_clean when in NAPI mode */ + if(RU_SUSPENDED == nic->ru_running) + restart_required = 1; /* Indicate newly arrived packets */ for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) { - if(e100_rx_indicate(nic, rx, work_done, work_to_do)) + int err = e100_rx_indicate(nic, rx, work_done, work_to_do); + if(-EAGAIN == err) { + /* hit quota so have more work to do, restart once + * cleanup is complete */ + restart_required = 0; + break; + } else if(-ENODATA == err) break; /* No more to clean */ } + /* save our starting point as the place we'll restart the receiver */ + if(restart_required) + rx_to_start = nic->rx_to_clean; + /* Alloc new skbs to refill list */ for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) { if(unlikely(e100_rx_alloc_skb(nic, rx))) break; /* Better luck next time (see watchdog) */ } - e100_start_receiver(nic); + if(restart_required) { + // ack the rnr? + writeb(stat_ack_rnr, &nic->csr->scb.stat_ack); + e100_start_receiver(nic, rx_to_start); + if(work_done) + (*work_done)++; + } } static void e100_rx_clean_list(struct nic *nic) @@ -1537,6 +1578,8 @@ static void e100_rx_clean_list(struct ni struct rx *rx; unsigned int i, count = nic->params.rfds.count; + nic->ru_running = RU_UNINITIALIZED; + if(nic->rxs) { for(rx = nic->rxs, i = 0; i < count; rx++, i++) { if(rx->skb) { @@ -1550,7 +1593,6 @@ static void e100_rx_clean_list(struct ni } nic->rx_to_use = nic->rx_to_clean = NULL; - nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) @@ -1559,6 +1601,7 @@ static int e100_rx_alloc_list(struct nic unsigned int i, count = nic->params.rfds.count; nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = RU_UNINITIALIZED; if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; @@ -1574,6 +1617,7 @@ static int e100_rx_alloc_list(struct nic } nic->rx_to_use = nic->rx_to_clean = nic->rxs; + nic->ru_running = RU_SUSPENDED; return 0; } @@ -1595,7 +1639,7 @@ static irqreturn_t e100_intr(int irq, vo /* We hit Receive No Resource (RNR); restart RU after cleaning */ if(stat_ack & stat_ack_rnr) - nic->ru_running = 0; + nic->ru_running = RU_SUSPENDED; e100_disable_irq(nic); netif_rx_schedule(netdev); @@ -1611,6 +1655,7 @@ static int e100_poll(struct net_device * int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); + // should we be quota on tx? tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ @@ -1684,7 +1729,7 @@ static int e100_up(struct nic *nic) if((err = e100_hw_init(nic))) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) @@ -1759,7 +1804,7 @@ static int e100_loopback_test(struct nic mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, BMCR_LOOPBACK); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; -- John W. Linville linville@tuxdriver.com From andy.furniss@dsl.pipex.com Tue Feb 1 06:53:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 06:53:44 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11ErdLA003342 for ; Tue, 1 Feb 2005 06:53:40 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 18C66E0002A4; Tue, 1 Feb 2005 14:53:28 +0000 (GMT) Message-ID: <41FF97E9.7040501@dsl.pipex.com> Date: Tue, 01 Feb 2005 14:53:29 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> In-Reply-To: <1107258578.1095.570.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev jamal wrote: > On Mon, 2005-01-31 at 17:39, Andy Furniss wrote: > >>Jamal Hadi Salim wrote: > > >>>2) Allows for queueing incoming traffic for shaping instead of >>>dropping. I am not aware of any study that shows policing is >>>worse than shaping in achieving the end goal of rate control. >> >>I would say the end goal is shaping not just rate control. Shaping >>meaning different things to different people and ingress shaping being >>different from egress. > > > I know for a while the Bart howto was mislabeling the meaning of > policing - not sure about shaping. > Shaping has a precise definition that involves a queue and a > non-working-conserving scheduler in order to rate control. This doesnt > matter where it happens (egress or ingress). Policing on the other hand > is work conserving etc. Ok, but shaping to LARTC posters means being able to classify traffic and set up sharing/priorotising of classes. This is the reason most need to be able to queue - they want to use htb/hfsc for complicated setups and until now were not aware that it was even possible to replicate this in policers and if it becomes feasable it will probably appear daunting to do compared with HTB and all the existing docs/scripts. For me, I think queuing and dropping is better than just dropping, you can affect tcp by delaying eg. 1 ack per packet rather than delayed acks and clocking out the packets helps smooth burstiness, which hurts latency if you are doing traffic control from the wrong end of the bottleneck. > >>For me it's from the wrong end of a relativly narrow (512kbit) >>bottleneck link that has a 600ms fifo at the other end. My aim to >>sacrifice as little bandwidth as possible while not adding latency >>bursts for gaming and per user bandwidth allocation (with sharing of >>unused) and sfq within that for bulk tcp traffic. >> >>If I was shaping LAN traffic, then policers/drops would be OK for me - >>but for a slow link I think queueing and dropping are better/give more >>control eg. I get to use sfq which should not drop the one packet a 56k >>user has managed to send me in the face of lots of incoming from low >>latency high bandwidth servers. >> >>Even if it's possible I bet few can easily get policers to setup the >>complex sharing/prioritisations that you can with HTB or HFSC. > > > sfq has a built in classifier that can efficiently separate those > flows so you can achieve semi-fairness; so its not the shaping perse > that helps, rather you ended up using a clever scheme that can isolate > flows and benefited from shaping as a result; the hashing function > should prove weak when a lot of flows start showing up. > You could write some interesting classifier (as an example steal the one > that sfq has) and achieve the same end results with policing. This would > be easier now with ematches .. The idea of loosing the s from sfq and doing multilevel hash/mapping is attractive - of course I would want to queue each flow and have the queue be variable length for each flow depending on occupancy of other flows. I suppose a per flow intelligent dropping scheme would be even better. It would be nice to be able to set/control queuelength for link bandwidth, nothing classful in linux tc does this. > > >>>But i wont go back to putting netfilter hooks in the device to satisfy >>>this. I also dont think its worth it hacking dummy some more to be >>>aware of say L3 info and play ip rule tricks to achieve this. >>>--> Instead the plan is to have a contrack related action. This action >>>will selectively either query/create contrack state on incoming packets. >> >>I don't understand exactly what you mean here - for my setup to work I >>need to see denatted addresses and mark (connbytes - it helps me be >>extra nasty to multiple simoultaneous connections in slowstart and >>prioritise browsing over bulk) in prerouting mangle. Of course if I can >>use netfilter to classify and save into contrack then I could do >>evrything in netfilter and then use something like connmark to save it >>per connection. >> > > > You may be refering to requirement #3 then? > In other words what you are doing is best served by knowing the state? As long as I could use netfilter to mark/classify connections then I think I can sort my setup, don't know about others. > Are pre/post routing sufficient as netfilter hooks for your case? Yes but depends on where in pre/postrouting. For me after/before nat, as I say above though I could workaround if I classify connections with netfilter. For others as long as they can filter on a mark/classify set in forward, then I think it will be OK for them. > > >>>Packets could then be redirected to dummy based on what happens -> eg >>>on incoming packets; if we find they are of known state we could send to >>>a different queue than one which didnt have existing state. This >>>all however is dependent on whatever rules the admin enters. >> >> >>How does the admin enter the rules - netfilter or other? >> > > Just like i showed in that post (It was long - so dont wanna cutnpaste > here). > I am not sure what exactly can can't be done in your example: ># 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 \ What I can do here depends where it hooks packets. >action ipt -j MARK --set-mark 1 \ I don't know what table I am using - may be OK as long as I can test for a mark I made earlier in the egress dummy case or test connmark/state I set for that connection in the ingress case. >action mirred egress redirect dev dummy0 Andy. > cheers, > jamal > > From andy.furniss@dsl.pipex.com Tue Feb 1 07:04:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 07:04:06 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11F41CJ004128 for ; Tue, 1 Feb 2005 07:04:02 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 5A265E000239; Tue, 1 Feb 2005 15:03:49 +0000 (GMT) Message-ID: <41FF9A55.4080005@dsl.pipex.com> Date: Tue, 01 Feb 2005 15:03:49 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> <20050201133138.GM31837@postel.suug.ch> In-Reply-To: <20050201133138.GM31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Thomas Graf wrote: >>>> X = ---------------------------------------------------------- >>>> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) >>>> >>>>Where: >>>> >>>> X is the transmit rate in bytes/second. >>>> s is the packet size in bytes. >>>> R is the round trip time in seconds. >>>> p is the loss event rate, between 0 and 1.0, of the number of loss >>>> events as a fraction of the number of packets transmitted. >>>> t_RTO is the TCP retransmission timeout value in seconds. >>>> b is the number of packets acknowledged by a single TCP >>>> acknowledgement. >> >>WRT policers I never figured out where you would put the effects of >>playing with the burst size parameter and it's effects with few/many >>connections and any burstiness caused into an equasion like that. > > > A burst buffer has impact on R on later packets, it can "smooth" R > and X and thus results in more stable rates. Depending on the actual > burst, it can avoid retransmits which stabilizes the rate as well. But it's not a real rate limiting buffer in the policer case is it? > > >>This sounds cool. For me in someways I think it could be nicer (in the >>case of shaping from the wrong end of a slow link) to delay the real >>packets - that way the tcps of the clients get to see the smoothed >>version of the traffic and you can delay udp aswell. > > > It's impossible to never drop anything, for udp we can either drop > it or use ECN and hope the other ip stack takes care of it or the > application implements its own cc algorithm. Basically you can already > do that with (G)RED. Most UDP users which provide a continous stream > such as video streams, implement some kind of key datagram which contains > the number of datagrams received since the last key datagram and the > application throttles down based on that so dropping is often the only > way to achieve a general working solution. Delaying UDP packets and > then drop them if the buffer is full is very dangerous, often the > protocols based on UDP rely on the assumption that datagrams get lost > randomly and not succcessive. We can think about precicse policing > for UDP again once the current poor application level cc algorithms > have failed and the industry accepted ECN as the right thing. For > now most of them still suffer from the NIH syndrom in this area. Interesting stuff. I was thinking of game udp where just dropping would simulate what the user should have done anyway, but costing you bandwidth. If alot of gamers share a slow link then if you lag them out they know it's time to turn the rate down. > > >>How intelligent and how much, if any, per connection state do you/could >>you keep? > > > I keep a rate estimator for every flow on ingress in a hash table and > lookup it up on egress with the flow parameters reversed. It gets > pretty expensive on huge amounts of connection usually one doesn't > want to do per connection policing on such boxes. ;-> > Nice - are you planning to add anything to tweak things for the wrong end of the bottleneck problems? Andy. From sfeldma@pobox.com Tue Feb 1 11:10:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:10:19 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JAALn020342 for ; Tue, 1 Feb 2005 11:10:13 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id DC5B595; Tue, 1 Feb 2005 14:10:09 -0500 (EST) Received: from [192.168.0.3] (wbar2.sea1-4-5-062-153.sea1.dsl-verizon.net [4.5.62.153]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 4DA1189; Tue, 1 Feb 2005 14:10:08 -0500 (EST) Subject: [PATCH 2.6] eepro100: remove ID for 82556 From: Scott Feldman Reply-To: sfeldma@pobox.com To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1107285106.3366.106.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 01 Feb 2005 11:11:46 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev 82556 support doesn't work with eepro100, so this removes the ID (0x1228) for 82556. See this thread for more info: http://marc.theaimsgroup.com/?l=linux-kernel&m=110726223221165&w=2 Signed-off-by: Scott Feldman --- linux-2.4.28-rc1/drivers/net/eepro100.c.orig 2005-02-01 10:58:56.878906632 -0800 +++ linux-2.4.28-rc1/drivers/net/eepro100.c 2005-02-01 10:59:10.479838976 -0800 @@ -2395,7 +2395,6 @@ { PCI_VENDOR_ID_INTEL, 0x1050, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1059, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1227, PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, 0x1228, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x2449, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x2459, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x245D, PCI_ANY_ID, PCI_ANY_ID, }, From olh@suse.de Tue Feb 1 11:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:27:47 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JRg8d021316 for ; Tue, 1 Feb 2005 11:27:43 -0800 Received: from hermes.suse.de (hermes-ext.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 8875B13E97C4; Tue, 1 Feb 2005 20:27:36 +0100 (CET) Date: Tue, 1 Feb 2005 20:27:35 +0100 From: Olaf Hering To: Ganesh Venkatesan , netdev@oss.sgi.com Cc: linuxppc64-dev@ozlabs.org Subject: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Message-ID: <20050201192735.GB7433@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev We have this patch in SLES9 SP1. I asked google about 'fix for errata 23, cant cross 64kB boundary', and it shhows such a patch is also part of RH 2.6.9. It still applies to current Linus tree. Can you check wether this is still required for the current driver? References: SUSE48368 LTC12567 Need to check 64k boundary on DMA address as well. We also need to have 64k boundary checking on the DMA address that comes back from pci_map_single(). This address is what will be passed to the adapter on ppc64 for it to DMA into. It's the address that the adapter sees which will trip erratum 23. The so patched driver passed a quick netperf run and a weekend long stress test. diff -puN drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse drivers/net/e1000-new/e1000_main.c --- linux-2.6.5-7.127/drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse Wed Dec 8 16:55:46 2004 +++ linux-2.6.5-7.127-moilanen/drivers/net/e1000-new/e1000_main.c Thu Dec 9 15:46:04 2004 @@ -2579,6 +2579,29 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + if(adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546) { + /* fix for errata 23, cant cross 64kB boundary */ + begin = (unsigned long)buffer_info->dma; + end = (unsigned long)(adapter->rx_buffer_len) - 1; + + if(!e1000_check_64k_alignment(adapter, begin, end)) { + + DPRINTK(RX_ERR,ERR,"dma align check failed: " + "begin: 0x%lx, end: 0x%lx\n", begin, end); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } + } + rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); From jdmason@us.ibm.com Tue Feb 1 11:35:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:35:15 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JZBd5021959 for ; Tue, 1 Feb 2005 11:35:11 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j11JZ5Bu451188 for ; Tue, 1 Feb 2005 14:35:05 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j11JZ5Z6191154 for ; Tue, 1 Feb 2005 12:35:05 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j11JZ4P5009923 for ; Tue, 1 Feb 2005 12:35:04 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j11JZ4ZX009900; Tue, 1 Feb 2005 12:35:04 -0700 From: Jon Mason Organization: IBM To: Olaf Hering Subject: Re: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Date: Tue, 1 Feb 2005 13:33:59 -0600 User-Agent: KMail/1.7.2 Cc: Ganesh Venkatesan , netdev@oss.sgi.com, linuxppc64-dev@ozlabs.org References: <20050201192735.GB7433@suse.de> In-Reply-To: <20050201192735.GB7433@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502011333.59262.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev On Tuesday 01 February 2005 01:27 pm, Olaf Hering wrote: > > We have this patch in SLES9 SP1. > I asked google about 'fix for errata 23, cant cross 64kB boundary', and > it shhows such a patch is also part of RH 2.6.9. > It still applies to current Linus tree. > Can you check wether this is still required for the current driver? This patch is still lacking from the latest e1000 driver. Intel has the patch in their queue, so it will be needed until they release their next version of the e1000 driver. From ganesh.venkatesan@intel.com Tue Feb 1 11:36:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:36:45 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JacM3022319 for ; Tue, 1 Feb 2005 11:36:39 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j11JaX0q020535; Tue, 1 Feb 2005 19:36:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j11Ja4Dq012823; Tue, 1 Feb 2005 19:36:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005020111363315138 ; Tue, 01 Feb 2005 11:36:33 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 11:36:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Date: Tue, 1 Feb 2005 11:36:31 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Thread-Index: AcUIlBtNJPyOId/LRwe3DRCCmZqjywAANlzQ From: "Venkatesan, Ganesh" To: "Olaf Hering" , Cc: , "Ronciak, John" , "Brandeburg, Jesse" X-OriginalArrivalTime: 01 Feb 2005 19:36:32.0975 (UTC) FILETIME=[55A1E5F0:01C50895] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j11JacM3022319 X-archive-position: 1155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev The patch attached to your mail does not seem to be complete. Did the mail application truncate? In any case, this fix is required in e1000. It is *not* in the latest driver that is released but *is* in the driver that is lined up for release in a couple of weeks. Thanks, Ganesh. >-----Original Message----- >From: Olaf Hering [mailto:olh@suse.de] >Sent: Tuesday, February 01, 2005 11:28 AM >To: Venkatesan, Ganesh; netdev@oss.sgi.com >Cc: linuxppc64-dev@ozlabs.org >Subject: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption >when DMA crosses a 64k boundary > > >We have this patch in SLES9 SP1. >I asked google about 'fix for errata 23, cant cross 64kB boundary', and >it shhows such a patch is also part of RH 2.6.9. >It still applies to current Linus tree. >Can you check wether this is still required for the current driver? > > >References: SUSE48368 LTC12567 > >Need to check 64k boundary on DMA address as well. > >We also need to have 64k boundary checking on the DMA address >that comes back from pci_map_single(). This address is what will >be passed to the adapter on ppc64 for it to DMA into. It's the >address that the adapter sees which will trip erratum 23. > >The so patched driver passed a quick netperf run and a weekend >long stress test. > >diff -puN drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse >drivers/net/e1000-new/e1000_main.c >--- linux-2.6.5-7.127/drivers/net/e1000-new/e1000_main.c~64k-align-check- >dma-suse Wed Dec 8 16:55:46 2004 >+++ linux-2.6.5-7.127-moilanen/drivers/net/e1000-new/e1000_main.c Thu Dec >9 15:46:04 2004 >@@ -2579,6 +2579,29 @@ e1000_alloc_rx_buffers(struct e1000_adap > adapter->rx_buffer_len, > PCI_DMA_FROMDEVICE); > >+ if(adapter->hw.mac_type == e1000_82545 || >+ adapter->hw.mac_type == e1000_82546) { >+ /* fix for errata 23, cant cross 64kB boundary */ >+ begin = (unsigned long)buffer_info->dma; >+ end = (unsigned long)(adapter->rx_buffer_len) - 1; >+ >+ if(!e1000_check_64k_alignment(adapter, begin, end)) { >+ >+ DPRINTK(RX_ERR,ERR,"dma align check failed: " >+ "begin: 0x%lx, end: 0x%lx\n", begin, end); >+ >+ dev_kfree_skb(skb); >+ buffer_info->skb = NULL; >+ >+ pci_unmap_single(pdev, >+ buffer_info->dma, >+ adapter->rx_buffer_len, >+ PCI_DMA_FROMDEVICE); >+ >+ break; /* while !buffer_info->skb */ >+ } >+ } >+ > rx_desc = E1000_RX_DESC(*rx_ring, i); > rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); > From olh@suse.de Tue Feb 1 11:40:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:40:22 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JeHjG022986 for ; Tue, 1 Feb 2005 11:40:18 -0800 Received: from hermes.suse.de (hermes-ext.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 3C26613DD392; Tue, 1 Feb 2005 20:40:11 +0100 (CET) Date: Tue, 1 Feb 2005 20:40:10 +0100 From: Olaf Hering To: "Venkatesan, Ganesh" Cc: netdev@oss.sgi.com, linuxppc64-dev@ozlabs.org, "Ronciak, John" , "Brandeburg, Jesse" Subject: Re: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Message-ID: <20050201194010.GA7892@suse.de> References: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev On Tue, Feb 01, Venkatesan, Ganesh wrote: > In any case, this fix is required in e1000. It is *not* in the latest > driver that is released but *is* in the driver that is lined up for > release in a couple of weeks. Thats good enough, just that things dont get lost. There are probably a few separate patches for each problem found. We are still in the process of sorting out our +2k patch mess. From xose@wanadoo.es Tue Feb 1 12:18:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 12:18:04 -0800 (PST) Received: from smtp2.jazztel.es (smtp2.jazztel.es [62.14.3.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KHxbM024228 for ; Tue, 1 Feb 2005 12:18:00 -0800 Received: from antivirus by smtp2.jazztel.es with antivirus id 1Cw4TW-0007OK-00 Tue, 01 Feb 2005 21:18:14 +0100 Received: from [212.106.207.199] (helo=wanadoo.es) by smtp2.jazztel.es with esmtp id 1Cw4TW-0007Mb-00 Tue, 01 Feb 2005 21:18:14 +0100 Message-ID: <41FFE3EB.5050603@wanadoo.es> Date: Tue, 01 Feb 2005 21:17:47 +0100 From: Xose Vazquez Perez User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.3) Gecko/20041005 X-Accept-Language: gl, es, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: jgarzik@pobox.com Subject: [ PATCH ] 2.6 eepro100: replace and delete duplicate ids References: <3FBA97E4.1060004@wanadoo.es> In-Reply-To: <3FBA97E4.1060004@wanadoo.es> Content-Type: multipart/mixed; boundary="------------040809020605060701090308" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by antivirus X-Virus-Status: Clean X-archive-position: 1157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xose@wanadoo.es Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040809020605060701090308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, - replace PCI_DEVICE_ID_INTEL_82557 and PCI_DEVICE_ID_INTEL_82559ER with theirs hex numbers - PCI_DEVICE_ID_INTEL_82801BA_7 is a duplicate of 0x2449. -thanks- --------------040809020605060701090308 Content-Type: text/plain; name="eepro100_ids.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100_ids.diff" --- linux2/drivers/net/eepro100.c 2005-01-22 19:22:54.000000000 +0100 +++ n/drivers/net/eepro100.c 2005-02-01 21:10:15.000000000 +0100 @@ -2355,12 +2355,8 @@ } static struct pci_device_id eepro100_pci_tbl[] = { - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82557, - PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82559ER, - PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_7, - PCI_ANY_ID, PCI_ANY_ID, }, + { PCI_VENDOR_ID_INTEL, 0x1229, PCI_ANY_ID, PCI_ANY_ID, }, + { PCI_VENDOR_ID_INTEL, 0x1209, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1029, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1030, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1031, PCI_ANY_ID, PCI_ANY_ID, }, --------------040809020605060701090308-- From laurent.deniel@free.fr Tue Feb 1 12:49:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 12:49:33 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KnH2r030126 for ; Tue, 1 Feb 2005 12:49:26 -0800 Received: from [192.168.1.108] (robinson-6-82-224-198-22.fbx.proxad.net [82.224.198.22]) by postfix3-2.free.fr (Postfix) with ESMTP id 03BEDC3A8 for ; Tue, 1 Feb 2005 21:49:14 +0100 (CET) Message-ID: <41FFEB4A.90400@free.fr> Date: Tue, 01 Feb 2005 21:49:14 +0100 From: Laurent Deniel Organization: Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [patch] superfluous CAP_NET_ADMIN required for some ioctl Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@free.fr Precedence: bulk X-list: netdev Hi, It should be possible to obtain bonding information with SIOCBOND[SLAVE]INFOQUERY ioctls without root privilege (like with /proc/net/bonding/bond? or ifconfig). Laurent Signed-off-by: Laurent Deniel --- linux-2.6.9.orig/net/core/dev.c 2005-01-08 17:29:55.000000000 +0100 +++ linux-2.6.9/net/core/dev.c 2005-01-08 18:00:01.000000000 +0100 @@ -2692,8 +2692,6 @@ int dev_ioctl(unsigned int cmd, void __u case SIOCBONDENSLAVE: case SIOCBONDRELEASE: case SIOCBONDSETHWADDR: - case SIOCBONDSLAVEINFOQUERY: - case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: case SIOCBRADDIF: case SIOCBRDELIF: @@ -2705,6 +2703,20 @@ int dev_ioctl(unsigned int cmd, void __u rtnl_unlock(); return ret; + /* + * These ioctl calls: + * - can be done by all. + * - require strict serialization. + * - return a value (but already copied to user) + */ + case SIOCBONDSLAVEINFOQUERY: + case SIOCBONDINFOQUERY: + dev_load(ifr.ifr_name); + rtnl_lock(); + ret = dev_ifsioc(&ifr, cmd); + rtnl_unlock(); + return ret; + case SIOCGIFMEM: /* Get the per device memory space. We can add this but * currently do not support it */ From dcbw@redhat.com Tue Feb 1 13:42:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:42:13 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11Lg8v6032467 for ; Tue, 1 Feb 2005 13:42:09 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j11Lg7wZ025026; Tue, 1 Feb 2005 16:42:07 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j11Lg7O25000; Tue, 1 Feb 2005 16:42:07 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11Lg6QO028445; Tue, 1 Feb 2005 16:42:06 -0500 Subject: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-k4QhFYTzadIYmllFUtUs" Date: Tue, 01 Feb 2005 16:42:06 -0500 Message-Id: <1107294126.17332.16.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-k4QhFYTzadIYmllFUtUs Content-Type: text/plain Content-Transfer-Encoding: 7bit Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct entries in sysfs. Seems like somebody meant to do this but it got lost. atmel_cs.c was previously fixed to pass in the correct struct device * via handle_to_dev() but the driver never actually used it. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; --=-k4QhFYTzadIYmllFUtUs Content-Disposition: attachment; filename=atmel-NETDEV-fix.patch Content-Type: text/x-patch; name=atmel-NETDEV-fix.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; --=-k4QhFYTzadIYmllFUtUs-- From dale@the-martins.org Tue Feb 1 13:56:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:27 -0800 (PST) Received: from smtp3.fuse.net (mail-out3.fuse.net [216.68.8.176]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11LuH1u000747 for ; Tue, 1 Feb 2005 13:56:18 -0800 Received: from gx6.fuse.net ([66.42.247.210]) by smtp3.fuse.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050201215335.QRGY12240.smtp3.fuse.net@gx6.fuse.net> for ; Tue, 1 Feb 2005 16:53:35 -0500 Received: from chinchilla.toadis.porkis ([66.42.247.210]) by gx6.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20050201215302.YRPC26160.gx6.fuse.net@chinchilla.toadis.porkis> for ; Tue, 1 Feb 2005 16:53:02 -0500 Received: from gerbil.toadis.porkis (localhost.localdomain) [192.168.10.2] by chinchilla.toadis.porkis with smtp (Exim 3.35 #1 (Debian)) id 1Cw60F-0000fa-00; Tue, 01 Feb 2005 16:56:07 -0500 Received: by localhost.localdomain (sSMTP sendmail emulation); Tue, 1 Feb 2005 16:56:07 -0500 Date: Tue, 1 Feb 2005 16:56:07 -0500 From: "Dale E. Martin" To: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050201215607.GA8530@gerbil.toadis.porkis> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20050131222342.GB13217@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@the-martins.org Precedence: bulk X-list: netdev --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Typical symptoms: the card works fine until 64 (256) packets are sent > (received) then "Good bye Charlie". Yep, that was it. Recompiled with gcc 3.3 and it seems to be working now, although it looks like the card is only found on cold boots. The irony of this, btw, is that linux/Documentation/Changes still recommends gcc 2.95.3 - even in version 2.6.8, possibly in 2.6.10. (I think I saw it in there but I don't have it handy.) Also, when I first started looking at this, I tried to #define RTL8169_DEBUG but was getting compile errors. Should I file a bug about this? > If it works, I'll gladly welcome an 'lspci -vx' + complete dmesg for my > collection. Attached. The box says "Zonet Gigabit Ethernet 32 bit Adapter" and "Model ZEN3300E". The Linksys card in the lspci output is not connected to anything and I did not load the tulip module that supports it. (I was trying to ease switching back to it since the gigE card kept locking up!) It looks like the poor 1Ghz C3 in this machine is going to be the bottleneck for getting good transfer rates over gigabit ethernet ;-) > Btw, you can test the patch below (on top of 2.4.28, no bad report so far): > http://www.fr.zoreil.com/~romieu/misc/20041209-2.4.28-r8169.c-test.patch What is the intention of this patch? Is it to handle the 2.95.x issue or something else? Thanks for the help! Dale -- Dale E. Martin - dale@the-martins.org http://the-martins.org/~dmartin --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stuff.txt" 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3123 Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, 66Mhz, medium devsel, latency 8 Memory at e0000000 (32-bit, prefetchable) [size=64M] Capabilities: 00: 06 11 23 31 06 00 30 a2 00 00 00 06 00 08 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 cc 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e8000000-e9ffffff Prefetchable memory behind bridge: e4000000-e7ffffff Capabilities: 00: 06 11 91 b0 07 01 30 a2 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: 00 e8 f0 e9 00 e4 f0 e7 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00 00:08.0 SCSI storage controller: BusLogic Flashpoint LT (rev 01) Flags: bus master, fast devsel, latency 32, IRQ 11 I/O ports at d000 [size=256] Memory at eb000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=32K] 00: 4b 10 30 81 07 00 00 00 01 00 00 01 08 20 00 00 10: 01 d0 00 00 00 00 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 08 08 00:09.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) Subsystem: Linksys: Unknown device 0574 Flags: bus master, medium devsel, latency 32, IRQ 7 I/O ports at d400 [size=256] Memory at eb001000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at [disabled] [size=128K] Capabilities: 00: 17 13 85 09 07 00 90 02 11 00 00 02 08 20 00 00 10: 01 d4 00 00 00 10 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 02 02 00 00 17 13 74 05 30: 00 00 00 00 c0 00 00 00 00 00 00 00 07 01 ff ff 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8169 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8169 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 5 I/O ports at d800 [size=256] Memory at eb002000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=128K] Capabilities: 00: ec 10 69 81 07 00 b0 02 10 00 00 02 08 40 00 00 10: 01 d8 00 00 00 20 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 20 40 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at dc00 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 dc 00 00 00 00 00 00 00 00 00 00 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 7 I/O ports at e000 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e0 00 00 00 00 00 00 00 00 00 00 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 07 02 00 00 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at e400 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e4 00 00 00 00 00 00 00 00 00 00 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 03 00 00 00:10.3 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev 82) (prog-if 20) Subsystem: VIA Technologies, Inc.: Unknown device 3104 Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at eb003000 (32-bit, non-prefetchable) [size=256] Capabilities: 00: 06 11 04 31 17 00 10 02 82 20 03 0c 08 20 00 00 10: 00 30 00 eb 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 04 31 30: 00 00 00 00 80 00 00 00 00 00 00 00 03 04 00 00 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177 Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 cc 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at e800 [size=16] Capabilities: 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e8 00 00 00 00 00 00 00 00 00 00 06 11 01 cc 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74) Subsystem: VIA Technologies, Inc.: Unknown device 0102 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ec00 [size=256] Memory at eb004000 (32-bit, non-prefetchable) [size=256] Capabilities: 00: 06 11 65 30 07 00 10 02 74 00 00 02 08 20 00 00 10: 01 ec 00 00 00 40 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 02 01 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 03 08 01:00.0 VGA compatible controller: VIA Technologies, Inc.: Unknown device 3122 (rev 03) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc.: Unknown device 3122 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e4000000 (32-bit, prefetchable) [size=64M] Memory at e8000000 (32-bit, non-prefetchable) [size=16M] Expansion ROM at [disabled] [size=64K] Capabilities: 00: 06 11 22 31 07 00 10 02 03 00 00 03 00 20 00 00 10: 08 00 00 e4 00 00 00 e8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 22 31 30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 01 02 00 Linux version 2.4.28 (root@chinchilla) (gcc version 3.3 (Debian)) #3 Tue Feb 1 16:24:24 EST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000eff0000 (usable) BIOS-e820: 000000000eff0000 - 000000000eff3000 (ACPI NVS) BIOS-e820: 000000000eff3000 - 000000000f000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 239MB LOWMEM available. On node 0 totalpages: 61424 zone(0): 4096 pages. zone(1): 57328 pages. zone(2): 0 pages. ACPI: RSDP (v000 VT9174 ) @ 0x000f6500 ACPI: RSDT (v001 VT9174 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0eff3000 ACPI: FADT (v001 VT9174 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0eff3040 ACPI: DSDT (v001 VT9174 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 Kernel command line: root=/dev/hdb3 ro vga=792 rootflags=data=journal No local APIC present or hardware disabled Initializing CPU#0 Detected 998.323 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1992.29 BogoMIPS Memory: 239484k/245696k available (1840k kernel code, 5824k reserved, 682k data, 140k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After generic, caps: 00803135 80803035 00000000 00000000 CPU: Common caps: 00803135 80803035 00000000 00000000 CPU: Centaur VIA C3 Ezra stepping 09 Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Level Trigger. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20040326 PCI: PCI BIOS revision 2.10 entry at 0xfb0c0, last bus=1 PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S4 S5) 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 [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 *3 4 5 6 7 10 11 12 14 15) PCI: Probing PCI hardware ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 3 PCI: Using ACPI for IRQ routing Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 okir@monad.swb.de). ACPI: Power Button (FF) [PWRF] pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled kmod: failed to exec /sbin/modprobe -s -k parport_lowlevel, errno = 2 lp: driver loaded but no devices found Real Time Clock Driver v1.10f Non-volatile memory driver v1.2 ipmi: message handler initialized FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 189M agpgart: Detected Via CLE266 chipset agpgart: AGP aperture is 64M @ 0xe0000000 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe808-0xe80f, BIOS settings: hdc:pio, hdd:pio hda: WDC WD100BA, ATA DISK drive hdb: ST3200822A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: attached ide-disk driver. hda: host protected area => 1 hda: 19541088 sectors (10005 MB) w/2048KiB Cache, CHS=1216/255/63 hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 390721968 sectors (200050 MB) w/8192KiB Cache, CHS=24321/255/63 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 hdb3 SCSI subsystem driver Revision: 1.00 scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-950 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.02, I/O Address: 0xD000, IRQ Channel: 11/Level scsi0: PCI Bus: 0, Device: 8, Address: 0xEB000000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Fast, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: Error Recovery Strategy: Default, SCSI Bus Reset: Enabled scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled scsi0: *** BusLogic BT-950 Initialized Successfully *** scsi0 : BusLogic BT-950 Vendor: SONY Model: SDX-300C Rev: 0404 Type: Sequential-Access ANSI SCSI revision: 02 scsi0: Target 0: Queue Depth 3, Wide Synchronous at 20.0 MB/sec, offset 15 scsi1 : SCSI host adapter emulation for IDE ATAPI devices st: Version 20040102, bufsize 32768, max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0 usb.c: registered new driver usbdevfs usb.c: registered new driver hub ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 ehci_hcd 00:10.3: irq 3, pci mem cf81d000 usb.c: new USB bus registered, assigned bus number 1 ehci_hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29/2.4 hub.c: USB hub found hub.c: 6 ports detected host/uhci.c: USB Universal Host Controller Interface driver v1.1 host/uhci.c: USB UHCI at I/O 0xdc00, IRQ 11 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xe000, IRQ 7 usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xe400, IRQ 5 usb.c: new USB bus registered, assigned bus number 4 hub.c: USB hub found hub.c: 2 ports detected Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) IPv4 over IPv4 tunneling driver ip_conntrack version 2.1 (1919 buckets, 15352 max) - 288 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with journal data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 140k freed hub.c: new USB device 00:10.3-3, assigned address 2 hub.c: USB hub found hub.c: 4 ports detected hub.c: new USB device 00:10.3-3.3, assigned address 3 usb.c: USB device 3 (vend/prod 0x4a9/0x1056) is not claimed by any active driver. hub.c: new USB device 00:10.3-3.4, assigned address 4 usb.c: USB device 4 (vend/prod 0x4f9/0x16) is not claimed by any active driver. Adding Swap: 506036k swap-space (priority -1) EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,67), internal journal usb.c: registered new driver usblp printer.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04A9 pid 0x1056 printer.c: usblp1: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0016 printer.c: v0.13: USB Printer Device Class driver via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xec00, 00:40:63:c4:b6:ca, IRQ 11. eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. r8169 Gigabit Ethernet driver 1.2 loaded eth1: Identified chip type is 'RTL8169s/8110s'. eth1: RTL8169 at 0xcf882000, 00:08:54:23:fd:2b, IRQ 5 eth1: Auto-negotiation Enabled. eth1: 1000Mbps Full-duplex operation. ttyS0: LSR safety check engaged! ttyS0: LSR safety check engaged! ttyS1: LSR safety check engaged! ttyS1: LSR safety check engaged! kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with journal data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with journal data mode. eth0: Setting full-duplex based on MII #1 link partner capability of 45e1. ttyS0: LSR safety check engaged! ttyS1: LSR safety check engaged! blk: queue c03c7f20, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03c805c, I/O limit 4095Mb (mask 0xffffffff) Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:63:c4:b6:ca:00:e0:d0:00:b7:f2:08:00 SRC=222.88.173.5 DST=10.192.151.130 LEN=666 TOS=0x00 PREC=0x00 TTL=105 ID=34014 PROTO=UDP SPT=14668 DPT=1026 LEN=646 --tThc/1wpZn/ma/RB-- From dcbw@redhat.com Tue Feb 1 13:56:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11Lue4B000842 for ; Tue, 1 Feb 2005 13:56:40 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j11LudKV028943; Tue, 1 Feb 2005 16:56:39 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j11LudO29074; Tue, 1 Feb 2005 16:56:39 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11LucQO029438; Tue, 1 Feb 2005 16:56:38 -0500 Subject: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-L/8SggFIwD8pPmkcRnGZ" Date: Tue, 01 Feb 2005 16:56:38 -0500 Message-Id: <1107294998.17332.30.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-L/8SggFIwD8pPmkcRnGZ Content-Type: text/plain Content-Transfer-Encoding: 7bit Identify different firmware by enums, not strings, as we need to have some integral firmware identifier for choosing maximum rssi values for each different firmware type. Consolidate the information about firmware filenames and capabilities in the atmel module, not in atmel_cs or atmel_pci. Move common prototypes and firmware enum into new atmel.h file. The atmel_cs driver also thought that init_atmel_card() took "int irq" as the first parameter, this is now fixed to be "unsigned short irq". Signed-off-by: Dan Williams --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This software is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table [fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName- revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName- revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020- V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502% s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e% s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table [card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; --=-L/8SggFIwD8pPmkcRnGZ Content-Disposition: attachment; filename=1.atmel-fw-load-cleanup.patch Content-Type: text/x-patch; name=1.atmel-fw-load-cleanup.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This software is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table[fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName-revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName-revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020-V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502%s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e%s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table[card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; --=-L/8SggFIwD8pPmkcRnGZ-- From dcbw@redhat.com Tue Feb 1 13:56:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11LunrI000916 for ; Tue, 1 Feb 2005 13:56:50 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j11LunqY029065; Tue, 1 Feb 2005 16:56:49 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j11LunO29141; Tue, 1 Feb 2005 16:56:49 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11LunQO029445; Tue, 1 Feb 2005 16:56:49 -0500 Subject: [PATCH 2.6.11-rc2 2/2] wireless: WEXT quality cleanups + max rssi level fix for at76c502e From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-8QNotCicUS/LDXwth6Ty" Date: Tue, 01 Feb 2005 16:56:48 -0500 Message-Id: <1107295008.17332.32.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-8QNotCicUS/LDXwth6Ty Content-Type: text/plain Content-Transfer-Encoding: 7bit Use correct maximum rssi level for at76c502e-type cards, and correct values in the qual.updated field to more closely match the current Wireless Extensions API. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv- >wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) --=-8QNotCicUS/LDXwth6Ty Content-Disposition: attachment; filename=2.atmel-502e-quality-fix.patch Content-Type: text/x-patch; name=2.atmel-502e-quality-fix.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv->wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) --=-8QNotCicUS/LDXwth6Ty-- From romieu@fr.zoreil.com Tue Feb 1 14:34:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 14:34:30 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11MYMlc002905 for ; Tue, 1 Feb 2005 14:34:23 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j11MVJOX007747; Tue, 1 Feb 2005 23:31:19 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j11MV9Oq007746; Tue, 1 Feb 2005 23:31:09 +0100 Date: Tue, 1 Feb 2005 23:31:09 +0100 From: Francois Romieu To: "Dale E. Martin" Cc: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050201223109.GA2957@electric-eye.fr.zoreil.com> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> <20050201215607.GA8530@gerbil.toadis.porkis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201215607.GA8530@gerbil.toadis.porkis> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1163 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 Dale E. Martin : [...] > although it looks like the card is only found on cold boots. Can you send (or put on a webpage) the same dmesg and lspci -vx when it happens ? > The irony of this, btw, is that linux/Documentation/Changes still > recommends gcc 2.95.3 - even in version 2.6.8, possibly in 2.6.10. (I > think I saw it in there but I don't have it handy.) You saw it there. No comment. > Also, when I first started looking at this, I tried to #define > RTL8169_DEBUG but was getting compile errors. Should I file a bug about > this ? I lost this one. Re-added to the queue. Don't bother with a PR for it. [...] > It looks like the poor 1Ghz C3 in this machine is going to be the > bottleneck for getting good transfer rates over gigabit ethernet ;-) It depends on the kind of transfer. A bigger MTU really helps. So does TSO and checksumming but it is really dependant on the kind of load. This is the content of the patch against 2.4.28. [...] > What is the intention of this patch? Is it to handle the 2.95.x issue or > something else ? See above. Can you: - send me discretly the .o built from the r8169 sources with 2.95.3 ? - pest me until you have a 2.95.3 compiled r8169 module which does not lock up any more ? -- Ueimor From tgraf@suug.ch Tue Feb 1 14:44:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 14:44:25 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11MiIM3003709 for ; Tue, 1 Feb 2005 14:44:19 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id DE0B882; Tue, 1 Feb 2005 23:43:54 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 7FD4C1C0EA; Tue, 1 Feb 2005 23:44:36 +0100 (CET) Date: Tue, 1 Feb 2005 23:44:36 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201224436.GO31837@postel.suug.ch> References: <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107263612.1095.598.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > Let the meta action do that. Just set the skb->tc_classid in my opinion; > recall we can change classid now .. True, I don't really care but it's already quite confusing. The priority of the packet is described in viarous field depeding on which qdisc/cls being used, we have skb->priority with sch_prio, tc_index for dsmark and cls_tcindex and now tc_classid directly. Some even use u32 to match on DSCP and set a nfmark. I can already feel the perfect confusion once we open up access for rt_classid, realm and other routing fields. I'm always aiming for easy to understand solutions, this doesn't mean it to be simple. Why is nfmark so heavly used? Because it's damn simple to undertand, you can set and read it and that's it. The only thing one has to care about is to make sure that is actually gets set before it being read and to make sure all userspace apps read it in the same base ;-> (This is basically one of the issue in usability, the lack of clearliness in what base number are read the displayed. Often they get displayed in hex without a 0x prefix but are read with strtol(...,0) resulting in a decimal reading if no prefix is specified) Long rant short statement, I'm pleading for a generic way to transfer such things between a classifier and a qdisc because it's simply easier to explain and use. ... eaction meta set tc_index ip_saddr_proto_hash ... qdisc sfq tcindex-hash where ip_saddr_proto_hash is not a variable but rather a special meta value calulated in the kernel. > You can let the user define that via tc but have a default; > eg: > tc dev eth0 add sfq ematch > tc dev eth0 set sfq pertub xxx > > match u32 ... > ematch sfq > ematch meta classid 1:2 > eaction meta set tcindex 101 > eaction meta set fwmark .. I think we're on the same road or at least going into the same direction. However I'm not sure whether it's a good to have ematches return some values besides true/false. I'd rather like to see an eaction store it in the skb and the sfq catching it up again. Of course we can have the userspace part be configured within the sfq. From davem@davemloft.net Tue Feb 1 15:10:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 15:10:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11NAYUq004892 for ; Tue, 1 Feb 2005 15:10:35 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cw74R-0005gg-00; Tue, 01 Feb 2005 15:04:31 -0800 Date: Tue, 1 Feb 2005 15:04:30 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: design for TSO performance fix Message-Id: <20050201150430.309978b6.davem@davemloft.net> In-Reply-To: <20050128015751.GT31837@postel.suug.ch> References: <20050127163146.33b01e95.davem@davemloft.net> <20050128015751.GT31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 28 Jan 2005 02:57:51 +0100 Thomas Graf wrote: > > static inline int tcp_skb_data_all_paged(struct sk_buff *skb) > > { > > return (skb->len == skb->data_len); > > } > > You could also define this as (skb_headlen(skb) == 0) Good point, I'll do it that way. > I assume the case when reroute changes oif to a device no > longer capable of SG+CSUM stays the same and the skb remains > paged until dev_queue_xmit? That's correct. The only difference is that the TSO building path of send queue transmit will not be executed. I'm slowly piecing together an implementation. The most non- trivial aspect is the frame pushing logic. While building the queue from userspace, we wish to defer until either 1) the user will not supply more data or 2) there is enough in the send queue for an optimally sized TSO frame to be built. For the curious, there is attached my current state of implementation. It's very raw, but it starts to give the basic ideas. The first attachment are the design notes I've been jotting down casually while thinking about this, and the second is the rough beginnings of a patch. The patch implements the tp->tso_goal calculations, and the TSO segmentizer, but nothing else. The missing pieces are: 1) the push-pending-frames logic, it requires the most thought 1.5) the code in tcp_write_xmit() that tries to call the TSO segmenter with groups of SKBs to send 2) killing of tp->mss_cache_std, use tp->mss_cache for everything 3) kill all the code disabling TSO during packet drops 4) kill all the pcount stuff I'll continue trying to make more progress with this thing. --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: text/plain; name="tcp_tso.txt" Content-Disposition: attachment; filename="tcp_tso.txt" Content-Transfer-Encoding: 7bit Maintain some "TSO potential" state during segmentation at sendmsg()/sendpage() time. Use this at push-pending-frames time to defer tcp_write_xmit() calls and control it's behavior. Add tcp_flush_queue() which doesn't try to optimize TSO, it is invoked when getting packets out is more important than producing larger TSO chunks. These two cases are: 1) At end of sendmsg()/sendpage() call without MSG_MORE, indicating that we have no way to know for sure if the user will queue up more TCP data to send. 2) When sleeping within sendmsg()/sendpage() waiting for memory. Pushing out packets and receiving the ACKs may very well be the event that will free up send queue space for us. (Must consider interactions with Nagle and Minshall rules) Consider tcp_opt state which keeps a "TSO goal", it must be in sync with tcp_opt MSS state. Initially define "TSO goal" using tcp_tso_win_divisor and the current congestion window. Formally this is: max(1U, CWND / TCP_TSO_WIN_DIVISOR) We could either maintain this lazily, costing us a divide each time it is recalculated. Or, we can update it incrementally each time snd_cwnd is updated. To save some state testing during output decisions, define "TSO goal" as one for non-TSO flows. Possible send test logic: if (no new data possibly coming from user) send_now(); if (sending due to ACK queue advancement) send_now(); send_tso_goal_sized_chunks(); --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: application/octet-stream; name="diff" Content-Disposition: attachment; filename="diff" Content-Transfer-Encoding: base64 PT09PT0gaW5jbHVkZS9saW51eC90Y3AuaCAxLjM0IHZzIGVkaXRlZCA9PT09PQotLS0gMS4zNC9p bmNsdWRlL2xpbnV4L3RjcC5oCTIwMDUtMDEtMTcgMTQ6MDk6MzMgLTA4OjAwCisrKyBlZGl0ZWQv aW5jbHVkZS9saW51eC90Y3AuaAkyMDA1LTAxLTMxIDE2OjAzOjMyIC0wODowMApAQCAtMjYyLDYg KzI2Miw3IEBACiAJX191MzIJcG10dV9jb29raWU7CS8qIExhc3QgcG10dSBzZWVuIGJ5IHNvY2tl dAkJKi8KIAlfX3UzMgltc3NfY2FjaGU7CS8qIENhY2hlZCBlZmZlY3RpdmUgbXNzLCBub3QgaW5j bHVkaW5nIFNBQ0tTICovCiAJX191MTYJbXNzX2NhY2hlX3N0ZDsJLyogTGlrZSBtc3NfY2FjaGUs IGJ1dCB3aXRob3V0IFRTTyAqLworCV9fdTE2CXRzb19nb2FsOwkvKiBUU08gcGFja2V0IGNvdW50 IGdvYWwsIDEgdy9ub24tVFNPIHBhdGhzICovCiAJX191MTYJbXNzX2NsYW1wOwkvKiBNYXhpbWFs IG1zcywgbmVnb3RpYXRlZCBhdCBjb25uZWN0aW9uIHNldHVwICovCiAJX191MTYJZXh0X2hlYWRl cl9sZW47CS8qIE5ldHdvcmsgcHJvdG9jb2wgb3ZlcmhlYWQgKElQL0lQdjYgb3B0aW9ucykgKi8K IAlfX3UxNglleHQyX2hlYWRlcl9sZW47LyogT3B0aW9ucyBkZXBlbmRpbmcgb24gcm91dGUgKi8K PT09PT0gbmV0L2lwdjQvdGNwX291dHB1dC5jIDEuNzcgdnMgZWRpdGVkID09PT09Ci0tLSAxLjc3 L25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA1LTAxLTE4IDEyOjIzOjM2IC0wODowMAorKysgZWRp dGVkL25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA1LTAyLTAxIDE0OjMyOjQ2IC0wODowMApAQCAt NzA3LDE1ICs3MDcsMTAzIEBACiAJCWlmIChmYWN0b3IgPiBsaW1pdCkKIAkJCWZhY3RvciA9IGxp bWl0OwogCi0JCXRwLT5tc3NfY2FjaGUgPSBtc3Nfbm93ICogZmFjdG9yOworCQkvKiBJZiB0aGlz IGV2ZXIgdHJpZ2dlcnMsIGNoYW5nZSB0cC0+dHNvX2dvYWwgdG8KKwkJICogYSBsYXJnZXIgdHlw ZSBhbmQgdXBkYXRlIHRoaXMgYnVnIGNoZWNrLgorCQkgKi8KKwkJQlVHX09OKGZhY3RvciA+IDY1 NTM1KTsKIAotCQltc3Nfbm93ID0gdHAtPm1zc19jYWNoZTsKLQl9CisJCXRwLT50c29fZ29hbCA9 IGZhY3RvcjsKKwl9IGVsc2UKKwkJdHAtPnRzb19nb2FsID0gMTsKIAogCWlmICh0cC0+ZWZmX3Nh Y2tzKQogCQltc3Nfbm93IC09IChUQ1BPTEVOX1NBQ0tfQkFTRV9BTElHTkVEICsKIAkJCSAgICAo dHAtPmVmZl9zYWNrcyAqIFRDUE9MRU5fU0FDS19QRVJCTE9DSykpOwogCXJldHVybiBtc3Nfbm93 OworfQorCitzdGF0aWMgaW5saW5lIGludCB0Y3Bfc2tiX2RhdGFfYWxsX3BhZ2VkKHN0cnVjdCBz a19idWZmICpza2IpCit7CisJcmV0dXJuIHNrYl9oZWFkbGVuKHNrYikgPT0gMDsKK30KKworLyog SWYgcG9zc2libGUsIGFwcGVuZCBwYWdlZCBkYXRhIG9mIFNSQ19TS0Igb250byB0aGUKKyAqIHRh aWwgb2YgRFNUX1NLQi4KKyAqLworc3RhdGljIGludCBza2JfYXBwZW5kX3BhZ2VzKHN0cnVjdCBz a19idWZmICpkc3Rfc2tiLCBzdHJ1Y3Qgc2tfYnVmZiAqc3JjX3NrYikKK3sKKwlpbnQgaTsKKwor CWlmICghdGNwX3NrYl9kYXRhX2FsbF9wYWdlZChzcmNfc2tiKSkKKwkJcmV0dXJuIC1FSU5WQUw7 CisKKwlmb3IgKGkgPSAwOyBpIDwgc2tiX3NoaW5mbyhzcmNfc2tiKS0+bnJfZnJhZ3M7IGkrKykg eworCQlza2JfZnJhZ190ICpzcmNfZnJhZyA9ICZza2Jfc2hpbmZvKHNyY19za2IpLT5mcmFnc1tp XTsKKwkJc2tiX2ZyYWdfdCAqZHN0X2ZyYWc7CisJCWludCBkc3RfZnJhZ19pZHg7CisKKwkJZHN0 X2ZyYWdfaWR4ID0gc2tiX3NoaW5mbyhkc3Rfc2tiKS0+bnJfZnJhZ3M7CisKKwkJaWYgKHNrYl9j YW5fY29hbGVzY2UoZHN0X3NrYiwgZHN0X2ZyYWdfaWR4LAorCQkJCSAgICAgc3JjX2ZyYWctPnBh Z2UsIHNyY19mcmFnLT5wYWdlX29mZnNldCkpIHsKKwkJCWRzdF9mcmFnID0gJnNrYl9zaGluZm8o ZHN0X3NrYiktPmZyYWdzW2RzdF9mcmFnX2lkeC0xXTsKKwkJCWRzdF9mcmFnLT5zaXplICs9IHNy Y19mcmFnLT5zaXplOworCQl9IGVsc2UgeworCQkJaWYgKGRzdF9mcmFnX2lkeCA+PSBNQVhfU0tC X0ZSQUdTKQorCQkJCXJldHVybiAtRU1TR1NJWkU7CisKKwkJCWRzdF9mcmFnID0gJnNrYl9zaGlu Zm8oZHN0X3NrYiktPmZyYWdzW2RzdF9mcmFnX2lkeF07CisJCQlza2Jfc2hpbmZvKGRzdF9za2Ip LT5ucl9mcmFncyA9IGRzdF9mcmFnX2lkeCArIDE7CisKKwkJCWRzdF9mcmFnLT5wYWdlID0gc3Jj X2ZyYWctPnBhZ2U7CisJCQlnZXRfcGFnZShzcmNfZnJhZy0+cGFnZSk7CisKKwkJCWRzdF9mcmFn LT5wYWdlX29mZnNldCA9IHNyY19mcmFnLT5wYWdlX29mZnNldDsKKwkJCWRzdF9mcmFnLT5zaXpl ID0gc3JjX2ZyYWctPnNpemU7CisJCX0KKwkJZHN0X3NrYi0+ZGF0YV9sZW4gKz0gc3JjX2ZyYWct PnNpemU7CisJfQorCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBzdHJ1Y3Qgc2tfYnVmZiAqdGNw X3Rzb19idWlsZChzdHJ1Y3Qgc2tfYnVmZiAqaGVhZCwgaW50IG1zcywgaW50IG51bSkKK3sKKwlz dHJ1Y3Qgc2tfYnVmZiAqc2tiOworCXN0cnVjdCBzb2NrICpzazsKKwlpbnQgZXJyOworCisJc2sg PSBoZWFkLT5zazsKKwlza2IgPSBhbGxvY19za2Ioc2stPnNrX3Byb3QtPm1heF9oZWFkZXIsIEdG UF9BVE9NSUMpOworCWVyciA9IC1FTk9NRU07CisJaWYgKCFza2IpCisJCWdvdG8gZmFpbDsKKwor CWVyciA9IDA7CisJc2tiX3NoaW5mbyhza2IpLT50c29fc2l6ZSA9IG1zczsKKwlza2Jfc2hpbmZv KHNrYiktPnRzb19zZWdzID0gbnVtOworCXdoaWxlIChudW0tLSkgeworCQllcnIgPSBza2JfYXBw ZW5kX3BhZ2VzKHNrYiwgaGVhZCk7CisJCWlmIChlcnIpCisJCQlnb3RvIGZhaWw7CisKKwkJaGVh ZCA9IGhlYWQtPm5leHQ7CisJfQorCXJldHVybiBza2I7CisKK2ZhaWw6CisJaWYgKHNrYikgewor CQlpbnQgaTsKKworCQlmb3IgKGkgPSAwOyBpIDwgc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFnczsg aSsrKSB7CisJCQlza2JfZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07 CisKKwkJCXB1dF9wYWdlKGZyYWctPnBhZ2UpOworCQl9CisKKwkJa2ZyZWVfc2tiKHNrYik7CisJ fQorCXJldHVybiBOVUxMOwogfQogCiAvKiBUaGlzIHJvdXRpbmUgd3JpdGVzIHBhY2tldHMgdG8g dGhlIG5ldHdvcmsuICBJdCBhZHZhbmNlcyB0aGUK --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9-- From oxymoron@waste.org Tue Feb 1 15:23:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 15:23:05 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11NN16q005580 for ; Tue, 1 Feb 2005 15:23:01 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j11NMkAl024732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 17:22:46 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j11NMjD0024728; Tue, 1 Feb 2005 17:22:45 -0600 Date: Tue, 1 Feb 2005 15:22:45 -0800 From: Matt Mackall To: Lorenzo Hern?ndez Garc?a-Hierro Cc: Valdis.Kletnieks@vt.edu, Adrian Bunk , Arjan van de Ven , Stephen Hemminger , "linux-kernel@vger.kernel.org" , Chris Wright , netdev@oss.sgi.com, Hank Leininger Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050201232245.GB17460@waste.org> References: <1106932637.3778.92.camel@localhost.localdomain> <20050128100229.5c0e4ea1@dxpl.pdx.osdl.net> <1106937110.3864.5.camel@localhost.localdomain> <20050128105217.1dc5ef42@dxpl.pdx.osdl.net> <1106944492.3864.30.camel@localhost.localdomain> <1106945266.7776.41.camel@laptopd505.fenrus.org> <200501290915.j0T9FkVY012948@turing-police.cc.vt.edu> <20050131165025.GN18316@stusta.de> <200501311942.j0VJgIYs016952@turing-police.cc.vt.edu> <1107201800.3754.125.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107201800.3754.125.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1166 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 On Mon, Jan 31, 2005 at 09:03:19PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote: > Arjan, I will give it a further look, is there anything you want to > comment about it before I start? > > I will re-code it to put the helper functions in random.c. Do it against -mm, please, there are something like 30 patches against random.c there already. And please cc: me on any changes there. -- Mathematics is the supreme nostalgia of our time. From jgarzik@pobox.com Tue Feb 1 17:34:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:34:28 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j121YNK3013297 for ; Tue, 1 Feb 2005 17:34:24 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9PR-00056C-8c; Wed, 02 Feb 2005 01:34:21 +0000 Message-ID: <42002E00.6000101@pobox.com> Date: Tue, 01 Feb 2005 20:33:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> In-Reply-To: <1107294126.17332.16.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1167 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 Dan Williams wrote: > Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct > entries in sysfs. Seems like somebody meant to do this but it got lost. > atmel_cs.c was previously fixed to pass in the correct struct device * > via handle_to_dev() but the driver never actually used it. > > Signed-off-by: Dan Williams > > --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 > +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 > @@ -1579,6 +1579,8 @@ > dev->irq = irq; > dev->base_addr = port; > > + SET_NETDEV_DEV(dev, sys_dev); > + > if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { > printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); > goto err_out_free; > > Can you please resend all your patches with _just_ the patch inline, rather than both inline and attached? Your emails break my scripts, since the scripts try to apply both. Jeff From dcbw@redhat.com Tue Feb 1 17:41:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:41:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j121f43q013859 for ; Tue, 1 Feb 2005 17:41:04 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j121f3VY020117; Tue, 1 Feb 2005 20:41:03 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j121f3O25367; Tue, 1 Feb 2005 20:41:03 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j121f2QO012134; Tue, 1 Feb 2005 20:41:02 -0500 Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: Jeff Garzik Cc: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk In-Reply-To: <42002E00.6000101@pobox.com> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> Content-Type: text/plain Date: Tue, 01 Feb 2005 20:41:02 -0500 Message-Id: <1107308462.20243.1.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev And both evolution and pine screw up the patches inline and break the line at odd places... at least, that's what I see... you don't mind if you have to do a little surgery here and there? Dan On Tue, 2005-02-01 at 20:33 -0500, Jeff Garzik wrote: > Dan Williams wrote: > > Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct > > entries in sysfs. Seems like somebody meant to do this but it got lost. > > atmel_cs.c was previously fixed to pass in the correct struct device * > > via handle_to_dev() but the driver never actually used it. > > > > Signed-off-by: Dan Williams > > > > --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 > > +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 > > @@ -1579,6 +1579,8 @@ > > dev->irq = irq; > > dev->base_addr = port; > > > > + SET_NETDEV_DEV(dev, sys_dev); > > + > > if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { > > printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); > > goto err_out_free; > > > > > > Can you please resend all your patches with _just_ the patch inline, > rather than both inline and attached? > > Your emails break my scripts, since the scripts try to apply both. > > Jeff > > > From jgarzik@pobox.com Tue Feb 1 17:48:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:48:52 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j121mluT017006 for ; Tue, 1 Feb 2005 17:48:48 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9dN-0005oA-E6; Wed, 02 Feb 2005 01:48:45 +0000 Message-ID: <4200316F.7030401@pobox.com> Date: Tue, 01 Feb 2005 20:48:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [0/8] orinoco driver updates References: <20050112052352.GA30426@localhost.localdomain> In-Reply-To: <20050112052352.GA30426@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1169 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 David Gibson wrote: > Following are a bunch of patches which make a few more steps towards > the long overdue merge of the CVS orinoco driver into mainline. These > do make behavioural changes to the driver, but they should all be > trivial and largely cosmetic. OK, the changes look good, but I was waiting for the previous stuff you submitted to land in upstream. Could I convince you to rediff and resend against the latest 2.6.x snapshot? At the time you sent these, they conflicted with a previous cleanup you had sent, and that I had applied. Jeff From jgarzik@pobox.com Tue Feb 1 17:53:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:53:06 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j121r1Fg018855 for ; Tue, 1 Feb 2005 17:53:02 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9hS-000666-NA; Wed, 02 Feb 2005 01:52:58 +0000 Message-ID: <4200326D.2000801@pobox.com> Date: Tue, 01 Feb 2005 20:52:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> In-Reply-To: <1107308462.20243.1.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1170 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 Dan Williams wrote: > And both evolution and pine screw up the patches inline and break the > line at odd places... at least, that's what I see... you don't mind if > you have to do a little surgery here and there? This is why we have request a common patch format -- because otherwise, everybody would request just-a-little-surgery-here-and-there. It's much easier in the long run to get people to find solutions (pine+vi or mutt or Mozilla Mail) that work, than to hope that a maintainer will know and fix up each submittor's mailer's eccentricities. Jeff From dave@thedillows.org Tue Feb 1 18:56:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 18:57:03 -0800 (PST) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j122uqcV019656 for ; Tue, 1 Feb 2005 18:56:57 -0800 Received: (qmail 16152 invoked by uid 0); 2 Feb 2005 02:56:51 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp7.knology.net with SMTP; 2 Feb 2005 02:56:51 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j122v0Mh005963; Tue, 1 Feb 2005 21:57:01 -0500 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j122v0js005962; Tue, 1 Feb 2005 21:57:00 -0500 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: David Dillow To: Dan Williams Cc: Jeff Garzik , Netdev , jgarzik@redhat.com, simon@thekelleys.org.uk In-Reply-To: <1107308462.20243.1.camel@dcbw.boston.redhat.com> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 01 Feb 2005 21:57:00 -0500 Message-Id: <1107313020.5888.1.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 20:41 -0500, Dan Williams wrote: > And both evolution and pine screw up the patches inline and break the > line at odd places... at least, that's what I see... you don't mind if > you have to do a little surgery here and there? Have you tried setting the format to "Preformat", and using Insert->Insert File... ? This is a really long line entered in "preformat" mode, and notice it doesn't wrap (if you look at it in text.) -- David Dillow From jgarzik@pobox.com Tue Feb 1 21:29:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:29:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j125TfjQ029387 for ; Tue, 1 Feb 2005 21:29:42 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwD59-0000Ud-M7; Wed, 02 Feb 2005 05:29:39 +0000 Message-ID: <42006535.4020309@pobox.com> Date: Wed, 02 Feb 2005 00:29:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sfeldma@pobox.com CC: netdev@oss.sgi.com, lunz@falooley.org Subject: Re: [PATCH 2.6] e100: remove reference to NAPI config option References: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> In-Reply-To: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Feb 1 21:29:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:29:54 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j125TnFc029400 for ; Tue, 1 Feb 2005 21:29:50 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwD5F-0000Uj-US; Wed, 02 Feb 2005 05:29:46 +0000 Message-ID: <4200653B.5040302@pobox.com> Date: Wed, 02 Feb 2005 00:29:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Porter CC: akpm@osdl.org, netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: Re: [PATCH][NET] Add PPC440SP support to IBM EMAC driver References: <20050131171009.F25809@cox.net> In-Reply-To: <20050131171009.F25809@cox.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Feb 1 21:35:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:35:51 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j125Zb1b030403 for ; Tue, 1 Feb 2005 21:35:45 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwDAt-0000ol-AT; Wed, 02 Feb 2005 05:35:35 +0000 Message-ID: <42006699.3040508@pobox.com> Date: Wed, 02 Feb 2005 00:35:21 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com, corey@world.std.com Subject: Re: [PATCH 2/2] ray_cs: reduce stack usage (sockaddr) References: <41FAB900.5020502@osdl.org> In-Reply-To: <41FAB900.5020502@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From SRS0+18c37aa9fd0904e0caa1+528+infradead.org+hch@pentafluge.srs.infradead.org Wed Feb 2 01:38:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 01:38:16 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j129cB3Q006816 for ; Wed, 2 Feb 2005 01:38:12 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1CwGxb-0003Nb-RJ; Wed, 02 Feb 2005 09:38:07 +0000 Date: Wed, 2 Feb 2005 09:38:07 +0000 From: Christoph Hellwig To: Jeff Garzik Cc: Dan Williams , netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV Message-ID: <20050202093807.GA12946@infradead.org> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> <4200326D.2000801@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4200326D.2000801@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Tue, Feb 01, 2005 at 08:52:45PM -0500, Jeff Garzik wrote: > It's much easier in the long run to get people to find solutions > (pine+vi or mutt or Mozilla Mail) that work, than to hope that a > maintainer will know and fix up each submittor's mailer's eccentricities. Mozilla Mail is fucked up for sending patches aswell. From jgarzik@pobox.com Wed Feb 2 01:59:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 01:59:21 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j129xGYk007602 for ; Wed, 2 Feb 2005 01:59:16 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwHI2-0005H0-RV; Wed, 02 Feb 2005 09:59:14 +0000 Message-ID: <4200A465.9090100@pobox.com> Date: Wed, 02 Feb 2005 04:59:01 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Dan Williams , netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> <4200326D.2000801@pobox.com> <20050202093807.GA12946@infradead.org> In-Reply-To: <20050202093807.GA12946@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1176 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 Christoph Hellwig wrote: > On Tue, Feb 01, 2005 at 08:52:45PM -0500, Jeff Garzik wrote: > >>It's much easier in the long run to get people to find solutions >>(pine+vi or mutt or Mozilla Mail) that work, than to hope that a >>maintainer will know and fix up each submittor's mailer's eccentricities. > > > Mozilla Mail is fucked up for sending patches aswell. Works for me. Jeff From adobriyan@mail.ru Wed Feb 2 02:35:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 02:35:09 -0800 (PST) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12AZ222009237 for ; Wed, 2 Feb 2005 02:35:03 -0800 Received: from [217.10.38.130] (port=41316 helo=mipter.zuzino.mipt.ru) by mx1.mail.ru with esmtp id 1CwHqb-000C3s-00; Wed, 02 Feb 2005 13:34:57 +0300 From: Alexey Dobriyan To: prism54-private@prism54.org Subject: [PATCH] prism54: use initialized current_time in debug_code Date: Wed, 2 Feb 2005 13:34:41 +0200 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200502021334.41648.adobriyan@mail.ru> X-Spam: Not detected X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@mail.ru Precedence: bulk X-list: netdev Otherwise gcc 4 complains: drivers/net/wireless/prism54/isl_38xx.c: In function ‘isl38xx_trigger_device’: drivers/net/wireless/prism54/isl_38xx.c:131: warning: ‘current_time.tv_sec’ is used uninitialized in this function drivers/net/wireless/prism54/isl_38xx.c:131: warning: ‘current_time.tv_usec’ is used uninitialized in this function Signed-off-by: Alexey Dobriyan --- linux-2.6.11-rc2-bk10/drivers/net/wireless/prism54/isl_38xx.c.orig 2005-02-02 13:20:57.000000000 +0200 +++ linux-2.6.11-rc2-bk10/drivers/net/wireless/prism54/isl_38xx.c 2005-02-02 13:24:25.000000000 +0200 @@ -112,7 +112,9 @@ isl38xx_handle_wakeup(isl38xx_control_bl void isl38xx_trigger_device(int asleep, void __iomem *device_base) { +#if VERBOSE > SHOW_ERROR_MESSAGES struct timeval current_time; +#endif u32 reg, counter = 0; #if VERBOSE > SHOW_ERROR_MESSAGES @@ -126,11 +128,10 @@ isl38xx_trigger_device(int asleep, void do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", current_time.tv_sec, current_time.tv_usec); -#endif - DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", current_time.tv_sec, current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); reg = readl(device_base + ISL38XX_INT_IDENT_REG); @@ -148,10 +149,13 @@ isl38xx_trigger_device(int asleep, void counter++; } +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", current_time.tv_sec, current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); #if VERBOSE > SHOW_ERROR_MESSAGES From tgraf@suug.ch Wed Feb 2 05:27:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 05:28:07 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12DRvN1021710 for ; Wed, 2 Feb 2005 05:27:58 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 5978182; Wed, 2 Feb 2005 14:27:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id A5C4C1C0EA; Wed, 2 Feb 2005 14:28:16 +0100 (CET) Date: Wed, 2 Feb 2005 14:28:16 +0100 From: Thomas Graf To: Andy Furniss Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202132816.GP31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> <20050201133138.GM31837@postel.suug.ch> <41FF9A55.4080005@dsl.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FF9A55.4080005@dsl.pipex.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > >>WRT policers I never figured out where you would put the effects of > >>playing with the burst size parameter and it's effects with few/many > >>connections and any burstiness caused into an equasion like that. > > > > > >A burst buffer has impact on R on later packets, it can "smooth" R > >and X and thus results in more stable rates. Depending on the actual > >burst, it can avoid retransmits which stabilizes the rate as well. > > But it's not a real rate limiting buffer in the policer case is it? Abstractly speaking, burst specifies the maximum amount of time allowed for a single packet to sit in the burst buffer. Although the burst is configured as the size of the buffer it is transformed into a time delta before providing it to the kernel. Because the policer doesn't enqueue things the packet simply gets dropped if it would exceed that time. It's not _exactly_ like this but it gives you an idea what happens, net/sched/police.c isn't that big so one coffee should do it. > Nice - are you planning to add anything to tweak things for the wrong > end of the bottleneck problems? I hope so, once I figured out an acceptable compromise between a good result and simplicity. Currently it would be way to expensive and hard to use. From olh@suse.de Wed Feb 2 05:38:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 05:39:03 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12DcvqQ022468 for ; Wed, 2 Feb 2005 05:38:58 -0800 Received: from hermes.suse.de (hermes-ext.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 ED7A713F052B for ; Wed, 2 Feb 2005 14:38:51 +0100 (CET) Date: Wed, 2 Feb 2005 14:38:51 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: limited number if iptable rules on 64bit hosts Message-ID: <20050202133851.GA9680@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev What buffer or sysctrl value has to change to allow more than 3445 rules like this (on a 64bit host with 64bit iptables)? iptables -A FORWARD -j ACCEPT setsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524368) = -1 ENOMEM (Cannot allocate memory) I see this with 2.6.5 and 2.6.11. From hadi@cyberus.ca Wed Feb 2 06:05:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 06:05:29 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12E5MNd023594 for ; Wed, 2 Feb 2005 06:05:22 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CwL8A-0002jG-0E for netdev@oss.sgi.com; Wed, 02 Feb 2005 09:05:18 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CwL81-0000TH-M9; Wed, 02 Feb 2005 09:05:09 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <41FF97E9.7040501@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> <41FF97E9.7040501@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107353106.1098.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Feb 2005 09:05:06 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 09:53, Andy Furniss wrote: > jamal wrote: > > I know for a while the Bart howto was mislabeling the meaning of > > policing - not sure about shaping. > > Shaping has a precise definition that involves a queue and a > > non-working-conserving scheduler in order to rate control. This doesnt > > matter where it happens (egress or ingress). Policing on the other hand > > is work conserving etc. > > Ok, but shaping to LARTC posters means being able to classify traffic > and set up sharing/priorotising of classes. > > This is the reason most need > to be able to queue - they want to use htb/hfsc for complicated setups Close - but you are missing the rate control requirement. You can do the above with prio qdisc for example but that does not equate to shaping. Understood about Lartc users definitions. However, note that they are influenced by what people tell them or what people write in docs. Help in making sure the redefinition doesnt propagate. Theres a very precise meaning to shaping and it is _exactly_ the way i described it above. Clue people who ask questions. > and until now were not aware that it was even possible to replicate this > in policers I am sure i have written about 50 emails on this topic over the last 5 years;-> look at the archives. I even joked about it here: http://www.cyberus.ca/~hadi/patches/action/README over 2 years ago. look at the text reading "it must be the summer heat again; weve had someone doing that every year around summer" Unfortunately people who are writting docs havent picked it up for whatever reasons. I am hoping we finaly get this documented somewhere. Can you help fix this? > and if it becomes feasable it will probably appear daunting > to do compared with HTB and all the existing docs/scripts. > >From a usability perspective i agree with you. Its still doable is all i can say ;-> (but you are correct in that it may not be for the weak hearts) As a reminder of some of the big discussions on shared and hierachical policing - look at the many many discussions I had with devik on this topic a few years back. It resulted in the birth of HTB (which is essentially a hierachy of the same token bucket meters used in policers; hierachical shared policers are doable - look at iproute2/examples/diffserv). HTB otoh has proven useful due to simplicty - so it stands on its own merit now. I think there may be peculiar occasions where you may need to have queues to shape traffic to a local app - but thats peculiar. > For me, I think queuing and dropping is better than just dropping, you > can affect tcp by delaying eg. 1 ack per packet rather than delayed acks > and clocking out the packets helps smooth burstiness, True - but i question the usefulness of localy terminating TCP packets being shaped. For packets being forwarded, the shaping happens on egress. > which hurts > latency if you are doing traffic control from the wrong end of the > bottleneck. > Not sure i followed the latency connection. > As long as I could use netfilter to mark/classify connections then I > think I can sort my setup, don't know about others. > > Great. yes, you can. > > Are pre/post routing sufficient as netfilter hooks for your case? > > Yes but depends on where in pre/postrouting. For me after/before nat, as > I say above though I could workaround if I classify connections with > netfilter. For others as long as they can filter on a mark/classify set > in forward, then I think it will be OK for them. > You can mark in netfilter or even in tc and use those marks in both places. > I am not sure what exactly can can't be done in your example: > > ># 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 \ > > What I can do here depends where it hooks packets. > > >action ipt -j MARK --set-mark 1 \ > > I don't know what table I am using - may be OK as long as I can test for > a mark I made earlier in the egress dummy case or test connmark/state I > set for that connection in the ingress case. > That would be doable. Thanks for taking the time Andy. cheers, jamal From hadi@cyberus.ca Wed Feb 2 06:25:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 06:25:09 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12EP40r024788 for ; Wed, 2 Feb 2005 06:25:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CwLRE-0007c5-Ox for netdev@oss.sgi.com; Wed, 02 Feb 2005 09:25:00 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CwLR9-0003wg-PL; Wed, 02 Feb 2005 09:24:56 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050201224436.GO31837@postel.suug.ch> References: <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107354293.1105.85.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Feb 2005 09:24:53 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 17:44, Thomas Graf wrote: > > Let the meta action do that. Just set the skb->tc_classid in my opinion; > > recall we can change classid now .. > > True, I don't really care but it's already quite confusing. The priority > of the packet is described in viarous field depeding on which qdisc/cls > being used, we have skb->priority with sch_prio, tc_index for dsmark > and cls_tcindex and now tc_classid directly. Some even use u32 to > match on DSCP and set a nfmark. I can already feel the perfect confusion > once we open up access for rt_classid, realm and other routing fields. > I'm always aiming for easy to understand solutions, this doesn't mean > it to be simple. Why is nfmark so heavly used? Because it's damn simple > to undertand, you can set and read it and that's it. The only thing one > has to care about is to make sure that is actually gets set before it being > read and to make sure all userspace apps read it in the same base ;-> > (This is basically one of the issue in usability, the lack of clearliness > in what base number are read the displayed. Often they get displayed in > hex without a 0x prefix but are read with strtol(...,0) resulting in > a decimal reading if no prefix is specified) So let me put it this way: You cant avoid passing around metadata between the different blocks. Whether the metadata is set by the admin or by some other block along the packet path is way of life. All of the metadata defined and attached around skbs so far has a standalone semantical meaning whic unfortunately cant just be hidden from the user. Its the unfortunate consequence of giving someone a weapon )they may shoot their toe off). As an example: People have been setting flowid/classid for years via the classifiers to stamp session a flow belongs to. All we are doing with skb->tc_classid is giving more power to them. i.e before you get to the queue given certain computation/state you may decide to belong to a different session. sfq as a matter of setting the hash is computing what flow you belong to and thats why i suggested tc_classid (in this case not set by the admin, rather by a smart stateful classifier). > Long rant short statement, I'm pleading for a generic way to transfer > such things between a classifier and a qdisc because it's simply > easier to explain and use. > ... eaction meta set tc_index ip_saddr_proto_hash > ... qdisc sfq tcindex-hash > where ip_saddr_proto_hash is not a variable but rather a special meta > value calulated in the kernel. > Let me see if i understood correctly: Instead of giving static values (such as 0x10) you want to assign a variable(ip_saddr_proto_hash) which is computed at runtime to tcindex? Thats a parallel issue though but indeed useful . > > You can let the user define that via tc but have a default; > > eg: > > tc dev eth0 add sfq ematch > > tc dev eth0 set sfq pertub xxx > > > > match u32 ... > > ematch sfq > > ematch meta classid 1:2 > > eaction meta set tcindex 101 > > eaction meta set fwmark .. > > I think we're on the same road or at least going into the same direction. > However I'm not sure whether it's a good to have ematches return > some values besides true/false. I'd rather like to see an eaction store > it in the skb and the sfq catching it up again. Of course we can have the > userspace part be configured within the sfq. A classifier is allowed to select/set the class/flow/sessionID. The sfq hash result should at least set/map to the minor value of the classid cheers, jamal From dcbw@redhat.com Wed Feb 2 07:17:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:17:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12FH20l028790 for ; Wed, 2 Feb 2005 07:17:03 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j12FH1Rc016588; Wed, 2 Feb 2005 10:17:01 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j12FGuO27035; Wed, 2 Feb 2005 10:16:56 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FGtQO027375; Wed, 2 Feb 2005 10:16:55 -0500 Subject: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:16:55 -0500 Message-Id: <1107357415.27197.4.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct entries in sysfs. Seems like somebody meant to do this but it got lost. atmel_cs.c was previously fixed to pass in the correct struct device * via handle_to_dev() but the driver never actually used it. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; From dcbw@redhat.com Wed Feb 2 07:17:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:17:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12FHrR1029031 for ; Wed, 2 Feb 2005 07:17:53 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j12FHrlr016803; Wed, 2 Feb 2005 10:17:53 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j12FHqO27330; Wed, 2 Feb 2005 10:17:52 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FHqQO027443; Wed, 2 Feb 2005 10:17:52 -0500 Subject: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:17:52 -0500 Message-Id: <1107357472.27197.5.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev (resend) Identify different firmware by enums, not strings, as we need to have some integral firmware identifier for choosing maximum rssi values for each different firmware type. Consolidate the information about firmware filenames and capabilities in the atmel module, not in atmel_cs or atmel_pci. Move common prototypes and firmware enum into new atmel.h file. The atmel_cs driver also thought that init_atmel_card() took "int irq" as the first parameter, this is now fixed to be "unsigned short irq". Signed-off-by: Dan Williams --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This software is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table[fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName-revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName-revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020-V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502%s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e%s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table[card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; From dcbw@redhat.com Wed Feb 2 07:18:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:18:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12FIsd8029613 for ; Wed, 2 Feb 2005 07:18:55 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j12FIsuj017044; Wed, 2 Feb 2005 10:18:54 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j12FIsO27711; Wed, 2 Feb 2005 10:18:54 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FIrQO027508; Wed, 2 Feb 2005 10:18:53 -0500 Subject: [PATCH 2.6.11-rc2 2/2] wireless: WEXT quality cleanups + max rssi level fix for at76c502e From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:18:53 -0500 Message-Id: <1107357533.27197.7.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev (resend) Use correct maximum rssi level for at76c502e-type cards, and correct values in the qual.updated field to more closely match the current Wireless Extensions API. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv->wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) From tgraf@suug.ch Wed Feb 2 07:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:40:30 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12FeNGq030657 for ; Wed, 2 Feb 2005 07:40:26 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 095ED82; Wed, 2 Feb 2005 16:39:58 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 3C0041C0EA; Wed, 2 Feb 2005 16:40:41 +0100 (CET) Date: Wed, 2 Feb 2005 16:40:41 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202154041.GQ31837@postel.suug.ch> References: <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> <1107354293.1105.85.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107354293.1105.85.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev First of all, sorry for the massive amount of typos in my last post. I could barely see anything due to the sun shining onto my display. > You cant avoid passing around metadata between the different blocks. > Whether the metadata is set by the admin or by some other block along > the packet path is way of life. Agreed. > All of the metadata defined and attached around skbs so far has a > standalone semantical meaning whic unfortunately cant just be hidden > from the user. Its the unfortunate consequence of giving someone a > weapon )they may shoot their toe off). Agreed, I'm just trying avoid further confusion. I think my country has one of highest if not the higest density of fully automatic assault weapons (because everyone liable to miltary service needs to have one at home), everyone owning one is forced to practice once a year and shooting is a common sport. OTOH, we have one of the lowest crime rates. Why's that? Because almost everyone is well educated in terms of weapon saftey, so I think this should be our way as well. So yes, we can definitely add more complexity but we should try to make it easy to understand and use. > sfq as a matter of setting the hash is computing what flow you belong to > and thats why i suggested tc_classid (in this case not set by the admin, > rather by a smart stateful classifier). If the value for tc_classid is directly set by the user then I agree. What I want to avoid is having hidden uses of parameters which can also be modified by the user. It results in a backward compatibility hell later on because we can't just add another use for it without possibily breaking scripts. > Let me see if i understood correctly: Instead of giving static values > (such as 0x10) you want to assign a variable(ip_saddr_proto_hash) which > is computed at runtime to tcindex? > Thats a parallel issue though but indeed useful . OK, so basically we weren't talking of exactly the same thing. In a user setting only context your argumentation makes sense. Let me follow on this thought a little further, what I basically want is a generic way to influence various qdiscs, be it a hashing index for sfq, a priority value for priority band based qdiscs, etc. tc_classid isn't a bad choice but it gets complex once we want a classful qdiscs to be able to use this input parameter. Summarizing what we currently have: tc_index: May contain a dscp value if dsmark is told to fetch the dscp field, the minor part of priority if dsmark is told to map priority values via handle values, or the minor part of the classid in a classifier result via ingress classification or a classifier attached to a dsmark. cls_tcindex, gred, and meta ematch use it as input value. nf_mark: cls_fw map to classids, meta ematch may read it, meta eaction may set it. tc_classid: Actions may set it to overwrite the result of a classifer, meta ematch may read it and I guess meta eaction may write to it. tc_verd: Set early in net stack, used to track location and tc relevant flags. tclassid: Set withing routing db, may be read via meta ematch. At the moment all of them can be described properly and it should be easy to understand if the relations are outlined properly. Assuming we allow setting tc_classid to overwrite the sfq internal hash we introduce a not so obvious double use because tc_classid is assumed to at least partly point to a class. We can redefine tc_classid as being a generic flow/session descriptor but then it should be moved out of being used to overwrite the classid within actions. Assuming I have a classifier which normally classifies into a child class but sometimes I want the traffic to go into a leaf sfq qdisc by using the action to overwrite the result. It will then be impossible to overwrite the sfq hash because I would no longer be able to overwrite the classifier result. It's probably possible to find some working solution by having the minor part being the sfq input or vice versa but it gets really nasty. Therefore I think we should make a difference between the current use of tc_classid to overwrite the classifier result and giving qdiscs some kind of input not directly related to their handle. Thoughts? From tgraf@suug.ch Wed Feb 2 07:55:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:55:27 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12FtN50031417 for ; Wed, 2 Feb 2005 07:55:24 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 791A382; Wed, 2 Feb 2005 16:55:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BE6FC1C0EA; Wed, 2 Feb 2005 16:55:43 +0100 (CET) Date: Wed, 2 Feb 2005 16:55:43 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202155543.GR31837@postel.suug.ch> References: <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> <1107354293.1105.85.camel@jzny.localdomain> <20050202154041.GQ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202154041.GQ31837@postel.suug.ch> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > tc_index: May contain a dscp value if dsmark is told to fetch the dscp > field, the minor part of priority if dsmark is told to map > priority values via handle values, or the minor part of the > classid in a classifier result via ingress classification or > a classifier attached to a dsmark. cls_tcindex, gred, and > meta ematch use it as input value. Assuming we use tc_index to provide the hash... - we don't need to worry about any definitions. tc_index already stands for some kind of index grouping together various packets. - we can directly use sfq to do fair queueing on dscp values and skb priority including specialized map with a underlying dsmark or cls_tcindex. From linux@horizon.com Wed Feb 2 09:17:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 09:17:17 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12HH8U2006003 for ; Wed, 2 Feb 2005 09:17:09 -0800 Received: (qmail 24524 invoked by uid 1000); 2 Feb 2005 17:17:02 -0000 Date: 2 Feb 2005 17:17:02 -0000 Message-ID: <20050202171702.24523.qmail@science.horizon.com> From: linux@horizon.com To: lorenzo@gnu.org, mingo@elte.hu Subject: Re: [PATCH] OpenBSD Networking-related randomization port Cc: arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, linux@horizon.com, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu In-Reply-To: <20050131201141.GA4879@elte.hu> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: netdev *Sigh*. This thread is heading into the weeds. I have things I should be doing instead, but since nobody seems to actually be looking at what the patch *does*, I guess I'll have to dig into it a bit more... Yes, licensing issues need to be resolved before a patch can go in. Yes, code style standards needs to be kept up. And yes, SMP-locking issues need to be looked at. (And yes, ipv6 needs to be looked at, too!) But before getting sidetracked into the fine details, could folks please take a step back from the trees and look at the forest? Several people have asked (especially when the first patch came out), but I haven't seen any answers to the Big Questions: 1) Does this patch improve Linux's networking behaviour in any way? 2) Are the techniques in this patch a good way to achieve those improvements? Let's look at the various parts of the change: - Increases the default random pool size. Opinion: whatever. No real cost, except memory. Increases the maximum amount that can be read from /dev/random without blocking. Note that this is already adjustable at run time, so the question is why put it in the kernel config. If you want this, I'd suggest instead an option under CONFIG_EMBEDDED to shrink the pools and possibly get rid of the run-time changing code, then you could increase the default with less concern. - Changes the TCP ISN generation algorithm. I have't seen any good side to this. The current algorithm can be used for OS fingerprinting based on starting two TCP connections from different sources (ports or IPs) and noticing that the ISNs only differ in the low 24 bits, but is that a serious issue? If it is, there are better ways to deal with it that still preserve the valuable timer property. I point out that the entire reason for the cryptographically marginal half_md4_transform oprtation was that a full MD5 was a very noticeable performance bottleneck; the hash was only justified by the significant real-world attacks. obsd_get_random uses two calls to half_md4_transform. Which is the same cost as a full MD4 call. Frankly, they could just change half_md4_transform to return 64 bits instead of 32 and make do with one call. - Changes to the IP ID generation algorithm. All it actually does is change the way the initial inet->id is initialized for the inet_opt structure associated with the TCP socket. And if you look at ip_output.c:ip_push_pending_frames(), you'll see that, if DF is set (as is usual for a TCP connection), iph->id (the actual IP header ID) is set to htons(inet->id++). So it's still an incrementing sequence. This is in fact (see the comment in ip.h:ip_select_ident()) a workaround for a Microsoft VJ compression bug. The fix was added in 2.4.4 (via DaveM's zerocopy-beta-3 patch); before that, Linux 2.4 sent a constant zero as the IP ID of DF packets. See discussion at http://www.postel.org/pipermail/end2end-interest/2001-May/thread.html http://tcp-impl.lerc.nasa.gov/tcp-impl/list/archive/2378.html I'm not finding the diagnosis of the problem. I saw one report at http://oss.sgi.com/projects/netdev/archive/2001-01/msg00006.html and Dave Miller is pretty much on top of it when he posts http://marc.theaimsgroup.com/?l=linux-kernel&m=98275316400452&w=2 but I haven't found the actual debugging leading to the conclusion. This also led to some discussion of the OpenBSD IP ID algorithm that I haven't fully waded through at http://mail-index.netbsd.org/tech-net/2003/11/ If the packet is fragmentable (the only time the IP ID is really needed by the receiver), it's done by route.c:__ip_select_ident(). Wherein the system uses inet_getid to assign p->ip_id_count++ based on the route cache's struct inet_peer *p. (If the route cache is OOM, the system falls back on random IP ID assignment.) This latter technique nicely prevents the sort of stealth port scanning that was mentioned earlier in this thread, and prevents a person at address A from guessing the IP ID range I'm using to talk to address B. So note that the boast about "Randomized IP IDs" in the grsecurity description at http://www.gentoo.org/proj/en/hardened/grsecurity.xml is, as far as I can tell from a quick look at the code, simply false. As for the algorithm itself, it's described at http://www.usenix.org/events/usenix99/full_papers/deraadt/deraadt_html/node18.html but it's not obvious to me that it'd be hard to cryptanalyze given a stream of consecutive IDs. You need to recover: - The n value for each inter-ID gap, - The LCRNG state ru_a, ru_x, ru_b, - The 15-bit XOR masks ru_seed and ru_seed2, and - The discrete log generator ru_j (ru_g = 2^ru_j mod RU_N). Which is actually just a multiplier (mod RU_N-1 = 32748) on the input to the pmod() operation. So the IP ID generation can be summarized as: ru_x = (ru_a * ru_x + ru_b) % 31104; /* Repeated 1..4 times */ exp = ((ru_x ^ ru_seed2) + ru_j) % 32748; return ru_seed ^ pmod(2, exp, 32749); Now, if you can guess ru_seed, then the pmod() operation is simply a bijection that can be looked up in a table, and then it's just a matter of untangling a slightly elaborated LCRNG. - Changes the sun RPC XID allocation algorithm. Note that each connection is already initialized with a secure random number; the only change is whether the IDs used are simply incrementing from there or randomized each time one is needed. First of all and very importantly, obsd_get_random_long() does indeed generate a *random* number, which could be the *same* number as the last one. This could be VERY BAD for RPC XIDs, which have to be unique so the client can match the reply with the request. Note that Theo de Raadt knows better than do do that: http://www.usenix.org/events/usenix99/full_papers/deraadt/deraadt_html/node18.html Looking at the OpenBSD code at http://www.openbsd.org/cgi-bin/cvsweb/src/sys/nfs/ you can see that the NFS code in nfs_subs.c:nfsm_rpchead() generates a random starting xid and increments it by a random number 1..255 each time. The more general RPC code in krpc_subr.c:krpc_call() generates a fully random XID, constrained only to differ from the previous one. This is because the call is synchronous and does not permit more than one outstanding request at a time. Anyway, if you wanted to do this, you'd have to add some checking to ensure that a request with that ID isn't already on the rq_list. Also, there appear to be some retransmit issues that mitigate against recycling them too fast (which is why OpenBSD forbids adjacent duplicates), but I haven't studied that in detail. So in summary: - Random pool: Few security issues, but on the other hand, why bother? It's run-time tunable already. - TCP ISN: Proposed patch increases chance of TPC ISN reuse by breaking timer-based design specified in TCP RFC. It doesn't appear to have any more cryptographic security. - IP ID: Doesn't change the uses where it matters (DF flag clear). Doesn't change the fact that the IDs are still consecutive. What's the freaking point? And all that modular exponentiation that OpenBSD does is a pretty dubious security improvement. - RPC XID: Broken; don't use. And what's wrong with incrementing from a random start? If an attacker can see your requests, he can generate a fake reply no matter what algorithm you use, and if he can't, then the random start is all you need to limit his chances. The only thing a fully random sequence prevents against is that if an attacker can somehow tell when they've succeeded, an incrementing sequence lets them spoof furter replies easily. You could apply a first level of protection by incrementing them by a random odd number rather than 1, but even then, why bother? And, of ocurse, all of this has performance implications. Linux is justifiably proud of keeping down performance bloat by not wasting cycles on fast paths if it can possibly be helped. If we *do* find something to improve, we should look at the goals and design the fastest way possible to achieve that. It's not at all clear that the current code patch is the right implementation even if it *did* do something useful. Before worrying about the small stuff, could we take a good look at the Big Stuff? I like to try to be polite to people contributing patches. It's a lot of work and I don't want to dishearten someone just starting. I'd like to be polite and encouraging when rejecting patches. But everyone is so busy ignoring the elephant in the kitchen that I shall have to forego politeness and shout a little. It doesn't matter what the license is or whether it's against the Linus tree or -mm or how the functions are names. ********************************************** ************************************************ ***** ***** **** THIS PATCH DOESN'T FREAKING WORK!!!! **** ***** ***** ************************************************ ********************************************** Ignoring all the *implementation* brokenness, it breaks the network protocols, doesn't do what it claims to do, and what it tries to do isn't of any benefit over the existing code. It's not resting, it's not stunned, and it's not pining for the fjords. It just plain doesn't work. If there are any claimed benefits that you want, the first thing to do is throw it away, go back to square one, and come up with an algorithm that actually achieves that benefit. I keep hearing people boast about how the many eyes reviewing open source code improves the code quality and makes it harder to insert back doors into the system. If something this bad can get this many comments without anyone pointing out the emperor's clothing arrangements, the situation is pretty pitiful. There *are* things in OpenBSD, like randomized port assignment (as opposed to the linear scan in tcp_v4_get_port()) that would be worth emulating. Maybe worry about that first? From lorenzo@gnu.org Wed Feb 2 09:39:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 09:39:17 -0800 (PST) Received: from vds-320151.amen-pro.com (vds-320151.amen-pro.com [62.193.204.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Hd9IE010909 for ; Wed, 2 Feb 2005 09:39:09 -0800 Received: (qmail 9473 invoked from network); 2 Feb 2005 17:39:11 -0000 Received: from 67.red-80-25-56.pooles.rima-tde.net (HELO estila) (80.25.56.67) by vds-320151.amen-pro.com with RC4-MD5 encrypted SMTP; 2 Feb 2005 17:39:11 -0000 Subject: Re: [PATCH] OpenBSD Networking-related randomization port From: Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= To: linux@horizon.com Cc: mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu, spender@grsecurity.net In-Reply-To: <20050202171702.24523.qmail@science.horizon.com> References: <20050202171702.24523.qmail@science.horizon.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JOyczWpX46u3ytv/yRYL" Date: Wed, 02 Feb 2005 18:38:37 +0100 Message-Id: <1107365917.3754.155.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lorenzo@gnu.org Precedence: bulk X-list: netdev --=-JOyczWpX46u3ytv/yRYL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El mi=E9, 02-02-2005 a las 17:17 +0000, linux@horizon.com escribi=F3: > There *are* things in OpenBSD, like randomized port assignment (as oppose= d > to the linear scan in tcp_v4_get_port()) that would be worth emulating. > Maybe worry about that first? >=20 Completely agreed with you, I was just trying to help with split up patches, but, as your analysis shows, it's more a weak implementation than a real security improvement. All I can say, just ignore the patch.I will work on other (worthy) issues that are in a bigger need. Maybe I would work something out on randomized source ports, as soon as I get time for it. Note also that Brad fixed obsd_rand.c code this week, I've added him to the CC list because there are things that may concern grSecurity he should be able to comment further on it and discuss whatever concerns *his* work (which is, BTW, a good thing (tm) to have in mind even if he didn't send split up patches for each feature, which I really don't know). I've just ported it out of grsecurity. Thanks for your meaningful comments, Cheers. --=20 Lorenzo Hern=E1ndez Garc=EDa-Hierro =20 [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] --=-JOyczWpX46u3ytv/yRYL Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQBCARAdDcEopW8rLewRAk/FAJwO9z7+G3+j67CGEDEDy/CJ5NnnKACY3VxJ 3SkgAMBcW3GKrhQGvVNXFg== =yQ6v -----END PGP SIGNATURE----- --=-JOyczWpX46u3ytv/yRYL-- From br33d@yahoo.com Wed Feb 2 10:00:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:00:07 -0800 (PST) Received: from web51506.mail.yahoo.com (web51506.mail.yahoo.com [206.190.38.198]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12I00Bl013885 for ; Wed, 2 Feb 2005 10:00:01 -0800 Received: (qmail 4707 invoked by uid 60001); 2 Feb 2005 17:59:55 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=J8DWZwdT6EXKwIXj39YF8/w3TvC/hlE5tpLn2XxwBGM7WAJwzdLProy5rbDduMiTAuJVOfdu+J6H/cdrb0uvJ5c2sEXCkYy8E4f9CWv4Xq/q/+JC+IXWu/Nnar0GT3L0S/D2RWRNZ6ff4D9KPN2yFdqIEUpR+zpbLzVi4bh042o= ; Message-ID: <20050202175955.4705.qmail@web51506.mail.yahoo.com> Received: from [198.4.83.52] by web51506.mail.yahoo.com via HTTP; Wed, 02 Feb 2005 09:59:54 PST Date: Wed, 2 Feb 2005 09:59:54 -0800 (PST) From: Benjamin Reed Subject: [PATCH] Dynamic airo.c patch for 2.6.10 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-765586789-1107367194=:3794" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: br33d@yahoo.com Precedence: bulk X-list: netdev --0-765586789-1107367194=:3794 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Here is a patch for the 2.6.10 aironet driver that will enable dynamic wep keying without resetting the MAC. It allows us to use xsupplicant with the driver. There are two lines of ugliness (the ones with the 0 &&) where I ignore the flag that says wether we are setting a permanent or a temporary key since xsupplicant doesn't use the IW_ENCODE_TEMP flag. --0-765586789-1107367194=:3794 Content-Type: text/x-diff; name="airo-dynkey.patch" Content-Description: airo-dynkey.patch Content-Disposition: inline; filename="airo-dynkey.patch" --- /usr/src/kernel-source-2.6.10/drivers/net/wireless/airo.c 2004-12-24 13:33:59.000000000 -0800 +++ airo.c 2005-02-01 09:23:36.000000000 -0800 @@ -1739,9 +1739,12 @@ rc = PC4500_writerid(ai, RID_WEP_TEMP, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) printk(KERN_ERR "airo: WEP_TEMP set %x\n", rc); if (perm) { + // We make these messages debug. They really should be error, + // but no one seems to use the TEMP flag and writing a PERM key + // with the MAC disable throws this error rc = PC4500_writerid(ai, RID_WEP_PERM, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) { - printk(KERN_ERR "airo: WEP_PERM set %x\n", rc); + printk(KERN_DEBUG "airo: WEP_PERM set %x\n", rc); } } return rc; @@ -3815,11 +3818,14 @@ pRsp->rsp1 = IN4500(ai, RESP1); pRsp->rsp2 = IN4500(ai, RESP2); if ((pRsp->status & 0xff00)!=0 && pCmd->cmd != CMD_SOFTRESET) { - printk (KERN_ERR "airo: cmd= %x\n", pCmd->cmd); - printk (KERN_ERR "airo: status= %x\n", pRsp->status); - printk (KERN_ERR "airo: Rsp0= %x\n", pRsp->rsp0); - printk (KERN_ERR "airo: Rsp1= %x\n", pRsp->rsp1); - printk (KERN_ERR "airo: Rsp2= %x\n", pRsp->rsp2); + /* These really should be error, but supplicants don't seem + * to use the TEMP flag when setting the keys, so this + * error is common */ + printk (KERN_DEBUG "airo: cmd= %x\n", pCmd->cmd); + printk (KERN_DEBUG "airo: status= %x\n", pRsp->status); + printk (KERN_DEBUG "airo: Rsp0= %x\n", pRsp->rsp0); + printk (KERN_DEBUG "airo: Rsp1= %x\n", pRsp->rsp1); + printk (KERN_DEBUG "airo: Rsp2= %x\n", pRsp->rsp2); } // clear stuck command busy if necessary @@ -4048,10 +4054,12 @@ Cmd cmd; Resp rsp; +#if 0 /* This check is to catch bugs, not needed for WepRid with temp key */ if (test_bit(FLAG_ENABLED, &ai->flags)) printk(KERN_ERR "%s: MAC should be disabled (rid=%04x)\n", __FUNCTION__, rid); +#endif memset(&cmd, 0, sizeof(cmd)); memset(&rsp, 0, sizeof(rsp)); @@ -5096,7 +5104,7 @@ wkr.len = sizeof(wkr); wkr.kindex = 0xffff; wkr.mac[0] = (char)index; - if (perm) printk(KERN_INFO "Setting transmit key to %d\n", index); + if (perm) printk(KERN_DEBUG "Setting transmit key to %d\n", index); if (perm) ai->defindex = (char)index; } else { // We are actually setting the key @@ -5105,12 +5113,16 @@ wkr.klen = keylen; memcpy( wkr.key, key, keylen ); memcpy( wkr.mac, macaddr, ETH_ALEN ); - printk(KERN_INFO "Setting key %d\n", index); } - disable_MAC(ai, lock); + //We are supposed to disable MACs before we write Rids, + //but the WEP Key rid seems to be the exception when temporary. + //unfortunately, no one uses the temporary flag, so until then + //an error is going to get thrown... (remove the 0 && when the + //flag comes into use. + if (0 && perm) disable_MAC(ai, lock); writeWepKeyRid(ai, &wkr, perm, lock); - enable_MAC(ai, &rsp, lock); + if (0 && perm) enable_MAC(ai, &rsp, lock); return 0; } @@ -5564,9 +5576,9 @@ } #ifdef CONFIG_PCI - printk( KERN_INFO "airo: Probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Probing for PCI adapters\n" ); pci_register_driver(&airo_driver); - printk( KERN_INFO "airo: Finished probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Finished probing for PCI adapters\n" ); #endif /* Always exit with success, as we are a library module @@ -5578,7 +5590,7 @@ static void __exit airo_cleanup_module( void ) { while( airo_devices ) { - printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name ); + printk( KERN_DEBUG "airo: Unregistering %s\n", airo_devices->dev->name ); stop_airo_card( airo_devices->dev, 1 ); } #ifdef CONFIG_PCI @@ -6168,6 +6180,7 @@ { struct airo_info *local = dev->priv; CapabilityRid cap_rid; /* Card capability info */ + u16 oldAuthType; /* Is WEP supported ? */ readCapabilityRid(local, &cap_rid, 1); @@ -6210,7 +6223,8 @@ /* Copy the key in the driver */ memcpy(key.key, extra, dwrq->length); /* Send the key to the card */ - set_wep_key(local, index, key.key, key.len, 1, 1); + set_wep_key(local, index, key.key, key.len, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } /* WE specify that if a valid key is set, encryption * should be enabled (user may turn it off later) @@ -6224,13 +6238,15 @@ /* Do we want to just set the transmit key index ? */ int index = (dwrq->flags & IW_ENCODE_INDEX) - 1; if ((index >= 0) && (index < ((cap_rid.softCap & 0x80)?4:1))) { - set_wep_key(local, index, NULL, 0, 1, 1); + set_wep_key(local, index, NULL, 0, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } else /* Don't complain if only change the mode */ if(!dwrq->flags & IW_ENCODE_MODE) { return -EINVAL; } } + oldAuthType = local->config.authType; /* Read the flags */ if(dwrq->flags & IW_ENCODE_DISABLED) local->config.authType = AUTH_OPEN; // disable encryption @@ -6239,7 +6255,7 @@ if(dwrq->flags & IW_ENCODE_OPEN) local->config.authType = AUTH_ENCRYPT; // Only Wep /* Commit the changes to flags if needed */ - if(dwrq->flags & IW_ENCODE_MODE) + if(oldAuthType != local->config.authType) set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } --0-765586789-1107367194=:3794-- From asimshankar@gmail.com Wed Feb 2 10:05:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:05:24 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12I5GUR014557 for ; Wed, 2 Feb 2005 10:05:17 -0800 Received: by wproxy.gmail.com with SMTP id 71so134870wra for ; Wed, 02 Feb 2005 10:04:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=U7R7Tt3Ax6KHJ9+m995Opl8A6PkQ582XT+Oduw0wR5kSa8eSUnjpkJYBZH9R4d5/B+hHejIhY2d6/F1KLIHyVKeQAe15b+0Ib7fgmuLegQTUnZjoAuknTbAEzAUoN3rOQf0m+tGgsOtsAc9yIxzZsFT1pa55xT52v/2uLL/IkZA= Received: by 10.54.24.77 with SMTP id 77mr82734wrx; Wed, 02 Feb 2005 10:04:38 -0800 (PST) Received: by 10.54.24.29 with HTTP; Wed, 2 Feb 2005 10:04:38 -0800 (PST) Message-ID: <7bca1cb5050202100475279073@mail.gmail.com> Date: Wed, 2 Feb 2005 12:04:38 -0600 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: netif_rx_schedule_prep() returning false? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Hi, In NAPI related drivers, is it expected that netif_rx_schedule_prep() will return false? Does the fact that it returns false mean something is wrong? Specifically, in e1000 driver, when loaded with TxIntDelay=0, RxIntDelay=0, InterruptThrottleRate=0 (i.e., no hardware interrupt-coalescing), I've observed that the call to netif_rx_schedule_prep() in the interrupt handler (e1000_intr()) ocassionally returns false. Further investigation shows that this is because the __LINK_STATE_RX_SCHED bit of the struct net_device's state is already set (netif_running(dev) is always true). I also checked the interrupt cause register (ICR) in the interrupt handler and it seems the interrupts were caused by packet receives (ICR == E1000_ICR_RXT0, no other bits in the ICR register were set), which by my understanding should have not been possible. In other words, it seems the device is already scheduled for polling when a receive-related interrupt is received and handled. Is this behavior normal? Thanks, -- Asim From nacc@us.ibm.com Wed Feb 2 10:11:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:11:47 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12IBbMd015191 for ; Wed, 2 Feb 2005 10:11:43 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12IBVm4382610 for ; Wed, 2 Feb 2005 13:11:31 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12IBV8D456120 for ; Wed, 2 Feb 2005 11:11:31 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IBUiP017847 for ; Wed, 2 Feb 2005 11:11:31 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IBUu7017828; Wed, 2 Feb 2005 11:11:30 -0700 Received: by joust (Postfix, from userid 1000) id 6B24D4F9C9; Wed, 2 Feb 2005 10:11:29 -0800 (PST) Date: Wed, 2 Feb 2005 10:11:29 -0800 From: Nishanth Aravamudan To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 3/20] net/8139too: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202181129.GD2546@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, Please consider applying. One thing I would have preferred using here is use wait_event*(), but there is no condition. However, try_to_freeze(PF_FREEZE) could be used as one, if the return condition matters -- it can return 0 or 1, from what I understand. If the intent is to loop until the task is "frozen," then I can revise the patch to use wait_event_interruptible_timeout(). Description: Replace deprecated interruptible_sleep_on_timeout() function calls with direct wait-queue usage. I did not find the direct wake_up_interruptible() function call in this file for the wait-queue, but that may not be an issue. Patch is compile-tested. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/drivers/net/8139too.c 2005-01-24 09:34:08.000000000 -0800 +++ 2.6.11-rc2-kj/drivers/net/8139too.c 2005-01-27 11:22:19.000000000 -0800 @@ -108,6 +108,7 @@ #include #include #include +#include #include #include #include @@ -1612,6 +1613,7 @@ static inline void rtl8139_thread_iter ( static int rtl8139_thread (void *data) { + DEFINE_WAIT(wait); struct net_device *dev = data; struct rtl8139_private *tp = dev->priv; unsigned long timeout; @@ -1622,7 +1624,9 @@ static int rtl8139_thread (void *data) while (1) { timeout = next_tick; do { - timeout = interruptible_sleep_on_timeout (&tp->thr_wait, timeout); + prepare_to_wait(&tp->thr_wait, &wait, TASK_INTERRUPTIBLE); + timeout = schedule_timeout(timeout); + finish_wait(&tp->thr_wait, &wait); /* make swsusp happy with our thread */ try_to_freeze(PF_FREEZE); } while (!signal_pending (current) && (timeout > 0)); From nacc@us.ibm.com Wed Feb 2 10:19:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:19:08 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12IJ2iE015750 for ; Wed, 2 Feb 2005 10:19:02 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12IIrm4397822 for ; Wed, 2 Feb 2005 13:18:53 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12IIr8D458056 for ; Wed, 2 Feb 2005 11:18:53 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IIqRe004920 for ; Wed, 2 Feb 2005 11:18:53 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IIqo0004901; Wed, 2 Feb 2005 11:18:52 -0700 Received: by joust (Postfix, from userid 1000) id EFC534F9C9; Wed, 2 Feb 2005 10:18:50 -0800 (PST) Date: Wed, 2 Feb 2005 10:18:50 -0800 From: Nishanth Aravamudan To: Peter.Deschrijver@linux.cc.kuleuven.ac.be, mikep@linuxtr.net, sullivan@us.ibm.com Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 4/20] net/ibmtr: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202181850.GE2546@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, Please consider applying. This patch supersedes the recent patch "net/ibmtr: remove sleep_on*() usage" Description: Replace deprecated sleep_on*() function calls with direct wait-queue usage. Patch is compile-tested. The patch also fixes a potentially racy conditional in tok_open(), whereby msleep_interruptible() could receive a signal within the last jiffy, thus returning 0, but signal_pending(current) would be true. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/drivers/net/tokenring/ibmtr.c 2005-01-26 11:19:04.000000000 -0800 +++ 2.6.11-rc2-kj/drivers/net/tokenring/ibmtr.c 2005-02-02 10:16:56.000000000 -0800 @@ -109,6 +109,7 @@ in the event that chatty debug messages #include #include +#include #ifdef PCMCIA /* required for ibmtr_cs.c to build */ #undef MODULE /* yes, really */ @@ -847,6 +848,7 @@ static int __devinit trdev_init(struct n static int tok_init_card(struct net_device *dev) { + DEFINE_WAIT(wait); struct tok_info *ti; short PIOaddr; unsigned long i; @@ -867,13 +869,16 @@ static int tok_init_card(struct net_devi writeb(SRPR_ENABLE_PAGING,ti->mmio+ACA_OFFSET+ACA_RW+SRPR_EVEN); #endif writeb(INT_ENABLE, ti->mmio + ACA_OFFSET + ACA_SET + ISRP_EVEN); - i = sleep_on_timeout(&ti->wait_for_reset, 4 * HZ); + prepare_to_wait(&ti->wait_for_reset, &wait, TASK_UNINTERRUPTIBLE); + i = schedule_timeout(4*HZ); + finish_wait(&ti->wait_for_reset, &wait); return i? 0 : -EAGAIN; } /*****************************************************************************/ static int tok_open(struct net_device *dev) { + DEFINE_WAIT(wait); struct tok_info *ti = (struct tok_info *) dev->priv; int i; @@ -903,7 +908,9 @@ static int tok_open(struct net_device *d while (1){ tok_open_adapter((unsigned long) dev); - i= interruptible_sleep_on_timeout(&ti->wait_for_reset, 25 * HZ); + prepare_to_wait(&ti->wait_for_reset, &wait, TASK_INTERRUPTIBLE); + i = schedule_timeout(25 * HZ); + finish_wait(&ti->wait_for_reset, &wait); /* sig catch: estimate opening adapter takes more than .5 sec*/ if (i>(245*HZ)/10) break; /* fancier than if (i==25*HZ) */ if (i==0) break; @@ -912,7 +919,8 @@ static int tok_open(struct net_device *d DPRINTK("Adapter is up and running\n"); return 0; } - if(msleep_interruptible(jiffies_to_msecs(TR_RETRY_INTERVAL))) + msleep_interruptible(jiffies_to_msecs(TR_RETRY_INTERVAL)); + if (signal_pending(current)) break; /*prob. a signal, like the i>24*HZ case above */ } outb(0, dev->base_addr + ADAPTRESET);/* kill pending interrupts*/ From jt@hpl.hp.com Wed Feb 2 10:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:35:32 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12IZSWh016591 for ; Wed, 2 Feb 2005 10:35:29 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 95827189A; Wed, 2 Feb 2005 10:35:26 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA13957; Wed, 2 Feb 2005 10:37:38 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwPLZ-0003cE-00; Wed, 02 Feb 2005 10:35:25 -0800 Date: Wed, 2 Feb 2005 10:35:25 -0800 To: Benjamin Reed , Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 Message-ID: <20050202183525.GA13881@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Benjamin Reed wrote : > > Here is a patch for the 2.6.10 aironet driver that > will enable dynamic wep keying without resetting the > MAC. It allows us to use xsupplicant with the driver. > > There are two lines of ugliness (the ones with the 0 > &&) where I ignore the flag that says wether we are > setting a permanent or a temporary key since > xsupplicant doesn't use the IW_ENCODE_TEMP flag. The IW_ENCODE_TEMP flag only make sense for the Aironet driver, as for all other hardware the WEP keys are volatile. So, don't expect this flag to be widespread. I would suggest you send a nice little patch to the maintainer of xsupplicant (and wpa_supplicant as well) explaining the situation. Enabling this flag should not affect other drivers, and might actually be a good idea in general. Have fun... Jean From nacc@us.ibm.com Wed Feb 2 10:58:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:58:44 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12IwXYK018275 for ; Wed, 2 Feb 2005 10:58:40 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12IwRCZ660510 for ; Wed, 2 Feb 2005 13:58:27 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12IwPqv317714 for ; Wed, 2 Feb 2005 11:58:25 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IwPRs022876 for ; Wed, 2 Feb 2005 11:58:25 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IwO3N022829; Wed, 2 Feb 2005 11:58:24 -0700 Received: by joust (Postfix, from userid 1000) id 751634F9C9; Wed, 2 Feb 2005 10:58:23 -0800 (PST) Date: Wed, 2 Feb 2005 10:58:23 -0800 From: Nishanth Aravamudan To: robert.olsson@its.uu.se Cc: netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 5/20] net/pktgen: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202185823.GG2546@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, The first and last replacements in the following patch were slightly confusing to me, as I have not used wait-queues that much myself. I did not exactly understand how a locally defined wait-queue could be slept on, especially since there are no wake_up() calls in pktgen.c. I was tempted to make the first sleep a msleep_interruptible(100), but decided to patch for the same code before I did that. Description: Replace deprecated interruptible_sleep_on_timeout() with direct wait-queue usage or wait_event_interruptible_timeout() as appropriate. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/net/core/pktgen.c 2005-01-24 09:34:21.000000000 -0800 +++ 2.6.11-rc2-kj/net/core/pktgen.c 2005-02-02 10:57:02.000000000 -0800 @@ -135,6 +135,7 @@ #include #include #include +#include #include #include #include @@ -2409,16 +2410,18 @@ static int running(struct pktgen_thread static int pktgen_wait_thread_run(struct pktgen_thread *t ) { - wait_queue_head_t queue; - - init_waitqueue_head(&queue); - + DEFINE_WAIT(wait); + wait_queue_head_t queue; + init_waitqueue_head(&queue); + if_lock(t); while(running(t)) { if_unlock(t); - - interruptible_sleep_on_timeout(&queue, HZ/10); + + prepare_to_wait(&queue, &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&queue, &wait); if (signal_pending(current)) goto signal; if_lock(t); @@ -2738,6 +2741,7 @@ __inline__ void pktgen_xmit(struct pktge static void pktgen_thread_worker(struct pktgen_thread *t) { + DEFINE_WAIT(wait); struct pktgen_dev *pkt_dev = NULL; int cpu = t->cpu; sigset_t tmpsig; @@ -2805,9 +2809,11 @@ static void pktgen_thread_worker(struct do_softirq(); tx_since_softirq = 0; } + } else { + prepare_to_wait(&(t->queue), &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&(t->queue), &wait); } - else - interruptible_sleep_on_timeout(&(t->queue), HZ/10); /* * Back from sleep, either due to the timeout or signal. @@ -3118,8 +3124,7 @@ static void __exit pg_cleanup(void) struct pktgen_thread *t = pktgen_threads; pktgen_threads->control |= (T_TERMINATE); - while( t == pktgen_threads) - interruptible_sleep_on_timeout(&queue, HZ); + wait_event_interruptible_timeout(queue, (t != pktgen_threads), HZ); } /* Un-register us from receiving netdevice events */ From sfeldma@pobox.com Wed Feb 2 11:14:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:15:04 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12JEwcD019200 for ; Wed, 2 Feb 2005 11:14:59 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 187E08F; Wed, 2 Feb 2005 14:14:58 -0500 (EST) Received: from [192.168.0.3] (wbar2.sea1-4-5-062-153.sea1.dsl-verizon.net [4.5.62.153]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 79ABD89; Wed, 2 Feb 2005 14:14:56 -0500 (EST) Subject: Re: netif_rx_schedule_prep() returning false? From: Scott Feldman Reply-To: sfeldma@pobox.com To: Asim Shankar Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb5050202100475279073@mail.gmail.com> References: <7bca1cb5050202100475279073@mail.gmail.com> Content-Type: text/plain Message-Id: <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 02 Feb 2005 11:16:32 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev On Wed, 2005-02-02 at 10:04, Asim Shankar wrote: > Specifically, in e1000 driver, when loaded with TxIntDelay=0, > RxIntDelay=0, InterruptThrottleRate=0 (i.e., no hardware > interrupt-coalescing), I've observed that the call to > netif_rx_schedule_prep() in the interrupt handler (e1000_intr()) > ocassionally returns false. Further investigation shows that this is > because the __LINK_STATE_RX_SCHED bit of the struct net_device's state > is already set (netif_running(dev) is always true). I also checked the > interrupt cause register (ICR) in the interrupt handler and it seems > the interrupts were caused by packet receives (ICR == E1000_ICR_RXT0, > no other bits in the ICR register were set), which by my understanding > should have not been possible. I'm running the same setup with delays turned off and I'm not seeing what you're seeing. What e1000 controller are you using? Send lspci -n. -scott From breed@almaden.ibm.com Wed Feb 2 11:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:16:08 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12JG4cR019606 for ; Wed, 2 Feb 2005 11:16:04 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12JFxm4284284 for ; Wed, 2 Feb 2005 14:15:59 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12JFw8D436190 for ; Wed, 2 Feb 2005 12:15:58 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12JFwMR028077 for ; Wed, 2 Feb 2005 12:15:58 -0700 Received: from mailhub.almaden.ibm.com (mailhub.almaden.ibm.com [9.1.45.57]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12JFvEH028047; Wed, 2 Feb 2005 12:15:58 -0700 Received: from [9.1.57.1] (dyn-9-1-57-1.almaden.ibm.com [9.1.57.1]) by mailhub.almaden.ibm.com (AIX5.2/8.11.6p2/8.11.0) with ESMTP id j12JFvN31904; Wed, 2 Feb 2005 11:15:57 -0800 Message-ID: <420126FB.3000007@almaden.ibm.com> Date: Wed, 02 Feb 2005 11:16:11 -0800 From: Benjamin Reed User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 References: <20050202183525.GA13881@bougret.hpl.hp.com> In-Reply-To: <20050202183525.GA13881@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: breed@almaden.ibm.com Precedence: bulk X-list: netdev I'm wondering if it would be possible to change IW_ENCODE_TEMP to IW_ENCODE_PERM. I realize that would not be backward compatible, but as you point out, the default assumption is that the keys are volatile. ben Jean Tourrilhes wrote: >Benjamin Reed wrote : > > >>Here is a patch for the 2.6.10 aironet driver that >>will enable dynamic wep keying without resetting the >>MAC. It allows us to use xsupplicant with the driver. >> >>There are two lines of ugliness (the ones with the 0 >>&&) where I ignore the flag that says wether we are >>setting a permanent or a temporary key since >>xsupplicant doesn't use the IW_ENCODE_TEMP flag. >> >> > > The IW_ENCODE_TEMP flag only make sense for the Aironet >driver, as for all other hardware the WEP keys are volatile. So, don't >expect this flag to be widespread. > I would suggest you send a nice little patch to the maintainer >of xsupplicant (and wpa_supplicant as well) explaining the >situation. Enabling this flag should not affect other drivers, and >might actually be a good idea in general. > Have fun... > > Jean > > From jt@hpl.hp.com Wed Feb 2 11:22:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:22:58 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12JMsiI020369 for ; Wed, 2 Feb 2005 11:22:54 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 36DEC20C41; Wed, 2 Feb 2005 11:22:08 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id LAA15220; Wed, 2 Feb 2005 11:24:21 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwQ4m-0003zd-00; Wed, 02 Feb 2005 11:22:08 -0800 Date: Wed, 2 Feb 2005 11:22:08 -0800 To: Benjamin Reed Cc: Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 Message-ID: <20050202192208.GA15344@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20050202183525.GA13881@bougret.hpl.hp.com> <420126FB.3000007@almaden.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420126FB.3000007@almaden.ibm.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev On Wed, Feb 02, 2005 at 11:16:11AM -0800, Benjamin Reed wrote: > I'm wondering if it would be possible to change IW_ENCODE_TEMP to > IW_ENCODE_PERM. I realize that would not be backward compatible, but as > you point out, the default assumption is that the keys are volatile. > > ben Then you would have to change all other wireless tools (mine, NetworkManager, KWiFi). By default, those tools will send you a WEP key without any flag. My assumption is that if a user set a WEP key explicitely with those tools, you want it to be permanent. I think it's easier to fix the only two tools that make use of dynamic keys. Have fun... Jean From bunk@stusta.de Wed Feb 2 11:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:52:34 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12JqRVR021710 for ; Wed, 2 Feb 2005 11:52:28 -0800 Received: (qmail 18980 invoked from network); 2 Feb 2005 19:52:21 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 Feb 2005 19:52:21 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 306A2BB62A; Wed, 2 Feb 2005 20:52:21 +0100 (CET) Date: Wed, 2 Feb 2005 20:52:21 +0100 From: Adrian Bunk To: Andrew Morton Cc: Margit Schubert-While , prism54-private@prism54.org, netdev@oss.sgi.com, jgarzik@pobox.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [2.6 patch] prism54: misc cleanups Message-ID: <20050202195221.GE3313@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev This patch makes some functions in prism54 that are only required locally static. As a side effect it turned out that the mgt_unlatch_all function was completely unused, and it's therefore #if 0'ed. I also considered moving display_buffer as static inline into islpci_mgt.h, but I wasn't 100% sure and therefore left it. Signed-off-by: Adrian Bunk --- This patch was already sent on: - 20 Dec 2004 drivers/net/wireless/prism54/isl_ioctl.c | 32 +++++++++++------- drivers/net/wireless/prism54/isl_ioctl.h | 5 -- drivers/net/wireless/prism54/islpci_dev.c | 5 +- drivers/net/wireless/prism54/islpci_dev.h | 2 - drivers/net/wireless/prism54/islpci_mgt.c | 2 + drivers/net/wireless/prism54/oid_mgt.c | 38 +--------------------- drivers/net/wireless/prism54/oid_mgt.h | 4 -- 7 files changed, 28 insertions(+), 60 deletions(-) --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h.old 2004-10-30 06:52:18.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h 2004-10-30 07:02:58.000000000 +0200 @@ -41,15 +41,10 @@ void prism54_wpa_ie_init(islpci_private *priv); void prism54_wpa_ie_clean(islpci_private *priv); -void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, - u8 *wpa_ie, size_t wpa_ie_len); -size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); int prism54_set_mac_address(struct net_device *, void *); int prism54_ioctl(struct net_device *, struct ifreq *, int); -int prism54_set_wpa(struct net_device *, struct iw_request_info *, - __u32 *, char *); extern const struct iw_handler_def prism54_handler_def; --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c.old 2004-10-30 06:43:10.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c 2004-10-30 07:11:26.000000000 +0200 @@ -36,6 +36,14 @@ #include /* New driver API */ + +static void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len); +static size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); +static int prism54_set_wpa(struct net_device *, struct iw_request_info *, + __u32 *, char *); + + /** * prism54_mib_mode_helper - MIB change mode helper function * @mib: the &struct islpci_mib object to modify @@ -47,7 +55,7 @@ * Wireless API modes to Device firmware modes. It also checks for * correct valid Linux wireless modes. */ -int +static int prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode) { u32 config = INL_CONFIG_MANUALRUN; @@ -647,7 +655,7 @@ return current_ev; } -int +static int prism54_get_scan(struct net_device *ndev, struct iw_request_info *info, struct iw_point *dwrq, char *extra) { @@ -1582,7 +1590,7 @@ #define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5] #define MACSTR "%02x:%02x:%02x:%02x:%02x:%02x" -void +static void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, u8 *wpa_ie, size_t wpa_ie_len) { @@ -1649,7 +1657,7 @@ up(&priv->wpa_sem); } -size_t +static size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie) { struct list_head *ptr; @@ -1736,7 +1744,7 @@ } } -int +static int prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid, char *data) { @@ -2314,7 +2322,7 @@ return ret; } -int +static int prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2358,7 +2366,7 @@ return 0; } -int +static int prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2367,7 +2375,7 @@ return 0; } -int +static int prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2380,7 +2388,7 @@ return 0; } -int +static int prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2389,7 +2397,7 @@ return 0; } -int +static int prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2401,7 +2409,7 @@ return 0; } -int +static int prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *info, struct iw_point *data, char *extra) { @@ -2437,7 +2445,7 @@ return ret; } -int +static int prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *info, struct iw_point *data, char *extra) { --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.h.old 2004-10-30 06:58:23.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.h 2004-10-30 07:04:02.000000000 +0200 @@ -211,8 +211,6 @@ priv->device_base); } -struct net_device_stats *islpci_statistics(struct net_device *); - int islpci_free_memory(islpci_private *); struct net_device *islpci_setup(struct pci_dev *); #endif /* _ISLPCI_DEV_H */ --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.c.old 2004-10-30 06:46:08.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.c 2004-10-30 07:12:13.000000000 +0200 @@ -44,6 +44,7 @@ static int prism54_bring_down(islpci_private *); static int islpci_alloc_memory(islpci_private *); +static struct net_device_stats *islpci_statistics(struct net_device *); /* Temporary dummy MAC address to use until firmware is loaded. * The idea there is that some tools (such as nameif) may query @@ -52,7 +53,7 @@ * Of course, this is not the final/real MAC address. It doesn't * matter, as you are suppose to be able to change it anytime via * ndev->set_mac_address. Jean II */ -const unsigned char dummy_mac[6] = { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 }; +static const unsigned char dummy_mac[6] = { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 }; static int isl_upload_firmware(islpci_private *priv) @@ -607,7 +608,7 @@ return rc; } -struct net_device_stats * +static struct net_device_stats * islpci_statistics(struct net_device *ndev) { islpci_private *priv = netdev_priv(ndev); --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_mgt.c.old 2004-10-30 06:46:45.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_mgt.c 2004-10-30 07:15:39.000000000 +0200 @@ -44,6 +44,7 @@ /****************************************************************************** Driver general functions ******************************************************************************/ +#if VERBOSE > SHOW_ERROR_MESSAGES void display_buffer(char *buffer, int length) { @@ -58,6 +59,7 @@ printk("\n"); } +#endif /***************************************************************************** Queue handling for management frames --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/oid_mgt.h.old 2004-10-30 07:05:55.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/oid_mgt.h 2004-10-30 07:42:02.000000000 +0200 @@ -28,8 +28,7 @@ void mgt_clean(islpci_private *); -/* I don't know where to put these 3 */ -extern const int frequency_list_bg[]; +/* I don't know where to put these 2 */ extern const int frequency_list_a[]; int channel_of_freq(int); @@ -49,7 +48,6 @@ void mgt_get(islpci_private *, enum oid_num_t, void *); int mgt_commit(islpci_private *); -void mgt_unlatch_all(islpci_private *); int mgt_mlme_answer(islpci_private *); --- linux-2.6.10-rc3-mm1-full/drivers/net/wireless/prism54/oid_mgt.c.old 2004-12-20 01:03:44.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/drivers/net/wireless/prism54/oid_mgt.c 2004-12-20 01:05:31.000000000 +0100 @@ -24,8 +24,8 @@ #include "isl_ioctl.h" /* to convert between channel and freq */ -const int frequency_list_bg[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442, - 2447, 2452, 2457, 2462, 2467, 2472, 2484 +static const int frequency_list_bg[] = { 2412, 2417, 2422, 2427, 2432, + 2437, 2442, 2447, 2452, 2457, 2462, 2467, 2472, 2484 }; int @@ -730,6 +730,7 @@ * * The way to do this is to set ESSID. Note though that they may get * unlatch before though by setting another OID. */ +#if 0 void mgt_unlatch_all(islpci_private *priv) { @@ -756,6 +757,7 @@ if (rvalue) printk(KERN_DEBUG "%s: Unlatching OIDs failed\n", priv->ndev->name); } +#endif /* This will tell you if you are allowed to answer a mlme(ex) request .*/ From dcbw@redhat.com Wed Feb 2 12:17:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:17:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12KH5c0023018 for ; Wed, 2 Feb 2005 12:17:06 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j12KH55h012552; Wed, 2 Feb 2005 15:17:05 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j12KH4O04510; Wed, 2 Feb 2005 15:17:04 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12KH4QO020417; Wed, 2 Feb 2005 15:17:04 -0500 Subject: [PATCH 2.6.11-rc2 ] wireless: Hook up Atmel scan quality information From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 15:17:04 -0500 Message-Id: <1107375424.18721.1.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Actually return quality information for scanned access points. Signed-off-by: Dan Williams --- atmel.c.scan-qual 2005-02-02 14:53:40.000000000 -0500 +++ atmel.c 2005-02-02 15:10:46.000000000 -0500 @@ -639,6 +639,7 @@ static int reset_atmel_card(struct net_device *dev ); static void atmel_enter_state(struct atmel_private *priv, int new_state); int atmel_open (struct net_device *dev); +static u8 get_rssi_percentage (struct atmel_private *priv, u8 rssi); static inline u16 atmel_hi(struct atmel_private *priv, u16 offset) { @@ -2187,6 +2188,15 @@ iwe.u.mode = priv->BSSinfo[i].BSStype; current_ev = iwe_stream_add_event(current_ev, extra + IW_SCAN_MAX_DATA, &iwe, IW_EV_UINT_LEN); + iwe.cmd = IWEVQUAL; + iwe.u.qual.level = get_rssi_percentage (priv, priv->BSSinfo[i].RSSI); + iwe.u.qual.noise = 0; + iwe.u.qual.qual = iwe.u.qual.level; + iwe.u.qual.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_QUAL_UPDATED + | IW_QUAL_NOISE_INVALID; /* Don't know noise or quality */ + current_ev = iwe_stream_add_event(current_ev, extra + IW_SCAN_MAX_DATA, &iwe, IW_EV_QUAL_LEN); + iwe.cmd = SIOCGIWFREQ; iwe.u.freq.m = priv->BSSinfo[i].channel; iwe.u.freq.e = 0; @@ -3048,9 +3058,8 @@ } } -static void smooth_rssi(struct atmel_private *priv, u8 rssi) +static u8 get_rssi_percentage (struct atmel_private *priv, u8 rssi) { - u8 old = priv->wstats.qual.level; u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ switch (priv->firmware_type) { @@ -3061,7 +3070,14 @@ break; } - rssi = rssi * 100 / max_rssi; + return (rssi * 100 / max_rssi); +} + +static void smooth_rssi(struct atmel_private *priv, u8 rssi) +{ + u8 old = priv->wstats.qual.level; + + rssi = get_rssi_percentage (priv, rssi); if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else From simon@thekelleys.org.uk Wed Feb 2 12:39:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:39:24 -0800 (PST) Received: from thekelleys.org.uk (cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com [81.108.205.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12KdJW1027365 for ; Wed, 2 Feb 2005 12:39:20 -0800 Received: from desk.thekelleys.org.uk ([192.168.0.3] helo=thekelleys.org.uk) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1CwRHM-0005dM-00; Wed, 02 Feb 2005 20:39:12 +0000 Message-ID: <42013A72.1080209@thekelleys.org.uk> Date: Wed, 02 Feb 2005 20:39:14 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com Subject: Re: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver References: <1107357472.27197.5.camel@dcbw.boston.redhat.com> In-Reply-To: <1107357472.27197.5.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: simon@thekelleys.org.uk Precedence: bulk X-list: netdev All Dans patches look good, in principle, to me. There's one more entry to go in the device table which has been floating around for a month or two, but doesn't seem to have made it in yet, in the new format: {0, 0," LG/LW2100N", ATMEL_FW_TYPE_502E, "LG LW2100N 11Mbps WLAN PCMCIA Card" } Dan, if you make another version of your patch maybe you could add that, otherwise I'll submit it as a follow-on once your changes have gone in. Cheers, Simon. From asimshankar@gmail.com Wed Feb 2 12:42:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:42:31 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12KgRcY027885 for ; Wed, 2 Feb 2005 12:42:28 -0800 Received: by wproxy.gmail.com with SMTP id 71so165632wra for ; Wed, 02 Feb 2005 12:42:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Y9J+1oLMbmvqR7hu9Bf+6qobqdmVANvgM4sjueXI9xtIIMQPduRgEU1cX+ez0GMVjtGBIkH9554uZbpmbl2u74Dg7kOfR4egonhLDOj9Iv8P7hXfu4WsW7f8s3uLkI5eyCoqOL/Atf5TJGW2G/mQkIxIi+Hx16rhnlwBtiA77W4= Received: by 10.54.24.77 with SMTP id 77mr184462wrx; Wed, 02 Feb 2005 12:42:14 -0800 (PST) Received: by 10.54.24.29 with HTTP; Wed, 2 Feb 2005 12:41:59 -0800 (PST) Message-ID: <7bca1cb5050202124149bd7f04@mail.gmail.com> Date: Wed, 2 Feb 2005 14:41:59 -0600 From: Asim Shankar Reply-To: Asim Shankar To: sfeldma@pobox.com Subject: Re: netif_rx_schedule_prep() returning false? Cc: netdev@oss.sgi.com In-Reply-To: <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7bca1cb5050202100475279073@mail.gmail.com> <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev > I'm running the same setup with delays turned off and I'm not seeing > what you're seeing. What e1000 controller are you using? Send lspci > -n. lspci -n: 00:00.0 Class 0600: 8086:7190 (rev 03) 00:01.0 Class 0604: 8086:7191 (rev 03) 00:07.0 Class 0601: 8086:7110 (rev 02) 00:07.1 Class 0101: 8086:7111 (rev 01) 00:07.2 Class 0c03: 8086:7112 (rev 01) 00:07.3 Class 0680: 8086:7113 (rev 02) 00:10.0 Class 0200: 8086:1076 00:11.0 Class 0200: 10b7:9055 00:13.0 Class 0604: 1011:0024 (rev 03) 01:00.0 Class 0300: 10de:0028 (rev 11) This happens when a more "powerful" machine sends to a less powerful one and not the reverse. My setup is so: Machine A: Dual Xeon 2.8Ghz, 1GB RAM Dell PowerEdge 1800 Machine B: Dual P-III 500Mhz, 512MB RAM, old Dell Precision 410 I'm using netperf, so B is running a "netserver" and the netperf client application is started on A. "lspci" shown above is from "B". When reversed, B sending TO A, then machine A doesn't complain at all. Machine A also has the same card: Intel PRO/1000 MT Desktop Adapter - Class 0200: 8086:1076. Thanks, Regards, -- Asim P.S. Changes to e1000_intr() in order to check this: o Added "int rx_sched = test_bit(__LINK_STATE_RX_SCHED, &netdev->state); o Later, added an "else" to the "if (likely(netif_rx_schedule_prep(nedev))" block where I do a printk() From davem@davemloft.net Wed Feb 2 13:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 13:14:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12LE6BQ029106 for ; Wed, 2 Feb 2005 13:14:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwRiy-00027M-00; Wed, 02 Feb 2005 13:07:44 -0800 Date: Wed, 2 Feb 2005 13:07:43 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets when using netfilter hooks Message-Id: <20050202130743.065bc627.davem@davemloft.net> In-Reply-To: <20050131184827.GH31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 19:48:27 +0100 Thomas Graf wrote: > Jamal, close your eyes please. :-) > Fixes the ingress qdisc to pick up IPv6 packets when using the old > style netfilter hooks, i.e. when CONFIG_NET_CLS_ACT is not enabled. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Wed Feb 2 13:15:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 13:16:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12LFvu7029576 for ; Wed, 2 Feb 2005 13:15:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwRkm-00028H-00; Wed, 02 Feb 2005 13:09:36 -0800 Date: Wed, 2 Feb 2005 13:09:36 -0800 From: "David S. Miller" To: Robert Olsson Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: [PATCH] gc_min_interval in milleseconds via /proc (fwd) Message-Id: <20050202130936.4b3b8895.davem@davemloft.net> In-Reply-To: <16894.29281.293401.832567@robur.slu.se> References: <16888.56016.608929.340640@robur.slu.se> <20050130225627.4feecd2e.davem@davemloft.net> <16894.29281.293401.832567@robur.slu.se> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 19:01:05 +0100 Robert Olsson wrote: > David S. Miller writes: > > > We must pick a new sysctl number too, for sysctl() system call. > > If the only access possible were through /proc then yes your > > change would be valid, but due to sysctl() system call the > > .ctl_name defines that dimension of the sysctl namespace. > > Ok! > NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS was added last in list to avoid > renumbering. Feel free to change. Applied, thanks Robert. From romieu@fr.zoreil.com Wed Feb 2 14:14:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:14:36 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12MERs6031672 for ; Wed, 2 Feb 2005 14:14:28 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j12MDdRn026719; Wed, 2 Feb 2005 23:13:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j12MDYMc026718; Wed, 2 Feb 2005 23:13:34 +0100 Date: Wed, 2 Feb 2005 23:13:33 +0100 From: Francois Romieu To: "Dale E. Martin" Cc: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050202221333.GA24020@electric-eye.fr.zoreil.com> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> <20050201215607.GA8530@gerbil.toadis.porkis> <20050201223109.GA2957@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201223109.GA2957@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1204 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 Re, - the 2.4.x backport has been rediffed against 2.4.29 (mostly harmless conflict in drivers/net/Config.in); - the driver compiles again when RTL8169_DEBUG is defined; - endianness fix in the Rx checksumming path. A test report with your 2.95.3 compiler would be welcome. If it breaks, the r8169.o file and an estimate of the transmitted/received packets count will help. If none is available, the number of interrupts processed can help too. Patch against 2.4.29 (md5: 444748e3c6c56382cb02adea4d16b5cf) http://www.fr.zoreil.com/~romieu/misc/20050202-2.4.29-r8169.c-test.patch Same thing a la patch-script: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.29/r8169/ Patch-script in a single file: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.29/r8169-blob.tar.bz2 -- Ueimor From olh@suse.de Wed Feb 2 14:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:25:27 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12MPMvE032433 for ; Wed, 2 Feb 2005 14:25:23 -0800 Received: from hermes.suse.de (hermes-ext.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 E23DD13F4B4B for ; Wed, 2 Feb 2005 23:25:16 +0100 (CET) Date: Wed, 2 Feb 2005 23:25:16 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202222516.GA15440@suse.de> References: <20050202133851.GA9680@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050202133851.GA9680@suse.de> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev On Wed, Feb 02, Olaf Hering wrote: > > What buffer or sysctrl value has to change to allow more than 3445 rules > like this (on a 64bit host with 64bit iptables)? > > iptables -A FORWARD -j ACCEPT > > setsockopt(3, SOL_IP, 0x40 /* IP_??? */, > "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524368) = > -1 ENOMEM (Cannot allocate memory) it triggers the first -ENOMEM in net/ipv4/netfilter/ip_tables.c:do_replace sizeof(struct ipt_table_info)+SMP_ALIGN(tmp.size)*NR_CPUS == 67108992 bytes 128+524288*128==67108992 (sizeof(struct ipt_table_info) + (((tmp.size) + (1 << 7)-1) & ~((1 << 7)-1)) * 128) hmm, no braces missing. From tgraf@suug.ch Wed Feb 2 14:36:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:36:17 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12MaBuG000632 for ; Wed, 2 Feb 2005 14:36:12 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C0AA682; Wed, 2 Feb 2005 23:35:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 059BF1C0EA; Wed, 2 Feb 2005 23:36:30 +0100 (CET) Date: Wed, 2 Feb 2005 23:36:29 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.4] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets Message-ID: <20050202223629.GS31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> <20050202130743.065bc627.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202130743.065bc627.davem@davemloft.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Signed-off-by: Thomas Graf --- linux-2.4.29-bk8.orig/net/sched/sch_ingress.c 2005-02-02 22:32:51.000000000 +0100 +++ linux-2.4.29-bk8/net/sched/sch_ingress.c 2005-02-02 22:56:33.000000000 +0100 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -241,6 +242,15 @@ NF_IP_PRI_FILTER + 1 }; +static struct nf_hook_ops ing6_ops = +{ + { NULL, NULL}, + ing_hook, + PF_INET6, + NF_IP6_PRE_ROUTING, + NF_IP6_PRI_FILTER + 1 +}; + int ingress_init(struct Qdisc *sch,struct rtattr *opt) { struct ingress_qdisc_data *p = PRIV(sch); @@ -249,8 +259,13 @@ if (nf_register_hook(&ing_ops) < 0) { printk("ingress qdisc registration error \n"); goto error; - } + } nf_registered++; + if (nf_register_hook(&ing6_ops) < 0) { + printk("IPv6 ingress qdisc registration error, " \ + "disabling IPv6 support.\n"); + } else + nf_registered++; } DPRINTK("ingress_init(sch %p,[qdisc %p],opt %p)\n",sch,p,opt); @@ -374,8 +389,11 @@ void cleanup_module(void) { unregister_qdisc(&ingress_qdisc_ops); - if (nf_registered) + if (nf_registered) { nf_unregister_hook(&ing_ops); + if (nf_registered > 1) + nf_unregister_hook(&ing6_ops); + } } #endif MODULE_LICENSE("GPL"); From davem@davemloft.net Wed Feb 2 14:37:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:37:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mb1Tm000886 for ; Wed, 2 Feb 2005 14:37:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwT1D-0002Yt-00; Wed, 02 Feb 2005 14:30:39 -0800 Date: Wed, 2 Feb 2005 14:30:38 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets Message-Id: <20050202143038.0e0e5dbc.davem@davemloft.net> In-Reply-To: <20050202223629.GS31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> <20050202130743.065bc627.davem@davemloft.net> <20050202223629.GS31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 2 Feb 2005 23:36:29 +0100 Thomas Graf wrote: > Signed-off-by: Thomas Graf Applied, thanks Thomas. From rugolsky@telemetry-investments.com Wed Feb 2 14:39:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:39:04 -0800 (PST) Received: from ti41.telemetry-investments.com (209-166-240-202.cust.walrus.com [209.166.240.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mcx0K001751 for ; Wed, 2 Feb 2005 14:39:00 -0800 Received: from ti64.telemetry-investments.com (ti64 [192.168.8.64]) by ti41.telemetry-investments.com (Postfix) with ESMTP id E75EB10101; Wed, 2 Feb 2005 17:38:53 -0500 (EST) Received: by ti64.telemetry-investments.com (Postfix, from userid 343) id E1A38FF2C; Wed, 2 Feb 2005 17:38:53 -0500 (EST) Date: Wed, 2 Feb 2005 17:38:53 -0500 From: "Bill Rugolsky Jr." To: Olaf Hering Cc: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202223853.GA29237@ti64.telemetry-investments.com> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202222516.GA15440@suse.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brugolsky@telemetry-investments.com Precedence: bulk X-list: netdev On Wed, Feb 02, 2005 at 11:25:16PM +0100, Olaf Hering wrote: > it triggers the first -ENOMEM in > net/ipv4/netfilter/ip_tables.c:do_replace > > sizeof(struct ipt_table_info)+SMP_ALIGN(tmp.size)*NR_CPUS == 67108992 bytes > > 128+524288*128==67108992 > > (sizeof(struct ipt_table_info) + (((tmp.size) + (1 << 7)-1) & ~((1 << 7)-1)) * 128) > > hmm, no braces missing. I don't have time to look now [I'm running for the door], but that's possibly the vmalloc() limit of 64M (67108864) ? Regards, Bill Rugolsky From olh@suse.de Wed Feb 2 14:53:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:53:09 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mr3kI002813 for ; Wed, 2 Feb 2005 14:53:04 -0800 Received: from hermes.suse.de (hermes-ext.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 4DF6C13F53A1; Wed, 2 Feb 2005 23:52:58 +0100 (CET) Date: Wed, 2 Feb 2005 23:52:58 +0100 From: Olaf Hering To: "Bill Rugolsky Jr." Cc: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202225258.GA15563@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050202223853.GA29237@ti64.telemetry-investments.com> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev On Wed, Feb 02, Bill Rugolsky Jr. wrote: > I don't have time to look now [I'm running for the door], > but that's possibly the vmalloc() limit of 64M (67108864) ? maybe. ->size is a userprovided value, havent looked closely at iptables source. It seems we have to live with this limitation. From davem@davemloft.net Wed Feb 2 16:15:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 16:15:20 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j130FDB5011276 for ; Wed, 2 Feb 2005 16:15:14 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwUYF-000304-00; Wed, 02 Feb 2005 16:08:51 -0800 Date: Wed, 2 Feb 2005 16:08:51 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.10] tg3: 5704 serdes fixes Message-Id: <20050202160851.27e532f6.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 27 Jan 2005 14:43:34 -0800 "Michael Chan" wrote: > Some 5704S and related fixes: > > - Fix capacitive coupling detection by reading the correct offset in sram > - Add support for different signal pre-emphasis on 5704S (used in some blade > servers) > - Improve 5704S link parallel detection. When autonegotiation fails, we only > detect link-up if we have PCS_SYNC and we are not receiving config code > words. This will prevent false link-up when only the rx cable is attached. Applied, thanks Michael. From davem@davemloft.net Wed Feb 2 16:27:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 16:27:39 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j130RV2c015319 for ; Wed, 2 Feb 2005 16:27:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwUjP-00031T-00; Wed, 02 Feb 2005 16:20:23 -0800 Date: Wed, 2 Feb 2005 16:20:23 -0800 From: "David S. Miller" To: Herbert Xu Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050202162023.075015d4.davem@davemloft.net> In-Reply-To: References: <20050131102920.GC4170@suse.de> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 22:33:26 +1100 Herbert Xu wrote: > We're using atomic integers to signal that we're done with an object. > The object is usually represented by a piece of memory. > > The problem is that in most of the places where we do this (and that's > not just in the networking systems), there are no memory barriers between > the last reference to that object and the decrease on the atomic counter. I agree. > if (atomic_read(&skb->users) != 1) { > smp_mb__before_atomic_dec(); > if (!atomic_dec_and_test(&skb->users)) > return; > } > __kfree_skb(skb); This looks good. Olaf can you possibly ask the reproducer if this patch makes the ARP problem go away? # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/02 15:53:55-08:00 herbert@gondor.apana.org.au # [NET]: Add missing memory barrier to SKB release. # # Here, we are using atomic counters to signal that we are done # with an object. The object is usually represented by a piece # of memory. # # The problem is that in most of the places we do this, there are # no memory barriers between the last reference to that object # and the decrease on the atomic counter. # # Based upon a race spotted in arp_queue handling by Olaf Kirch. # # Signed-off-by: David S. Miller # # include/linux/skbuff.h # 2005/02/02 15:51:57-08:00 herbert@gondor.apana.org.au +6 -2 # [NET]: Add missing memory barrier to SKB release. # diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h --- a/include/linux/skbuff.h 2005-02-02 15:54:13 -08:00 +++ b/include/linux/skbuff.h 2005-02-02 15:54:13 -08:00 @@ -353,8 +353,12 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); + if (atomic_read(&skb->users) != 1) { + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + } + __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ From davem@davemloft.net Wed Feb 2 17:23:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 17:23:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j131NSRf017686 for ; Wed, 2 Feb 2005 17:23:28 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwVcD-0003Gg-00; Wed, 02 Feb 2005 17:17:01 -0800 Date: Wed, 2 Feb 2005 17:17:01 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 1/2] ipv4 routing: splitting of ip_route_[in|out]put_slow, 2.6.10-rc3 Message-Id: <20050202171701.18a81a6a.davem@davemloft.net> In-Reply-To: <41C6B3D4.6060207@einar-lueck.de> References: <41C6B3D4.6060207@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j131NSRf017686 X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 20 Dec 2004 12:13:24 +0100 Einar Lück wrote: > This patch splits up ip_route_[in|out]put_slow in inlined functions. > Basic idea: > * improve overall comprehensibility > * allow for an easier application of patch for improved multipath > support Patch applied to my 2.6.12 pending tree. Thanks a lot Einar. One minor comment is that there are some minor cases where excessing in_dev get/put can be eliminated. For example, in __mkroute_output() we really only need to do the in_dev_get(dev_out) once, yet we do it twice due to how the return path of this function always puts the reference even in the non-error case. From davem@davemloft.net Wed Feb 2 17:30:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 17:30:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j131U4im018252 for ; Wed, 2 Feb 2005 17:30:05 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwViX-0003JH-00; Wed, 02 Feb 2005 17:23:33 -0800 Date: Wed, 2 Feb 2005 17:23:33 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Message-Id: <20050202172333.4d0ad5f0.davem@davemloft.net> In-Reply-To: <41C6B54F.2020604@einar-lueck.de> References: <41C6B54F.2020604@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j131U4im018252 X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 20 Dec 2004 12:19:43 +0100 Einar Lück wrote: > This patch is an approach towards solving some problems with the > current multipath implementation: > * routing cache allows only one route to be cached for a certain > search key > * a mulitpath/load balancing decision is only made in case a > corresponding route is not yet cached > In the scenarios, that are relevant to us (high amount of outgoing > connection requests), this is a serious problem. I agree that per-connection attempt a new multipath decision should be made, but within a flow I disagree. This needs to be flow based. Can you describe more precisely "the scenerios, that are relevant to us"? If you are only interested in more precise multipathing when TCP connections on the local system are made, this we can implement via a flag to the ipv4 routing cache which forces a new multipath decision when TCP sockets have their identity established. We have a precise interface that is invoked at this time, called ip_route_connect(). So that is where we would pass in some flag to indicate that we desire the new multipath behavior. If you want this behavior on a router, you will need to mark the packets using something like firewall marking on the SKB, then this mark would be used at route cache lookup time to determine what kind of multipath decisions to make. There is no way we can enable the new behavior for every routing cache lookup. From webmaster@rapidforum.com Wed Feb 2 20:07:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 20:07:49 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1347iix022816 for ; Wed, 2 Feb 2005 20:07:45 -0800 Received: (qmail 2179 invoked by uid 1004); 3 Feb 2005 04:07:42 -0000 Received: from p3ee04c23.dip0.t-ipconnect.de (HELO ?62.224.76.35?) (62.224.76.35) by www.rapidforum.com with SMTP; 3 Feb 2005 04:07:42 -0000 Message-ID: <4201A382.1020208@rapidforum.com> Date: Thu, 03 Feb 2005 05:07:30 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: TCP-Protection is really a pain... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Hi. Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell me a way how to disable it. Thank you. Best regards, Christian Schmid From shemminger@osdl.org Wed Feb 2 20:54:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 20:54:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j134sg5Q028359 for ; Wed, 2 Feb 2005 20:54:43 -0800 Received: from localhost.localdomain (m810f36d0.tmodns.net [208.54.15.129]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j134sYuN024883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Feb 2005 20:54:36 -0800 Date: Wed, 2 Feb 2005 20:54:37 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050202205437.571a702b@localhost.localdomain> In-Reply-To: <4201A382.1020208@rapidforum.com> References: <4201A382.1020208@rapidforum.com> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 05:07:30 +0100 Christian Schmid wrote: > Hi. > > Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell > me a way how to disable it. sysctl -w net.ipv4.tcp_wmem="4096 8192 16384" Your single stream will be slower, but the memory footprint will be smaller. From webmaster@rapidforum.com Wed Feb 2 21:22:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 21:22:29 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j135MMlp029340 for ; Wed, 2 Feb 2005 21:22:23 -0800 Received: (qmail 4401 invoked by uid 1004); 3 Feb 2005 05:22:22 -0000 Received: from p3ee04c23.dip0.t-ipconnect.de (HELO ?62.224.76.35?) (62.224.76.35) by www.rapidforum.com with SMTP; 3 Feb 2005 05:22:22 -0000 Message-ID: <4201B4EA.2030101@rapidforum.com> Date: Thu, 03 Feb 2005 06:21:46 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> In-Reply-To: <20050202205437.571a702b@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every second now... *sigh* well maybe you might just want to add a /proc file in order to configure this behaviour. btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue is completely full (checked with a grep in netstat). This looks like as if the receiver is just too slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty pipe but linux doesn't send. What could this be? Stephen Hemminger wrote: > On Thu, 03 Feb 2005 05:07:30 +0100 > Christian Schmid wrote: > > >>Hi. >> >>Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell >>me a way how to disable it. > > > sysctl -w net.ipv4.tcp_wmem="4096 8192 16384" > > Your single stream will be slower, but the memory footprint will be smaller. > > From jgarzik@pobox.com Wed Feb 2 22:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 22:51:08 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j136p33C032313 for ; Wed, 2 Feb 2005 22:51:04 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwapR-0006BP-Qj; Thu, 03 Feb 2005 06:51:02 +0000 Message-ID: <4201C9C5.1060002@pobox.com> Date: Thu, 03 Feb 2005 01:50:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> In-Reply-To: <4201B4EA.2030101@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1217 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 Christian Schmid wrote: > btw: Another problem I am experiencing is that downloads suddenly break > in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they stall > completely. But the interesting part is, that the send-queue is > completely full (checked with a grep in netstat). This looks like as if > the receiver is just too slow. But this is not the case. That makes it > rather funny. The receiver is waiting with an empty pipe but linux > doesn't send. What could this be? With recent kernels, I've noticed that my browser progress bar will download about 98% of a page, then stall for several seconds, then complete. Very strange. Haven't investigated it at all, though. Jeff From herbert@gondor.apana.org.au Thu Feb 3 03:13:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 03:13:35 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13BDQGo012879 for ; Thu, 3 Feb 2005 03:13:27 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cweuy-0008Jl-00; Thu, 03 Feb 2005 22:13:00 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CweuO-0000xa-00; Thu, 03 Feb 2005 22:12:24 +1100 Date: Thu, 3 Feb 2005 22:12:24 +1100 To: "David S. Miller" Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203111224.GA3267@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050202162023.075015d4.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20050202162023.075015d4.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 02, 2005 at 04:20:23PM -0800, David S. Miller wrote: > > > if (atomic_read(&skb->users) != 1) { > > smp_mb__before_atomic_dec(); > > if (!atomic_dec_and_test(&skb->users)) > > return; > > } > > __kfree_skb(skb); > > This looks good. Olaf can you possibly ask the reproducer if > this patch makes the ARP problem go away? Not so hasty Dave :) That was only meant to be an example of what we might do to insert a write barrier in kfree_skb(). It doesn't solve Olaf's problem because a write barrier is usually not sufficient by itself. In most cases you'll need a read barrier as well. So if we're going for a solution that only involves kfree_skb() then we'll need the following patch. I got rid of the atomic_read optimisation since it would've needed an additional smp_rmb() to be safe. I thought about preserving that optimisation through something like skb->cloned. However, it turns out that most skb's will be shared at least once so it doesn't buy us much. Signed-off-by: Herbert Xu What I hoped to do though was to bring your collective attention to the problem in general. kfree_skb() is certainly not the only place where we free an object after the counter hits zero. This paradigm is repeated throughout the kernel. I bet the same race can be found in a lot of those places. So we really need to sit down and audit them one by one or else come up with a magical solution apart from disabling SMP :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-03 21:57:26 +11:00 @@ -353,15 +353,21 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + smp_mb__after_atomic_dec(); + __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ static inline void kfree_skb_fast(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - kfree_skbmem(skb); + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + smp_mb__after_atomic_dec(); + kfree_skbmem(skb); } /** --fdj2RfSjLxBAspz7-- From okir@suse.de Thu Feb 3 03:19:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 03:19:56 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13BJnLW013506 for ; Thu, 3 Feb 2005 03:19:50 -0800 Received: from hermes.suse.de (hermes-ext.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 0C48A13FA6DF; Thu, 3 Feb 2005 12:19:44 +0100 (CET) Date: Thu, 3 Feb 2005 12:19:39 +0100 From: Olaf Kirch To: Olaf Hering Cc: "Bill Rugolsky Jr." , netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203111939.GI31570@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202225258.GA15563@suse.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1219 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 On Wed, Feb 02, 2005 at 11:52:58PM +0100, Olaf Hering wrote: > > I don't have time to look now [I'm running for the door], > > but that's possibly the vmalloc() limit of 64M (67108864) ? > > maybe. > ->size is a userprovided value, havent looked closely at iptables > source. It seems we have to live with this limitation. The problem is two-fold. netfilter tries to allocate some data per-CPU and does vmalloc(sizeof(struct ipt_table_info) + SMP_ALIGN(tmp.size) * NR_CPUS); At 3445 rules, tmp.size is 524272 (why does it want that much memory? I would expect the only data that's per-CPU is the packet and byte counters). In some of our kernel configurations, NR_CPUS is 128 or even more, and we run into a vmalloc limit here. vmalloc wants to allocate an arrays of struct page pointers, and on a 64bit platform this means you're limited to 131072 / 8 = 16384 pages, or 67108864 bytes. In the example Olaf H posted, we fail at 128 + 524272 * 128 = 67108992 bytes, i.e. 16385 pages. So I guess it all boils down to why netfilter needs 150-odd bytes per rule and CPU. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From cranium.2003@gmail.com Thu Feb 3 05:18:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 05:18:25 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DIKYY020288 for ; Thu, 3 Feb 2005 05:18:20 -0800 Received: by rproxy.gmail.com with SMTP id b11so189718rne for ; Thu, 03 Feb 2005 05:18:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=D26WPYq1HfHPFVC6sKeCtv2ndcC5/3hW4Xr50EGfPn4QHNsTrn27tcSNlJtOkRML2r+gTarck0HzutUtQ691pqv/9yAFQyP6Strd4+9rkzmCHSJiBBGIn3s89dzvt4D6rc0cHVZG5meFqN3XbkUocdzmhm3HRDnjlp6fhVPtp2k= Received: by 10.38.71.60 with SMTP id t60mr71870rna; Thu, 03 Feb 2005 05:18:19 -0800 (PST) Received: by 10.38.81.57 with HTTP; Thu, 3 Feb 2005 05:18:19 -0800 (PST) Message-ID: <1d55641b05020305182d423c57@mail.gmail.com> Date: Thu, 3 Feb 2005 18:48:19 +0530 From: cranium 2003 Reply-To: cranium 2003 To: netdev@oss.sgi.com, kernelnewbies Subject: Which function at link layer sends packet? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium.2003@gmail.com Precedence: bulk X-list: netdev Hello, In a LAN i have 2 pcs host1 with 10.0.2.10 and host2 with eth0:10.0.0.100 and eth1:192.168.1.1 Both are connected to switch. what i observe that when i ping from 10.0.2.10 to 192.168.1.1 then packet is sent through dev_queue_xmit_nit. In that function it goes upto ptype->func(skb2, skb->dev, ptype); and then i am not getting which functions get called but then i found call goes to ethernet driver to NIC card. Does that mean above statement calls hard_start_xmit? Then i reboot my linux RH9 with 2.4.24 kernel PC and again ping to 192.168.1.1 and found that packet transmission is not going through dev_queu_xmit_nit but from dev_queue_xmit to hard_start_xmit. regards, cranium. From cranium.2003@gmail.com Thu Feb 3 05:21:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 05:21:34 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DLUKZ020791 for ; Thu, 3 Feb 2005 05:21:31 -0800 Received: by rproxy.gmail.com with SMTP id b11so190121rne for ; Thu, 03 Feb 2005 05:21:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=J2V4ai+DvBHX6Cle350DoAMudmZclGsOGkd7PVPG8CvcuxL3O+gJFVMo9+mjChjRxWGYbplo6ugLBf4luGNhaQpMy0JcpYnVYSgmPMDCSD5a/w4ovQ6qFkwb/xj8arY5/siL9cxGB3qpH16VHMJj7XhqNfzxJYj26S/KPM23S/M= Received: by 10.38.98.76 with SMTP id v76mr61186rnb; Thu, 03 Feb 2005 05:21:30 -0800 (PST) Received: by 10.38.81.57 with HTTP; Thu, 3 Feb 2005 05:21:30 -0800 (PST) Message-ID: <1d55641b050203052150cbbea3@mail.gmail.com> Date: Thu, 3 Feb 2005 18:51:30 +0530 From: cranium 2003 Reply-To: cranium 2003 To: netdev@oss.sgi.com, linux-net@vger.linux.org Subject: How much ARP requests need to single IP address? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium.2003@gmail.com Precedence: bulk X-list: netdev Hello, In Linux kernel by adding debug statement i observe that if i ping to host 10.0.0.5 with 10 packets then first i know network stack require to resolve hosts IP to its Hardware ID by sending ARP on Ethernet LAN. But then what i get that if i again ping for another 10 packets to 10.0.0.5 then ARP routine is called. Why? Why linux kernel is not caching it. Infact its caching i check it in debug statements then why network stack require to resolve 10.0.0.5 host to send packets to it? Also i want to know once eth_header_cache called then all successive packet to that cache host goes directly from hh->hh_output(skb) to hard_start_xmit? regards, cranium From anton@ozlabs.org Thu Feb 3 06:30:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 06:30:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13EU1xa023484 for ; Thu, 3 Feb 2005 06:30:01 -0800 Received: by ozlabs.org (Postfix, from userid 1010) id 5210667A5D; Fri, 4 Feb 2005 01:29:55 +1100 (EST) Date: Fri, 4 Feb 2005 01:27:05 +1100 From: Anton Blanchard To: Herbert Xu Cc: Olaf Kirch , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Hi, > For example, in this particular case, a more sinister (but probably > impossible for sk_buff objects) problem would be for the list removal > itself to be delayed until after the the kfree_skb. This could > potentially mean that we're reading/writing memory that's already > been freed. > > Perhaps we should always add a barrier to such operations. So > kfree_skb would become > > if (atomic_read(&skb->users) != 1) { > smp_mb__before_atomic_dec(); > if (!atomic_dec_and_test(&skb->users)) > return; > } > __kfree_skb(skb); Architectures should guarantee that any of the atomics and bitops that return values order in both directions. So you dont need the smp_mb__before_atomic_dec here. It is, however, required on the atomics and bitops that dont return values. Its difficult stuff, everyone gets it wrong and Andrew keeps hassling me to write up a document explaining it. Anton From Robert.Olsson@data.slu.se Thu Feb 3 07:24:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 07:25:05 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13FOwx0026211 for ; Thu, 3 Feb 2005 07:24:59 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j13FOswY010556; Thu, 3 Feb 2005 16:24:54 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 49C33EE2A4; Thu, 3 Feb 2005 16:24:54 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16898.16966.272116.431070@robur.slu.se> Date: Thu, 3 Feb 2005 16:24:54 +0100 To: Nishanth Aravamudan Cc: davem@davemloft.net, robert.olsson@its.uu.se, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 5/20] net/pktgen: remove interruptible_sleep_on_timeout() usage In-Reply-To: <20050202185823.GG2546@us.ibm.com> References: <20050202185823.GG2546@us.ibm.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1223 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 Nishanth Aravamudan writes: > The first and last replacements in the following patch were slightly confusing > to me, as I have not used wait-queues that much myself. I did not exactly > understand how a locally defined wait-queue could be slept on, especially since > there are no wake_up() calls in pktgen.c. I was tempted to make the first sleep > a msleep_interruptible(100), but decided to patch for the same code before I did > that. > > Description: Replace deprecated interruptible_sleep_on_timeout() with direct > wait-queue usage or wait_event_interruptible_timeout() as appropriate. Tbanks! I've tested the patch w. msleep_interruptible(). It seems fine. Dave. This is on top of a patch I sent some days ago.. --ro --- net/core/pktgen.c.050201 2005-02-03 14:38:33.337577424 +0100 +++ net/core/pktgen.c 2005-02-03 15:44:22.959143680 +0100 @@ -104,6 +104,8 @@ * Corrections from Nikolai Malykh (nmalykh@bilim.com) * Removed unused flags F_SET_SRCMAC & F_SET_SRCIP 041230 * + * interruptible_sleep_on_timeout() replaced Nishanth Aravamudan + * 050103 */ #include #include @@ -135,6 +137,7 @@ #include #include #include +#include #include #include #include @@ -148,7 +151,7 @@ #include -#define VERSION "pktgen v2.56: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.57: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -2402,16 +2405,14 @@ static int pktgen_wait_thread_run(struct pktgen_thread *t ) { - wait_queue_head_t queue; - - init_waitqueue_head(&queue); - if_lock(t); while(thread_is_running(t)) { + if_unlock(t); - - interruptible_sleep_on_timeout(&queue, HZ/10); + + msleep_interruptible(100); + if (signal_pending(current)) goto signal; if_lock(t); @@ -2733,6 +2734,7 @@ static void pktgen_thread_worker(struct pktgen_thread *t) { + DEFINE_WAIT(wait); struct pktgen_dev *pkt_dev = NULL; int cpu = t->cpu; sigset_t tmpsig; @@ -2800,9 +2802,11 @@ do_softirq(); tx_since_softirq = 0; } + } else { + prepare_to_wait(&(t->queue), &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&(t->queue), &wait); } - else - interruptible_sleep_on_timeout(&(t->queue), HZ/10); /* * Back from sleep, either due to the timeout or signal. @@ -3112,8 +3116,7 @@ struct pktgen_thread *t = pktgen_threads; pktgen_threads->control |= (T_TERMINATE); - while( t == pktgen_threads) - interruptible_sleep_on_timeout(&queue, HZ); + wait_event_interruptible_timeout(queue, (t != pktgen_threads), HZ); } /* Un-register us from receiving netdevice events */ From abreu@datacom-telematica.com.br Thu Feb 3 08:51:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 08:51:05 -0800 (PST) Received: from eserver.datacom-telematica.com.br (radio-112-3.poa.terraempresas.com.br [200.176.112.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Gp0uf001120 for ; Thu, 3 Feb 2005 08:51:00 -0800 Received: (qmail 20815 invoked by uid 89); 3 Feb 2005 16:50:52 -0000 Received: from abreu@datacom-telematica.com.br by eserver by uid 89 with qmail-scanner-1.22 (clamdscan: 0.70. spamassassin: 2.55. Clear:RC:1(192.168.11.35):. Processed in 0.035529 secs); 03 Feb 2005 16:50:52 -0000 Received: from unknown (HELO abreu.local) (abreu@192.168.11.35) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Feb 2005 16:50:52 -0000 Date: Thu, 3 Feb 2005 14:51:10 -0200 From: DataCom - Abreu To: netdev@oss.sgi.com Subject: 8139too interframe gap Message-Id: <20050203145110.06fa5ca6.abreu@datacom-telematica.com.br> Organization: DataCom X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abreu@datacom-telematica.com.br Precedence: bulk X-list: netdev Hi, The driver 8139too configures interframe gap with the shortest possible interval. This behaviour was commited by Jeff on version 0.9.4.1. From changelog: * Do not set Interfame Gap (IFG) bits in TxConfig The chip spec, though, says that these bits must be set in order to conform to 802.3. There is a comment on the code that says exactly the opposite. I would like to know why the configuration is set this way. I have a problem where an external device inserts VLAN tags in frames, thus reducing the gap more yet. After that, too close frames (except the first one) are not recognized by a switch. I have set these bits and my problem disappears. My patch follows: --- linux-2.6.10/drivers/net/8139too.c 2004-12-24 19:33:47.000000000 -0200 +++ linux-2.6.10-mod/drivers/net/8139too.c 2005-02-03 13:47:15.000000000 -0200 @@ -391,7 +391,7 @@ /* Bits in TxConfig. */ enum tx_config_bits { TxIFG1 = (1 << 25), /* Interframe Gap Time */ - TxIFG0 = (1 << 24), /* Enabling these bits violates IEEE 802.3 */ + TxIFG0 = (1 << 24), /* Disabling any of these bits violates IEEE 802.3 */ TxLoopBack = (1 << 18) | (1 << 17), /* enable loopback test mode */ TxCRC = (1 << 16), /* DISABLE appending CRC to end of Tx packets */ TxClearAbt = (1 << 0), /* Clear abort (WO) */ @@ -723,7 +723,7 @@ #endif static const unsigned int rtl8139_tx_config = - (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); + TxIFG1 | TxIFG0 | (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); static void __rtl8139_cleanup_dev (struct net_device *dev) { Thanks. Marcelo Abreu From webmaster@rapidforum.com Thu Feb 3 09:04:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 09:04:43 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13H4cup002148 for ; Thu, 3 Feb 2005 09:04:39 -0800 Received: (qmail 2347 invoked by uid 1004); 3 Feb 2005 17:04:37 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 17:04:37 -0000 Message-ID: <42025998.5070704@rapidforum.com> Date: Thu, 03 Feb 2005 18:04:24 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <4201C9C5.1060002@pobox.com> In-Reply-To: <4201C9C5.1060002@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Several users complain about downloads stalling at 99% as well... I was unable to solve this issue. Jeff Garzik wrote: > Christian Schmid wrote: > >> btw: Another problem I am experiencing is that downloads suddenly >> break in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they >> stall completely. But the interesting part is, that the send-queue is >> completely full (checked with a grep in netstat). This looks like as >> if the receiver is just too slow. But this is not the case. That makes >> it rather funny. The receiver is waiting with an empty pipe but linux >> doesn't send. What could this be? > > > > With recent kernels, I've noticed that my browser progress bar will > download about 98% of a page, then stall for several seconds, then > complete. > > Very strange. Haven't investigated it at all, though. > > Jeff > > > > From davem@davemloft.net Thu Feb 3 10:21:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:21:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13ILdYe004754 for ; Thu, 3 Feb 2005 10:21:40 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwlUj-0007BL-00; Thu, 03 Feb 2005 10:14:21 -0800 Date: Thu, 3 Feb 2005 10:14:20 -0800 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203101420.468c1607.davem@davemloft.net> In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 01:27:05 +1100 Anton Blanchard wrote: > Architectures should guarantee that any of the atomics and bitops that > return values order in both directions. So you dont need the > smp_mb__before_atomic_dec here. > > It is, however, required on the atomics and bitops that dont return > values. Its difficult stuff, everyone gets it wrong and Andrew keeps > hassling me to write up a document explaining it. Sparc64 happens to order the atomic we use in the bitops and atomic_t ops, so sparc64 gets this right by accident. I had no idea about this requirement before reading your email. If IBM is seeing race this on ppc64, then I'm even more confused. If Anton understands the requirements, then ppc64 should have the return value atomic's implemented with the proper barriers. From davem@davemloft.net Thu Feb 3 10:55:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:55:10 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13It5hV005957 for ; Thu, 3 Feb 2005 10:55:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cwm1e-0007JB-00; Thu, 03 Feb 2005 10:48:22 -0800 Date: Thu, 3 Feb 2005 10:48:22 -0800 From: "David S. Miller" To: Olaf Kirch Cc: olh@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-Id: <20050203104822.05be3281.davem@davemloft.net> In-Reply-To: <20050203111939.GI31570@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 3 Feb 2005 12:19:39 +0100 Olaf Kirch wrote: > At 3445 rules, tmp.size is 524272 (why does it want that much memory? I > would expect the only data that's per-CPU is the packet and byte > counters). The rule itself is replicated per-cpu as well to keep L2 cache accesses local per cpu on SMP systems. From olh@suse.de Thu Feb 3 10:59:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:59:45 -0800 (PST) Received: from Cantor.suse.de (news.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Ixdtn006456 for ; Thu, 3 Feb 2005 10:59:39 -0800 Received: from hermes.suse.de (hermes-ext.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 317B113FE6A8; Thu, 3 Feb 2005 19:59:33 +0100 (CET) Date: Thu, 3 Feb 2005 19:59:28 +0100 From: Olaf Hering To: "David S. Miller" Cc: Olaf Kirch , brugolsky@telemetry-investments.com, netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203185928.GA22832@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050203104822.05be3281.davem@davemloft.net> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev On Thu, Feb 03, David S. Miller wrote: > On Thu, 3 Feb 2005 12:19:39 +0100 > Olaf Kirch wrote: > > > At 3445 rules, tmp.size is 524272 (why does it want that much memory? I > > would expect the only data that's per-CPU is the packet and byte > > counters). > > The rule itself is replicated per-cpu as well to keep L2 cache > accesses local per cpu on SMP systems. Andy made this change, which helped on a dual box. diff -u linux-2.6.5/net/ipv4/netfilter/ip_tables.c-o linux-2.6.5/net/ipv4/netfilter/ip_tables.c --- linux-2.6.5/net/ipv4/netfilter/ip_tables.c-o 2005-02-03 08:06:33.000000000 +0100 +++ linux-2.6.5/net/ipv4/netfilter/ip_tables.c 2005-02-03 13:06:32.163182472 +0100 @@ -29,6 +29,12 @@ #include +#ifdef CONFIG_HOTPLUG_CPU +#define NF_NR_CPUS NR_CPUS +#else +#define NF_NR_CPUS num_online_cpus() +#endif + MODULE_LICENSE("GPL"); MODULE_AUTHOR("Netfilter Core Team "); MODULE_DESCRIPTION("IPv4 packet filter"); @@ -860,7 +866,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < NF_NR_CPUS; i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -882,7 +888,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < NF_NR_CPUS; i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -929,7 +935,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < NF_NR_CPUS; cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1067,7 +1073,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * NF_NR_CPUS); if (!newinfo) return -ENOMEM; @@ -1380,7 +1386,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(table->table->size) * NR_CPUS); + + SMP_ALIGN(table->table->size) * NF_NR_CPUS); if (!newinfo) return -ENOMEM; diff -u linux-2.6.5/mm/vmalloc.c-o linux-2.6.5/mm/vmalloc.c --- linux-2.6.5/mm/vmalloc.c-o 2005-02-03 08:06:50.000000000 +0100 +++ linux-2.6.5/mm/vmalloc.c 2005-02-03 13:07:44.162236952 +0100 @@ -310,7 +310,10 @@ __free_page(area->pages[i]); } - kfree(area->pages); + if (area->nr_pages * sizeof(struct page *) >= 4*PAGE_SIZE) + vfree(area->pages); + else + kfree(area->pages); } kfree(area); @@ -414,7 +417,11 @@ array_size = (nr_pages * sizeof(struct page *)); area->nr_pages = nr_pages; - area->pages = pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM)); + + if (array_size >= 4*PAGE_SIZE) + area->pages = pages = __vmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM), PAGE_KERNEL); + else + area->pages = pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM)); if (!area->pages) { remove_vm_area(area->addr); kfree(area); From davem@davemloft.net Thu Feb 3 11:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:07:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13J7X8Z007051 for ; Thu, 3 Feb 2005 11:07:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwmDh-0007Ne-00; Thu, 03 Feb 2005 11:00:49 -0800 Date: Thu, 3 Feb 2005 11:00:49 -0800 From: "David S. Miller" To: Olaf Hering Cc: okir@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: limited number if iptable rules on 64bit hosts Message-Id: <20050203110049.6b2d9c64.davem@davemloft.net> In-Reply-To: <20050203185928.GA22832@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 3 Feb 2005 19:59:28 +0100 Olaf Hering wrote: > On Thu, Feb 03, David S. Miller wrote: > > > The rule itself is replicated per-cpu as well to keep L2 cache > > accesses local per cpu on SMP systems. > > Andy made this change, which helped on a dual box. It might not help for Olaf's 128 cpu box though :-) I think reconsider the idea of replicating the rule itself per-cpu. Also, this thread should have begun with netfilter-devel at least on the CC:, added. From bdschuym@pandora.be Thu Feb 3 11:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:27:47 -0800 (PST) Received: from asia.telenet-ops.be (asia.telenet-ops.be [195.130.132.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JRghW007851 for ; Thu, 3 Feb 2005 11:27:43 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id 9BCCC22413B; Thu, 3 Feb 2005 20:27:41 +0100 (MET) Received: from 192.168.0.138 (dD5763CA9.access.telenet.be [213.118.60.169]) by asia.telenet-ops.be (Postfix) with ESMTP id 0F0AF224085; Thu, 3 Feb 2005 20:27:41 +0100 (MET) Subject: Re: limited number if iptable rules on 64bit hosts From: Bart De Schuymer To: "David S. Miller" Cc: Olaf Hering , okir@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org In-Reply-To: <20050203110049.6b2d9c64.davem@davemloft.net> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> <20050203110049.6b2d9c64.davem@davemloft.net> Content-Type: text/plain Date: Thu, 03 Feb 2005 20:33:51 +0100 Message-Id: <1107459231.3381.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bdschuym@pandora.be Precedence: bulk X-list: netdev Op do, 03-02-2005 te 11:00 -0800, schreef David S. Miller: > On Thu, 3 Feb 2005 19:59:28 +0100 > Olaf Hering wrote: > > > On Thu, Feb 03, David S. Miller wrote: > > > > > The rule itself is replicated per-cpu as well to keep L2 cache > > > accesses local per cpu on SMP systems. > > > > Andy made this change, which helped on a dual box. > > It might not help for Olaf's 128 cpu box though :-) > > I think reconsider the idea of replicating the rule itself per-cpu. > Also, this thread should have begun with netfilter-devel at least on > the CC:, added. Note that ebtables only has per-cpu counters. I wonder what limits are seen on such systems for ebtables. cheers, Bart From shemminger@osdl.org Thu Feb 3 11:33:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:33:50 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JXgZW008383 for ; Thu, 3 Feb 2005 11:33:43 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13JXPl11349; Thu, 3 Feb 2005 11:33:26 -0800 Date: Thu, 3 Feb 2005 11:33:35 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050203113335.46396c11@dxpl.pdx.osdl.net> In-Reply-To: <4201B4EA.2030101@rapidforum.com> References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 06:21:46 +0100 Christian Schmid wrote: > Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was > very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every > second now... *sigh* well maybe you might just want to add a /proc file in order to configure this > behaviour. > > btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to > 8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue > is completely full (checked with a grep in netstat). This looks like as if the receiver is just too > slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty > pipe but linux doesn't send. What could this be? > Are you using a board that support TCP Segmentation Offload. The problem may well be that before we were not doing congestion control properly with TSO. A pre-2.6.8 host with TSO was violating all sorts of RFC's and unfairly monopolizing bandwidth. -- Stephen Hemminger From shemminger@osdl.org Thu Feb 3 11:52:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:52:18 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JqBnm009293 for ; Thu, 3 Feb 2005 11:52:11 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13JpHl16131; Thu, 3 Feb 2005 11:51:17 -0800 Date: Thu, 3 Feb 2005 11:51:27 -0800 From: Stephen Hemminger To: Lorenzo =?ISO-8859-1?B?SGVybuFuZGV6IEdhcmPtYS1IaWVycm8=?= Cc: linux@horizon.com, mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, Valdis.Kletnieks@vt.edu, spender@grsecurity.net Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050203115127.3245951f@dxpl.pdx.osdl.net> In-Reply-To: <1107365917.3754.155.camel@localhost.localdomain> References: <20050202171702.24523.qmail@science.horizon.com> <1107365917.3754.155.camel@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j13JqBnm009293 X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 02 Feb 2005 18:38:37 +0100 Lorenzo Hernández García-Hierro wrote: > El mié, 02-02-2005 a las 17:17 +0000, linux@horizon.com escribió: > > There *are* things in OpenBSD, like randomized port assignment (as opposed > > to the linear scan in tcp_v4_get_port()) that would be worth emulating. > > Maybe worry about that first? > > Recent 2.6 does a more advanced form of port randomization already using address hash at connect time. tcp_v4_get_port is only used for the case of applications that explicitly bind to port zero to find a free port. So the sequence: socket(); connect(); will assign a random port in a manner similar to sequence number creation The sequence: socket(); bind(); connect(); assigns a simple linear increasing port value. It could be randomized, but most applications don't bother binding, so the first case is sufficient. -- Stephen Hemminger From webmaster@rapidforum.com Thu Feb 3 11:59:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:59:09 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13Jx2C3009985 for ; Thu, 3 Feb 2005 11:59:03 -0800 Received: (qmail 13663 invoked by uid 1004); 3 Feb 2005 19:59:02 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 19:59:02 -0000 Message-ID: <42028278.7040008@rapidforum.com> Date: Thu, 03 Feb 2005 20:58:48 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> In-Reply-To: <20050203113335.46396c11@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Hm how can I check that? and what do you mean with "board"? Mainboard? NIC? its an onboard-nic on this mainboard: http://www.supermicro.com/products/motherboard/Xeon/E7501/X5DP8-G2.cfm The worst thing is the stalled downloads. It drops to 8-12 kb-sec. sometimes after a few seconds it goes up to full speed again, but sometimes it suddenly stops completely. After a few seconds it continues with full speed or it stalls forever. send-queue is always full..... Thank you for your help in this matter. Chris Stephen Hemminger wrote: > On Thu, 03 Feb 2005 06:21:46 +0100 > Christian Schmid wrote: > > >>Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was >>very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every >>second now... *sigh* well maybe you might just want to add a /proc file in order to configure this >>behaviour. >> >>btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to >>8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue >>is completely full (checked with a grep in netstat). This looks like as if the receiver is just too >>slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty >>pipe but linux doesn't send. What could this be? >> > > > Are you using a board that support TCP Segmentation Offload. The problem may well be that > before we were not doing congestion control properly with TSO. A pre-2.6.8 host with TSO was violating > all sorts of RFC's and unfairly monopolizing bandwidth. > From marcel@holtmann.org Thu Feb 3 12:04:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:04:46 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13K4dtu010606 for ; Thu, 3 Feb 2005 12:04:40 -0800 Received: from pegasus (p3EE2CEA9.dip.t-dialin.net [62.226.206.169]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j13K4ihH030983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Feb 2005 21:04:45 +0100 Subject: Problem with "ESP: sha1 digestsize 20 != 0" From: Marcel Holtmann To: Network Development Mailing List Content-Type: text/plain Date: Thu, 03 Feb 2005 21:04:33 +0100 Message-Id: <1107461073.6833.8.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Hi, when using my RAS account with 2.6.11-rc3, I see a lot of ESP: sha1 digestsize 20 != 0 messages in my logs and the IPsec tunnel is not working. I tracked the problem down to the change below. After reverting this patch, everything works like before. Regards Marcel ChangeSet@1.1830.738.7, 2005-01-25 21:53:42-08:00, herbert@gondor.apana.org.au [XFRM]: Probe selected algorithm only. This patch removes an annoying problem in xfrm_user. As it is every time an SA is added it probes every known algorithm in the universe. Now if they all existed it would be OK. However, for the ones which don't actually exist this causes multiple /sbin/modprobe processes to be spawned which slows the system down when you're adding hundreds of SAs. Since we know the type of algorithm required when we're adding a new SA, we can get away with only probing the selected algorithms. This is what the following patch does for xfrm_user. From buytenh@wantstofly.org Thu Feb 3 12:14:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:14:14 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KE9bC011431 for ; Thu, 3 Feb 2005 12:14:10 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 8BA762B0EC; Thu, 3 Feb 2005 21:14:08 +0100 (MET) Date: Thu, 3 Feb 2005 21:14:08 +0100 From: Lennert Buytenhek To: Stephen Hemminger Cc: Lorenzo =?iso-8859-1?Q?Hern=E1ndez_Garc=EDa-Hierro?= , linux@horizon.com, mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, Valdis.Kletnieks@vt.edu, spender@grsecurity.net Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050203201408.GB3199@xi.wantstofly.org> References: <20050202171702.24523.qmail@science.horizon.com> <1107365917.3754.155.camel@localhost.localdomain> <20050203115127.3245951f@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203115127.3245951f@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote: > Recent 2.6 does a more advanced form of port randomization already > using address hash at connect time. tcp_v4_get_port is only used for > the case of applications that explicitly bind to port zero to find a > free port. Is any such randomisation done or planned for UDP? --L From shemminger@osdl.org Thu Feb 3 12:15:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:15:07 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KF1ff011723 for ; Thu, 3 Feb 2005 12:15:01 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13KEsl20870; Thu, 3 Feb 2005 12:14:54 -0800 Date: Thu, 3 Feb 2005 12:15:03 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050203121503.4f122779@dxpl.pdx.osdl.net> In-Reply-To: <42028278.7040008@rapidforum.com> References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 20:58:48 +0100 Christian Schmid wrote: E1000 support TSO. To check if it is enabled do: ethtool -k eth0 To turn it off use. ethtool -K eth0 tso off You get the idea.. -- Stephen Hemminger From webmaster@rapidforum.com Thu Feb 3 12:19:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:19:38 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13KJXNT015791 for ; Thu, 3 Feb 2005 12:19:34 -0800 Received: (qmail 14775 invoked by uid 1004); 3 Feb 2005 20:19:32 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 20:19:32 -0000 Message-ID: <42028747.6060602@rapidforum.com> Date: Thu, 03 Feb 2005 21:19:19 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> In-Reply-To: <20050203121503.4f122779@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on What exactly is tcp segmentation offload? Where can I read more about it? Should I disable it or is this not a good idea? Stephen Hemminger wrote: > On Thu, 03 Feb 2005 20:58:48 +0100 > Christian Schmid wrote: > > E1000 support TSO. To check if it is enabled do: > ethtool -k eth0 > To turn it off use. > ethtool -K eth0 tso off > > You get the idea.. > From herbert@gondor.apana.org.au Thu Feb 3 12:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:31:34 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KVQV3019208 for ; Thu, 3 Feb 2005 12:31:27 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cwncu-0004YC-00; Fri, 04 Feb 2005 07:30:56 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwncA-0001qT-00; Fri, 04 Feb 2005 07:30:10 +1100 Date: Fri, 4 Feb 2005 07:30:10 +1100 To: Anton Blanchard Cc: Olaf Kirch , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203203010.GA7081@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote: > > Architectures should guarantee that any of the atomics and bitops that > return values order in both directions. So you dont need the > smp_mb__before_atomic_dec here. I wasn't aware of this requirement before. However, if this is so, why don't we get rid of the smp_mb__* macros? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Feb 3 12:40:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:40:35 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KeQgc019963 for ; Thu, 3 Feb 2005 12:40:27 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cwnll-0004dv-00; Fri, 04 Feb 2005 07:40:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwnlK-0001rv-00; Fri, 04 Feb 2005 07:39:38 +1100 From: Herbert Xu To: marcel@holtmann.org (Marcel Holtmann) Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" Cc: netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <1107461073.6833.8.camel@pegasus> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 04 Feb 2005 07:39:38 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Marcel Holtmann wrote: > > when using my RAS account with 2.6.11-rc3, I see a lot of > > ESP: sha1 digestsize 20 != 0 > > messages in my logs and the IPsec tunnel is not working. I tracked the > problem down to the change below. After reverting this patch, everything > works like before. Sorry, my fault. The name test in xfrm_get_byname is inverted. Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/xfrm/xfrm_algo.c 1.16 vs edited ===== --- 1.16/net/xfrm/xfrm_algo.c 2005-01-26 16:53:19 +11:00 +++ edited/net/xfrm/xfrm_algo.c 2005-02-04 07:38:16 +11:00 @@ -357,7 +357,7 @@ return NULL; for (i = 0; i < entries; i++) { - if (!strcmp(name, list[i].name)) + if (strcmp(name, list[i].name)) continue; if (list[i].available) From rick.jones2@hp.com Thu Feb 3 12:47:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:47:19 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KlFDa020558 for ; Thu, 3 Feb 2005 12:47:15 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 138809ED for ; Thu, 3 Feb 2005 12:47:15 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id MAA15008 for ; Thu, 3 Feb 2005 12:47:14 -0800 (PST) Message-ID: <42028DD2.2010809@hp.com> Date: Thu, 03 Feb 2005 12:47:14 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> In-Reply-To: <42028747.6060602@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Christian Schmid wrote: > Offload parameters for eth0: > rx-checksumming: on > tx-checksumming: on > scatter-gather: on > tcp segmentation offload: on > > What exactly is tcp segmentation offload? TCP Segmentation Offload, aka TSO or in other contexts "large send" can be thought of as a "poor man's" Jumbo Frame. The NIC advertises to the host that it can resegment larger TCP segments into sizes apropriate for the network. This allows the host CPU stack to make fewer trips down the protocol stack to transfer a given quantity of data, thus reducing the service demand (quantity of CPU consumed per quantity of work). The reduction in service demand can result in an increase in throughput if the transfer was previously CPU-bound. It has the advantage over JumboFrame in that it does not require support in the rest of the infrastructure (switches, routers, receivers etc). I call it "poor man's" JumboFrame because it does not reduce the overheads on the receiver - the receiver still sees just as many "normally" sized segments as before, and sends just as many ACKs per KB transferred as before. If a NIC is implemented with a microprocessor (bletch - personal opinion) the additional demands of TSO resegmenation may actually reduce throughput even as it greatly reduces server CPU utilization. That was particularly evident in old Tigon2 NICs. I am not sure if that is noticable in current generation BMC570X's or not - most of the systems I have at my disposal have BCM5701's in them and I'm not sure the drivers allow TSO to be enabled on that rev? I've not seen a drop in maximum throughput on the "e1000" NICs I've played with, which have been some dual-port cards HP sells. YMMV. > Where can I read more about it? In addition to whatever there may be in Linux documentation... TSO or large send is also a long-standing feature of TCP in AIX and (dare I say it here?-) Windows. As such IBM and Microsoft may have writeups - I'm pretty sure that Microsoft had a write-up about it on their website - talking about the NDIS interface at least. It is also a fairly recent addition to HP-UX, but I am not sure if there are any writeups about it on HP's websites yet. >Should I disable it or is this not a good idea? That depends. If you are concerned about proper slow-start behaviour at the beginning of a connection you should disable it until you are on a later rev. I've always wondered if it wouldn't be an interesting experiment with a "real" server to see if dishonouring slow-start at connection establishment (and there only, keep it after RTO) made all that much a difference in the host's retransmission rates... rick jones From marcel@holtmann.org Thu Feb 3 13:02:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 13:02:55 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13L2oH7021357 for ; Thu, 3 Feb 2005 13:02:51 -0800 Received: from pegasus (p3EE2CEA9.dip.t-dialin.net [62.226.206.169]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j13L2ihH031379 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Feb 2005 22:02:44 +0100 Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" From: Marcel Holtmann To: Herbert Xu Cc: Network Development Mailing List , "David S. Miller" In-Reply-To: References: Content-Type: text/plain Date: Thu, 03 Feb 2005 22:02:33 +0100 Message-Id: <1107464553.6911.0.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Hi Herbert, > > when using my RAS account with 2.6.11-rc3, I see a lot of > > > > ESP: sha1 digestsize 20 != 0 > > > > messages in my logs and the IPsec tunnel is not working. I tracked the > > problem down to the change below. After reverting this patch, everything > > works like before. > > Sorry, my fault. > > The name test in xfrm_get_byname is inverted. now it is working again. Thanks. Regards Marcel From rugolsky@telemetry-investments.com Thu Feb 3 13:35:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 13:35:53 -0800 (PST) Received: from ti41.telemetry-investments.com (209-166-240-202.cust.walrus.com [209.166.240.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13LZmij022324 for ; Thu, 3 Feb 2005 13:35:49 -0800 Received: from ti64.telemetry-investments.com (ti64 [192.168.8.64]) by ti41.telemetry-investments.com (Postfix) with ESMTP id DF13E10107; Thu, 3 Feb 2005 16:35:42 -0500 (EST) Received: by ti64.telemetry-investments.com (Postfix, from userid 343) id D41EFFF2C; Thu, 3 Feb 2005 16:35:42 -0500 (EST) Date: Thu, 3 Feb 2005 16:35:42 -0500 From: "Bill Rugolsky Jr." To: "David S. Miller" Cc: Olaf Hering , okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203213542.GC16868@ti64.telemetry-investments.com> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> <20050203110049.6b2d9c64.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203110049.6b2d9c64.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brugolsky@telemetry-investments.com Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 11:00:49AM -0800, David S. Miller wrote: > It might not help for Olaf's 128 cpu box though :-) > > I think reconsider the idea of replicating the rule itself per-cpu. > Also, this thread should have begun with netfilter-devel at least on > the CC:, added. As Olaf Kirch pointed out, an entry is about 150 bytes, while the counters are two 64-bit ints, and it looks like 'unsigned int comefrom' is set as the chains are traversed [net/ipv4/netfilter/ip_tables.c]: /* Save old back ptr in next entry */ struct ipt_entry *next = (void *)e + e->next_offset; next->comefrom = (void *)back - table_base; /* set back pointer to next entry */ back = next; That's 20-24 bytes of state per-entry per-cpu, for a factor of 6-7 savings, at the expense of hairing up the code slightly to do parallel indexed access, Fortran style. If I am understanding the mm code correctly, a single vmalloc() allocation is currently limited to 64M on a 64-bit platform, but the VMALLOC address range is much greater, so one might also prefer to do a kmalloc()/vmalloc() per CPU, perhaps by creating {vmalloc,vfree}_percpu() and using the percpu interfaces. Bill Rugolsky From jgarzik@pobox.com Thu Feb 3 14:13:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:13:57 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13MDqhe023755 for ; Thu, 3 Feb 2005 14:13:53 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwpEV-0004Cx-1h; Thu, 03 Feb 2005 22:13:51 +0000 Message-ID: <4202A206.7060100@pobox.com> Date: Thu, 03 Feb 2005 17:13:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> In-Reply-To: <42028747.6060602@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1243 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 Christian Schmid wrote: > What exactly is tcp segmentation offload? Where can I read more about > it? Should I disable it or is this not a good idea? It's an optimization designed to reduce CPU usage for zero-copy apps (those that use sendfile(2)). It would be a useful datapoint to disable TSO, and see if that improves things for you. Jeff From davem@davemloft.net Thu Feb 3 14:26:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:26:29 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13MQOfC024432 for ; Thu, 3 Feb 2005 14:26:24 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwpJV-0008Cm-00; Thu, 03 Feb 2005 14:19:01 -0800 Date: Thu, 3 Feb 2005 14:19:01 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203141901.5ce04c92.davem@davemloft.net> In-Reply-To: <20050203203010.GA7081@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 07:30:10 +1100 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote: > > > > Architectures should guarantee that any of the atomics and bitops that > > return values order in both directions. So you dont need the > > smp_mb__before_atomic_dec here. > > I wasn't aware of this requirement before. However, if this is so, > why don't we get rid of the smp_mb__* macros? They are for cases where you want strict ordering even for the non-return-value-giving atomic_t ops. Actually.... Herbert has a point. By Anton's specification, several uses in 2.6.x I see of these smp_mb__*() routines are bogus. Case in point, look at mm/filemap.c: void fastcall unlock_page(struct page *page) { smp_mb__before_clear_bit(); if (!TestClearPageLocked(page)) BUG(); smp_mb__after_clear_bit(); wake_up_page(page, PG_locked); } TestClearPageLocked() uses one of the bitops returning a value, so must be providing the explicit memory barriers in it's implementation. void end_page_writeback(struct page *page) { if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) { if (!test_clear_page_writeback(page)) BUG(); } smp_mb__after_clear_bit(); wake_up_page(page, PG_writeback); } Same thing there. Looking at include/linux/sunrpc/sched.h, those uses are legitimate, correct, and needed. As is the put_bh() use in include/linux/buffer_head.h There are several other correct and necessary uses in: include/linux/interrupt.h include/linux/netdevice.h include/linux/nfs_page.h include/linux/spinlock.h net/core/dev.c net/sunrpc/sched.c sound/pci/bt87x.c fs/buffer.c fs/nfs/pagelist.c drivers/block/ll_rw_blk.c arch/ppc64/kernel/smp.c arch/i386/kernel/smp.c arch/i386/mach-voyager/smp.c I'm working on a rough but rather complete draft Anton said needs to be written to explicitly spell out the atomic_t and bitops stuff. From webmaster@rapidforum.com Thu Feb 3 14:29:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:29:38 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13MTX8e024937 for ; Thu, 3 Feb 2005 14:29:34 -0800 Received: (qmail 20779 invoked by uid 1004); 3 Feb 2005 22:29:32 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 22:29:32 -0000 Message-ID: <4202A5B6.5080903@rapidforum.com> Date: Thu, 03 Feb 2005 23:29:10 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> <4202A206.7060100@pobox.com> In-Reply-To: <4202A206.7060100@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev I turned it off and without it, I was unable to reproduce any stalls anymore. Jeff Garzik wrote: > Christian Schmid wrote: > >> What exactly is tcp segmentation offload? Where can I read more about >> it? Should I disable it or is this not a good idea? > > > It's an optimization designed to reduce CPU usage for zero-copy apps > (those that use sendfile(2)). > > It would be a useful datapoint to disable TSO, and see if that improves > things for you. > > Jeff > > > > From sudeep.list@gmail.com Thu Feb 3 14:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:45:19 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13MjF7Z025749 for ; Thu, 3 Feb 2005 14:45:16 -0800 Received: by rproxy.gmail.com with SMTP id a41so516159rng for ; Thu, 03 Feb 2005 14:45:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=V2qeG9laEFqkB+494ibAlyj+/BXPxmcRCWhiyuDJrvXOtrnr9o7sfF1sEmiNFYRvnNzLspLXiql8VYlGZOBiwhSzGoTi4gxGVB02/mfXRyGA11J6zfkIq5/e+kK5N4BdUbe+1MoPU88SUHgIkAaEPB1zbBZxVryZ8r3hqz5MW74= Received: by 10.38.9.54 with SMTP id 54mr156386rni; Thu, 03 Feb 2005 14:45:15 -0800 (PST) Received: by 10.38.72.22 with HTTP; Thu, 3 Feb 2005 14:45:15 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 15:45:15 -0700 From: sudeep list Reply-To: sudeep list To: netdev@oss.sgi.com Subject: pointers in the sk_buff structure. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sudeep.list@gmail.com Precedence: bulk X-list: netdev hello, I figured that the pointer sk_buff->tail points to the end of data in the buffer attached to the sk_buff. What does the pointer sk_buff->end point to ? Is there any data that lies between the two pointers, or they are two pointers to the same address (end of data in the buffer area) ? Sudeep From davem@davemloft.net Thu Feb 3 15:15:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:15:46 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13NFcdZ027041 for ; Thu, 3 Feb 2005 15:15:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cwq5G-0008R7-00; Thu, 03 Feb 2005 15:08:22 -0800 Date: Thu, 3 Feb 2005 15:08:21 -0800 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203150821.2321130b.davem@davemloft.net> In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 01:27:05 +1100 Anton Blanchard wrote: > Its difficult stuff, everyone gets it wrong and Andrew keeps > hassling me to write up a document explaining it. Ok, here goes nothing. Can someone run with this? It should be rather complete, and require only minor editorial work. --- atomic_ops.txt --- This document is intended to serve as a guide to Linux port maintainers on how to implement atomic counter and bitops operations properly. The atomic_t type should be defined as a signed integer. Also, it should be made opaque such that any kind of cast to a normal C integer type will fail. Something like the following should suffice: typedef struct { volatile int counter; } atomic_t; The first operations to implement for atomic_t's are the initializers and plain reads. #define ATOMIC_INIT(i) { (i) } #define atomic_set(v, i) ((v)->counter = (i)) The first macro is used in definitions, such as: static atomic_t my_counter = ATOMIC_INIT(1); The second interface can be used at runtime, as in: k = kmalloc(sizeof(*k), GFP_KERNEL); if (!k) return -ENOMEM; atomic_set(&k->counter, 0); Next, we have: #define atomic_read(v) ((v)->counter) which simply reads the current value of the counter. Now, we move onto the actual atomic operation interfaces. void atomic_add(int i, atomic_t *v); void atomic_sub(int i, atomic_t *v); void atomic_inc(atomic_t *v); void atomic_dec(atomic_t *v); These four routines add and subtract integral values to/from the given atomic_t value. The first two routines pass explicit integers by which to make the adjustment, whereas the latter two use an implicit adjustment value of "1". One very important aspect of these two routines is that they DO NOT require any explicit memory barriers. They need only perform the atomic_t counter update in an SMP safe manner. Next, we have: int atomic_inc_return(atomic_t *v); int atomic_dec_return(atomic_t *v); These routines add 1 and subtract 1, respectively, from the given atomic_t and return the new counter value after the operation is performed. Unlike the above routines, it is required that explicit memory barriers are performed before and after the operation. It must be done such that all memory operations before and after the atomic operation calls are strongly ordered with respect to the atomic operation itself. For example, it should behave as if a smp_mb() call existed both before and after the atomic operation. If the atomic instructions used in an implementation provide explicit memory barrier semantics which satisfy the above requirements, that is fine as well. Let's move on: int atomic_add_return(int i, atomic_t *v); int atomic_sub_return(int i, atomic_t *v); These behave just like atomic_{inc,dec}_return() except that an explicit counter adjustment is given instead of the implicit "1". This means that like atomic_{inc,dec}_return(), the memory barrier semantics are required. Next: int atomic_inc_and_test(atomic_t *v); int atomic_dec_and_test(atomic_t *v); These two routines increment and decrement by 1, respectively, the given atomic counter. They return a boolean indicating whether the resulting counter value was zero or not. It requires explicit memory barrier semantics around the operation as above. int atomic_sub_and_test(int i, atomic_t *v); This is identical to atomic_dec_and_test() except that an explicit decrement is given instead of the implicit "1". It requires explicit memory barrier semantics around the operation. int atomic_add_negative(int i, atomic_t *v); The given increment is added to the given atomic counter value. A boolean is return which indicates whether the resulting counter value is negative. It requires explicit memory barrier semantics around the operation. If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: void smb_mb__before_atomic_dec(void); void smb_mb__after_atomic_dec(void); void smb_mb__before_atomic_inc(void); void smb_mb__after_atomic_dec(void); For example, smb_mb__before_atomic_dec() can be used like so: obj->dead = 1; smb_mb__before_atomic_dec(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceeding the atomic_dec() call are strongly ordered with respect to the atomic counter operation. In the above example, it guarentees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. Without the explicitl smb_mb__before_atomic_dec() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. The other three interfaces listed are used to provide explicit ordering with respect to memory operations after an atomic_dec() call (smb_mb__after_atomic_dec()) and around atomic_inc() calls (smb_mb__{before,after}_atomic_inc()). A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disasterous results. Here is an example, which follows a pattern occuring frequently in the Linux kernel. It is the use of atomic counters to implement reference counting, and it works such that once the counter falls to zero it can be guarenteed that no other entity can be accessing the object. Observe: list_del(&obj->list); if (atomic_dec_and_test(&obj->ref_count)) kfree(obj); Here, the list (say it is some linked list on which object searches are performed) creates the reference to the object. The insertion code probably looks something like this: atomic_inc(&obj->ref_count); list_add(&obj->list, &global_obj_list); And searches look something like: for_each(obj, &global_obj_list) { if (key_compare(obj->key, key)) { atomic_inc(&obj->ref_count); return obj; } } return NULL; Given the above scheme, it must be the case that the list_del() be visible to other processors before the atomic counter decrement is performed. Otherwise, the counter could fall to zero, yet the object is still visible for lookup on the linked list. So we'd get a bogus sequence like this: cpu 0 cpu 1 list_del(&obj->list); ... visibility delayed ... lookup and find obj on global_obj_list atomic_dec_and_test(); obj refcount hits zero, this is visible globally atomic_inc() obj refcount incremented to one list_del() becomes visible kfree(obj); obj is now freed up memory --> CRASH With the memory barrier semantics required of the atomic_t operations which return values, the above sequence of memory visibility can never happen. We will now cover the atomic bitmask operations. You will find that their SMP and memory barrier semantics are similar in shape to the atomic_t ops above. Native atomic bit operations are defined to operate on objects aligned to the size of an "unsigned long" C data type, and are least of that size. The endianness of the bits within each "unsigned long" are the native endianness of the cpu. void set_bit(unsigned long nr, volatils unsigned long *addr); void clear_bit(unsigned long nr, volatils unsigned long *addr); void change_bit(unsigned long nr, volatils unsigned long *addr); These routines set, clear, and change, respectively, the bit number indicated by "nr" on the bit mask pointed to by "ADDR". They must execute atomically, yet there are no implicit memory barrier semantics required of these interfaces. long test_and_set_bit(unsigned long nr, volatils unsigned long *addr); long test_and_clear_bit(unsigned long nr, volatils unsigned long *addr); long test_and_change_bit(unsigned long nr, volatils unsigned long *addr); Like the above, except that these routines return a boolean which indicates whether the changed bit was set _BEFORE_ the atomic bit operation. These routines, like the atomic_t counter operations returning values, require explicit memory barrier semantics around their execution. All memory operations before the atomic bit operation call must be made visible globally before the atomic bit operation is made visible. Likewise, the atomic bit operation must be visible globally before any subsequent memory operation is made visible. For example: obj->dead = 1; if (test_and_set_bit(0, &obj->flags)) /* ... */; obj->killed = 1; The implementation of test_and_set_bit() must guarentee that "obj->dead = 1;" is visible to cpus before the atomic memory operation done by test_and_set_bit() becomes visible. Likewise, the atomic memory operation done by test_and_set_bit() must become visible before "obj->killed = 1;" is visible. Finally there is the basic operation: long test_bit(unsigned long nr, __const__ volatile unsigned long *addr); Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". If explicit memory barriers are required around clear_bit() (which does not return a value, and thus does not need to provide memory barrier semantics), two interfaces are provided: void smp_mb__before_clear_bit(void); void smp_mb__after_clear_bit(void); They are used as follows, and are akin to their atomic_t operation brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ smp_mb__before_clear_bit(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ smp_mb__after_clear_bit(); Finally, there are non-atomic versions of the bitmask operations provided. They are used in contexts where some other higher-level SMP locking scheme is being used to protect the bitmask, and thus less expensive non-atomic operations may be used in the implementation. They have names similar to the above bitmask operation interfaces, except that two underscores are prefixed to the interface name. void __set_bit(unsigned long nr, volatile unsigned long *addr); void __clear_bit(unsigned long nr, volatile unsigned long *addr); void __change_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_set_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_change_bit(unsigned long nr, volatile unsigned long *addr); These non-atomic variants also do not require any special memory barrier semantics. From davem@davemloft.net Thu Feb 3 15:51:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:51:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Np274028018 for ; Thu, 3 Feb 2005 15:51:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cwqdb-00008J-00; Thu, 03 Feb 2005 15:43:51 -0800 Date: Thu, 3 Feb 2005 15:43:51 -0800 From: "David S. Miller" To: Herbert Xu Cc: marcel@holtmann.org, netdev@oss.sgi.com Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" Message-Id: <20050203154351.1c653848.davem@davemloft.net> In-Reply-To: References: <1107461073.6833.8.camel@pegasus> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 04 Feb 2005 07:39:38 +1100 Herbert Xu wrote: > Marcel Holtmann wrote: > > > > when using my RAS account with 2.6.11-rc3, I see a lot of > > > > ESP: sha1 digestsize 20 != 0 > > > > messages in my logs and the IPsec tunnel is not working. I tracked the > > problem down to the change below. After reverting this patch, everything > > works like before. > > Sorry, my fault. > > The name test in xfrm_get_byname is inverted. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From herbert@gondor.apana.org.au Thu Feb 3 15:51:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:52:05 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13NpuAw028318 for ; Thu, 3 Feb 2005 15:51:57 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cwqku-0005zu-00; Fri, 04 Feb 2005 10:51:24 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwqkH-0002CF-00; Fri, 04 Feb 2005 10:50:45 +1100 Date: Fri, 4 Feb 2005 10:50:44 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203235044.GA8422@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20050203141901.5ce04c92.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 03, 2005 at 02:19:01PM -0800, David S. Miller wrote: > > They are for cases where you want strict ordering even for the > non-return-value-giving atomic_t ops. I see. I got atomic_dec and atomic_dec_and_test mixed up. So the problem isn't as big as I thought which is good. sk_buff is only in trouble because of the atomic_read optimisation which really needs a memory barrier. However, instead of adding a memory barrier which makes the optimisation less useful, let's just get rid of the atomic_read. Signed-off-by: Herbert Xu Thanks for the document, it's really helpful. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-04 10:44:17 +11:00 @@ -353,14 +353,14 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) + if (atomic_dec_and_test(&skb->users)) __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ static inline void kfree_skb_fast(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) + if (atomic_dec_and_test(&skb->users)) kfree_skbmem(skb); } --fUYQa+Pmc3FrFX/N-- From andy.furniss@dsl.pipex.com Thu Feb 3 16:33:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:34:01 -0800 (PST) Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140Xsg2004777 for ; Thu, 3 Feb 2005 16:33:55 -0800 Received: from dsl.pipex.com (81-178-134-214.dsl.pipex.com [81.178.134.214]) by ranger.systems.pipex.net (Postfix) with ESMTP id 96522E000149; Fri, 4 Feb 2005 00:33:43 +0000 (GMT) Message-ID: <4202C2F2.2050500@dsl.pipex.com> Date: Fri, 04 Feb 2005 00:33:54 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> <41FF97E9.7040501@dsl.pipex.com> <1107353106.1098.65.camel@jzny.localdomain> In-Reply-To: <1107353106.1098.65.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev jamal wrote: > On Tue, 2005-02-01 at 09:53, Andy Furniss wrote: > >>jamal wrote: >> >>>I know for a while the Bart howto was mislabeling the meaning of >>>policing - not sure about shaping. >>>Shaping has a precise definition that involves a queue and a >>>non-working-conserving scheduler in order to rate control. This doesnt >>>matter where it happens (egress or ingress). Policing on the other hand >>>is work conserving etc. >> >>Ok, but shaping to LARTC posters means being able to classify traffic >>and set up sharing/priorotising of classes. >> >>This is the reason most need >>to be able to queue - they want to use htb/hfsc for complicated setups > > > Close - but you are missing the rate control requirement. > You can do the above with prio qdisc for example but that does not > equate to shaping. Understood about Lartc users definitions. However, > note that they are influenced by what people tell them or what people > write in docs. Help in making sure the redefinition doesnt propagate. > Theres a very precise meaning to shaping and it is _exactly_ the way i > described it above. Clue people who ask questions. I see your point. > > >>and until now were not aware that it was even possible to replicate this >>in policers > > > I am sure i have written about 50 emails on this topic over the last 5 > years;-> look at the archives. I even joked about it here: > http://www.cyberus.ca/~hadi/patches/action/README over 2 years ago. > look at the text reading "it must be the summer heat again; weve had > someone doing that every year around summer" > Unfortunately people who are writting docs havent picked it up for > whatever reasons. I am hoping we finaly get this documented somewhere. > Can you help fix this? I could write up some what I did type stuff. Once I work out what to do and how to do it :-) > > >>and if it becomes feasable it will probably appear daunting >>to do compared with HTB and all the existing docs/scripts. >> > > >>From a usability perspective i agree with you. > Its still doable is all i can say ;-> (but you are correct in that it > may not be for the weak hearts) > As a reminder of some of the big discussions on shared and hierachical > policing - look at the many many discussions I had with devik on this > topic a few years back. > It resulted in the birth of HTB (which is essentially a hierachy of the > same token bucket meters used in policers; hierachical shared policers > are doable - look at iproute2/examples/diffserv). HTB otoh has proven > useful due to simplicty - so it stands on its own merit now. > I think there may be peculiar occasions where you may need to have > queues to shape traffic to a local app - but thats peculiar. > I'll have to read up abit. > >>For me, I think queuing and dropping is better than just dropping, you >>can affect tcp by delaying eg. 1 ack per packet rather than delayed acks >>and clocking out the packets helps smooth burstiness, > > > True - but i question the usefulness of localy terminating TCP packets > being shaped. For packets being forwarded, the shaping happens on > egress. I know it's a bit odd, but then if I had just one PC I would want to rather than police for reasons below. > > >>which hurts >>latency if you are doing traffic control from the wrong end of the >>bottleneck. >> > > > Not sure i followed the latency connection. I am shaping a relativly slow link from the wrong end. My objective is to avoid the 600ms buffer at ISP/Teleco getting filled as it adds latency for my interactive traffic. If I have a dozen bulk tcp connections running then policing encourages each to send data in bursts at link speed, because delayed acks will pair packets and say a group of four passes without dropping it causes another group of four from that connection at link speed. Add to that the different or variable rtts of the 12 connections it means that there will be times when large bunches of big packets arrive together and delay the interactive traffic. If I shape and dequeue each connection round robin and the aggeragate rate is below link speed then the aggregate flow is smoothed better. If the rates are low enough I will delay longer than delayed ack timers and get one packet per ack aswell. It's still not perfect of course. > > >>As long as I could use netfilter to mark/classify connections then I >>think I can sort my setup, don't know about others. >> >> > > > Great. yes, you can. > > >>>Are pre/post routing sufficient as netfilter hooks for your case? >> >>Yes but depends on where in pre/postrouting. For me after/before nat, as >>I say above though I could workaround if I classify connections with >>netfilter. For others as long as they can filter on a mark/classify set >>in forward, then I think it will be OK for them. >> > > > You can mark in netfilter or even in tc and use those marks in both > places. Great. > > > >>I am not sure what exactly can can't be done in your example: >> >> ># 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 \ >> >>What I can do here depends where it hooks packets. >> >> >action ipt -j MARK --set-mark 1 \ >> >>I don't know what table I am using - may be OK as long as I can test for >>a mark I made earlier in the egress dummy case or test connmark/state I >>set for that connection in the ingress case. >> > > > That would be doable. Thanks for taking the time Andy. Glad I can help. Andy. > > cheers, > jamal > > From davem@davemloft.net Thu Feb 3 16:42:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:42:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140gSeQ005405 for ; Thu, 3 Feb 2005 16:42:28 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwrR4-0000KS-00; Thu, 03 Feb 2005 16:34:58 -0800 Date: Thu, 3 Feb 2005 16:34:58 -0800 From: "David S. Miller" To: Herbert Xu , anton@samba.org, anton@au.ibm.com Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203163458.6282c3fe.davem@davemloft.net> In-Reply-To: <20050203111224.GA3267@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050202162023.075015d4.davem@davemloft.net> <20050203111224.GA3267@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 3 Feb 2005 22:12:24 +1100 Herbert Xu wrote: > This paradigm is repeated throughout the kernel. I bet the > same race can be found in a lot of those places. So we really > need to sit down and audit them one by one or else come up with > a magical solution apart from disabling SMP :) Ok. I'm commenting now considering Anton's atomic_t rules. Anton, please read down below, I think there is a hole in the PPC memory barriers used for atomic ops on SMP. I don't see what changes are needed anywhere given those rules. Olaf says the problem shows up on PPC SMP system, and since Anton knows the proper rules we hopefully can safely assume he implemented them correctly on PPC :-) I thought for a moment that the atomic_read() might be an issue, and I'd really hate to kill that optimization. But I can't see how it is. Let us restate Olaf's original guess as to the problematic sequence of events: cpu 0 cpu 1 skb_get(skb) unlock(neigh) lock(neigh) __skb_unlink(skb) kfree_skb(sb) kfree_skb(skb) First, __skb_unlink(skb) does an unlocked queue unlink, and these memory operations may have their visibility freely reordered by the processor. However, cpu 1 will see the refcount at 2, so it will execute: atomic_dec_and_test(&skb->users) which has the implicit memory barriers, as Anton stated. This means that the cpu will make the __skb_unlink(skb) results visible globally before the decrement. Now the kfree_skb() on cpu 0 executes, the atomic_read() sees it at 1, we do the __kfree_skb() and since the __skb_unlink() has been made visible before the decrement on the count to "1" the BUG() should not trigger in __kfree_skb(). This all assumes, again, that PPC implements these things properly. Let's take a look (Anton, start reading here). My understanding of PPC memory barriers, wrt. the physical memory coherency domain, is as follows: sync ! All previous read/write execute before all subsequent read/write lwsync ! All previous reads execute before all subsequent read/write eieio ! All previous writes execute before all subsequent read/write isync ! All previous memory operations and instructions execute and ! reach global visibility before any subsequent instructions execute What guarentees does isync really make about "read" reordering around the atomic increment? Any descrepencies here would account for the case Olaf observed. All the atomic ops returning values on PPC do this on SMP: eieio atomic_op() isync At a minimum, it seems that the eieio is not strong enough a memory barrier. It is defined to order previous writes against future memory operations, but we also need to strictly order previous reads as well don't we? Also, if my understanding of isync is not correct, that could have implications as well. I guess for performance reasons, ppc doesn't use "sync" both before and after the atomic ops requiring ordering. But I suspect that might be what is actually needed for proper conformity to the atomic_t memory ordering rules. Anton? From jt@hpl.hp.com Thu Feb 3 16:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:53:52 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140rl57006511 for ; Thu, 3 Feb 2005 16:53:48 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 41E09100F; Thu, 3 Feb 2005 16:53:47 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA04043; Thu, 3 Feb 2005 16:56:02 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwrjG-00027v-00; Thu, 03 Feb 2005 16:53:46 -0800 Date: Thu, 3 Feb 2005 16:53:46 -0800 To: Marcelo Tosatti , Stephen Hemminger , Linux kernel mailing list , netdev@oss.sgi.com Subject: [PATCH 2.4] SIOCSIFNAME wildcard support Message-ID: <20050204005346.GA7692@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Hi Marcelo, This patch adds wildcard support for the SIOCSIFNAME ioctl, like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to change network interface names (such as nameif, ifrename, or ip link), this patch allow those tools to specify a pattern, such as "eth%d" or "wlan%d", and the kernel use the lowest available slot. The reason I'm sending you this patch is that I've got some 2.4.X users who requested the feature... This patch was initially done for 2.4.23, and I rediffed and retested with 2.4.29. It's somewhat different from the patch Stephen and me added to 2.6.1, because the netdev init code is different and also this patch is more conservative. Have fun... Jean ------------------------------------------------------------- diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c --- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003 +++ linux/net/core/dev.c Wed Dec 3 18:55:27 2003 @@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr, case SIOCSIFNAME: if (dev->flags&IFF_UP) return -EBUSY; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - dev->name[IFNAMSIZ-1] = 0; + /* Check if name contains a wildcard */ + if (strchr(ifr->ifr_newname, '%')) { + char format[IFNAMSIZ + 1]; + int ret; + memcpy(format, ifr->ifr_newname, IFNAMSIZ); + format[IFNAMSIZ-1] = 0; + /* Find a free name based on format. + * dev_alloc_name() replaces "%d" with at max + * 2 digits, so no name overflow. - Jean II */ + ret = dev_alloc_name(dev, format); + if (ret < 0) + return ret; + /* Copy the new name back to caller. */ + strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ); + } else { + if (__dev_get_by_name(ifr->ifr_newname)) + return -EEXIST; + memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); + dev->name[IFNAMSIZ-1] = 0; + } notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); return 0; @@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar * - return a value */ + case SIOCSIFNAME: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) @@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: From davem@davemloft.net Thu Feb 3 16:56:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:56:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140uYhi007141 for ; Thu, 3 Feb 2005 16:56:34 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cwrf0-0000OH-00; Thu, 03 Feb 2005 16:49:22 -0800 Date: Thu, 3 Feb 2005 16:49:22 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203164922.2627a112.davem@davemloft.net> In-Reply-To: <20050203235044.GA8422@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 10:50:44 +1100 Herbert Xu wrote: > So the problem isn't as big as I thought which is good. sk_buff > is only in trouble because of the atomic_read optimisation which > really needs a memory barrier. > > However, instead of adding a memory barrier which makes the optimisation > less useful, let's just get rid of the atomic_read. See my other email, the atomic_read() should function just fine. If we see the count dropped to "1", whoever set it to "1" made sure that all outstanding memory operations (including things like __skb_unlink()) are globally visible before the atomic_dec_and_test() which put the thing to "1" from "2". (and we did use atomic_dec_and_test() since the refcount was not "1") Example, assuming skb->users is "2": cpu 0 cpu 1 __skb_unlink() kfree_skb() kfree_skb() If cpu 0 sees the count at "1", it will always see the __skb_unlink() as well. Either my logic is flawed (very possible, I am a pinhead) or something is amiss in the PPC atomic ops. I describe all of this more explicitly in my other email. I'm actually going through all the sparc64 chip manuals to make sure I have things correct in that implementation :-))) From jt@hpl.hp.com Thu Feb 3 17:08:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:08:13 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14185um009004 for ; Thu, 3 Feb 2005 17:08:05 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 9C99AA848; Thu, 3 Feb 2005 17:07:58 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA04434; Thu, 3 Feb 2005 17:10:14 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Cwrx0-00028Y-00; Thu, 03 Feb 2005 17:07:58 -0800 Date: Thu, 3 Feb 2005 17:07:58 -0800 To: Marcelo Tosatti , Jeff Garzik , Linux kernel mailing list , netdev@oss.sgi.com Subject: [PATCH 2.4] Wireless Extension v17 Message-ID: <20050204010758.GB7692@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin : * - Fix kernel data leak to user space in private handler handling Have fun... Jean -------------------------------------------------------------------- diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h 2005-02-03 14:54:56.000000000 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.000000000 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.000000000 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.000000000 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * -------------------------------- * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -------------- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * ---------- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ /**************************** CONSTANTS ****************************/ @@ -251,7 +258,7 @@ /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define IW_MODE_SECOND 5 /* Secondary master/repeater (backup) */ #define IW_MODE_MONITOR 6 /* Passive monitor (listen only) */ +/* Statistics flags (bitmask in updated) */ +#define IW_QUAL_QUAL_UPDATED 0x1 /* Value was updated since last read */ +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define IW_QUAL_NOISE_UPDATED 0x4 +#define IW_QUAL_QUAL_INVALID 0x10 /* Driver doesn't provide value */ +#define IW_QUAL_LEVEL_INVALID 0x20 +#define IW_QUAL_NOISE_INVALID 0x40 + +/* Frequency flags */ +#define IW_FREQ_AUTO 0x00 /* Let the driver decides */ +#define IW_FREQ_FIXED 0x01 /* Force a specific value */ + /* Maximum number of size of encoding token available * they are listed in the range structure */ #define IW_MAX_ENCODING_SIZES 8 @@ -390,6 +409,7 @@ #define IW_TXPOW_TYPE 0x00FF /* Type of value */ #define IW_TXPOW_DBM 0x0000 /* Value is in dBm */ #define IW_TXPOW_MWATT 0x0001 /* Value is in mW */ +#define IW_TXPOW_RELATIVE 0x0002 /* Value is in arbitrary units */ #define IW_TXPOW_RANGE 0x1000 /* Range of value between min/max */ /* Retry limits and lifetime flags available */ @@ -418,6 +438,25 @@ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Event capability macros - in (struct iw_range *)->event_capa + * Because we have more than 32 possible events, we use an array of + * 32 bit bitmasks. Note : 32 bits = 0x20 = 2^5. */ +#define IW_EVENT_CAPA_BASE(cmd) ((cmd >= SIOCIWFIRSTPRIV) ? \ + (cmd - SIOCIWFIRSTPRIV + 0x60) : \ + (cmd - SIOCSIWCOMMIT)) +#define IW_EVENT_CAPA_INDEX(cmd) (IW_EVENT_CAPA_BASE(cmd) >> 5) +#define IW_EVENT_CAPA_MASK(cmd) (1 << (IW_EVENT_CAPA_BASE(cmd) & 0x1F)) +/* Event capability constants - event autogenerated by the kernel + * This list is valid for most 802.11 devices, customise as needed... */ +#define IW_EVENT_CAPA_K_0 (IW_EVENT_CAPA_MASK(0x8B04) | \ + IW_EVENT_CAPA_MASK(0x8B06) | \ + IW_EVENT_CAPA_MASK(0x8B1A)) +#define IW_EVENT_CAPA_K_1 (IW_EVENT_CAPA_MASK(0x8B2A)) +/* "Easy" macro to set events in iw_range (less efficient) */ +#define IW_EVENT_CAPA_SET(event_capa, cmd) (event_capa[IW_EVENT_CAPA_INDEX(cmd)] |= IW_EVENT_CAPA_MASK(cmd)) +#define IW_EVENT_CAPA_SET_KERNEL(event_capa) {event_capa[0] |= IW_EVENT_CAPA_K_0; event_capa[1] |= IW_EVENT_CAPA_K_1; } + + /****************************** TYPES ******************************/ /* --------------------------- SUBTYPES --------------------------- */ @@ -456,7 +495,7 @@ struct iw_freq __s32 m; /* Mantissa */ __s16 e; /* Exponent */ __u8 i; /* List index (when in range struct) */ - __u8 pad; /* Unused - just for alignement */ + __u8 flags; /* Flags (fixed/auto) */ }; /* @@ -610,11 +649,12 @@ struct iw_range /* Old Frequency (backward compat - moved lower ) */ __u16 old_num_channels; __u8 old_num_frequency; - /* Filler to keep "version" at the same offset */ - __s32 old_freq[6]; + + /* Wireless event capability bitmasks */ + __u32 event_capa[6]; /* signal level threshold range */ - __s32 sensitivity; + __s32 sensitivity; /* Quality of link & SNR stuff */ /* Quality range (link, level, noise) diff -u -p linux/include/net/iw_handler.we16.h linux/include/net/iw_handler.h --- linux/include/net/iw_handler.we16.h 2005-02-03 14:55:26.000000000 -0800 +++ linux/include/net/iw_handler.h 2005-02-03 15:47:04.000000000 -0800 @@ -1,10 +1,10 @@ /* * This file define the new driver API for Wireless Extensions * - * Version : 5 4.12.02 + * Version : 6 21.6.04 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 2001-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 2001-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _IW_HANDLER_H @@ -206,7 +206,7 @@ * will be needed... * I just plan to increment with each new version. */ -#define IW_HANDLER_VERSION 5 +#define IW_HANDLER_VERSION 6 /* * Changes : @@ -224,11 +224,18 @@ * V4 to V5 * -------- * - Add new spy support : struct iw_spy_data & prototypes + * + * V5 to V6 + * -------- + * - Change the way we get to spy_data method for added safety + * - Remove spy #ifdef, they are always on -> cleaner code + * - Add IW_DESCR_FLAG_NOMAX flag for very large requests + * - Start migrating get_wireless_stats to struct iw_handler_def */ /**************************** CONSTANTS ****************************/ -/* Enable enhanced spy support. Disable to reduce footprint */ +/* Enhanced spy support available */ #define IW_WIRELESS_SPY #define IW_WIRELESS_THRSPY @@ -258,6 +265,7 @@ #define IW_DESCR_FLAG_EVENT 0x0002 /* Generate an event on SET */ #define IW_DESCR_FLAG_RESTRICT 0x0004 /* GET : request is ROOT only */ /* SET : Omit payload from generated iwevent */ +#define IW_DESCR_FLAG_NOMAX 0x0008 /* GET : no limit on request size */ /* Driver level flags */ #define IW_DESCR_FLAG_WAIT 0x0100 /* Wait for driver event */ @@ -311,23 +319,25 @@ struct iw_handler_def /* Array of handlers for standard ioctls * We will call dev->wireless_handlers->standard[ioctl - SIOCSIWNAME] */ - iw_handler * standard; + const iw_handler * standard; /* Array of handlers for private ioctls * Will call dev->wireless_handlers->private[ioctl - SIOCIWFIRSTPRIV] */ - iw_handler * private; + const iw_handler * private; /* Arguments of private handler. This one is just a list, so you * can put it in any order you want and should not leave holes... * We will automatically export that to user space... */ - struct iw_priv_args * private_args; + const struct iw_priv_args * private_args; - /* Driver enhanced spy support */ - long spy_offset; /* Spy data offset */ + /* This field will be *removed* in the next version of WE */ + long spy_offset; /* DO NOT USE */ - /* In the long term, get_wireless_stats will move from - * 'struct net_device' to here, to minimise bloat. */ + /* New location of get_wireless_stats, to de-bloat struct net_device. + * The old pointer in struct net_device will be gradually phased + * out, and drivers are encouraged to use this one... */ + struct iw_statistics* (*get_wireless_stats)(struct net_device *dev); }; /* ---------------------- IOCTL DESCRIPTION ---------------------- */ @@ -374,18 +384,29 @@ struct iw_ioctl_description */ struct iw_spy_data { -#ifdef IW_WIRELESS_SPY /* --- Standard spy support --- */ int spy_number; u_char spy_address[IW_MAX_SPY][ETH_ALEN]; struct iw_quality spy_stat[IW_MAX_SPY]; -#ifdef IW_WIRELESS_THRSPY /* --- Enhanced spy support (event) */ struct iw_quality spy_thr_low; /* Low threshold */ struct iw_quality spy_thr_high; /* High threshold */ u_char spy_thr_under[IW_MAX_SPY]; -#endif /* IW_WIRELESS_THRSPY */ -#endif /* IW_WIRELESS_SPY */ +}; + +/* --------------------- DEVICE WIRELESS DATA --------------------- */ +/* + * This is all the wireless data specific to a device instance that + * is managed by the core of Wireless Extensions. + * We only keep pointer to those structures, so that a driver is free + * to share them between instances. + * This structure should be initialised before registering the device. + * Access to this data follow the same rules as any other struct net_device + * data (i.e. valid as long as struct net_device exist, same locking rules). + */ +struct iw_public_data { + /* Driver enhanced spy support */ + struct iw_spy_data * spy_data; }; /**************************** PROTOTYPES ****************************/ diff -u -p linux/net/core/dev.we16.c linux/net/core/dev.c --- linux/net/core/dev.we16.c 2005-02-03 14:55:56.000000000 -0800 +++ linux/net/core/dev.c 2005-02-03 15:28:48.000000000 -0800 @@ -2426,7 +2426,7 @@ int dev_ioctl(unsigned int cmd, void *ar /* Follow me in net/core/wireless.c */ ret = wireless_process_ioctl(&ifr, cmd); rtnl_unlock(); - if (!ret && IW_IS_GET(cmd) && + if (IW_IS_GET(cmd) && copy_to_user(arg, &ifr, sizeof(struct ifreq))) return -EFAULT; return ret; diff -u -p linux/net/core/wireless.we16.c linux/net/core/wireless.c --- linux/net/core/wireless.we16.c 2005-02-03 14:56:09.000000000 -0800 +++ linux/net/core/wireless.c 2005-02-03 16:33:22.000000000 -0800 @@ -2,7 +2,7 @@ * This file implement the Wireless Extensions APIs. * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2003 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. * * (As all part of the Linux kernel, this file is GPL) */ @@ -48,6 +48,16 @@ * o Add common spy support : iw_handler_set_spy(), wireless_spy_update() * o Add enhanced spy support : iw_handler_set_thrspy() and event. * o Add WIRELESS_EXT version display in /proc/net/wireless + * + * v6 - 18.06.04 - Jean II + * o Change get_spydata() method for added safety + * o Remove spy #ifdef, they are always on -> cleaner code + * o Allow any size GET request if user specifies length > max + * and if request has IW_DESCR_FLAG_NOMAX flag or is SIOCGIWPRIV + * o Start migrating get_wireless_stats to struct iw_handler_def + * o Add wmb() in iw_handler_set_spy() for non-coherent archs/cpus + * Based on patch from Pavel Roskin : + * o Fix kernel data leak to user space in private handler handling */ /***************************** INCLUDES *****************************/ @@ -64,11 +74,7 @@ /**************************** CONSTANTS ****************************/ -/* Enough lenience, let's make sure things are proper... */ -#define WE_STRICT_WRITE /* Check write buffer size */ -/* I'll probably drop both the define and kernel message in the next version */ - -/* Debuging stuff */ +/* Debugging stuff */ #undef WE_IOCTL_DEBUG /* Debug IOCTL API */ #undef WE_EVENT_DEBUG /* Debug Event dispatcher */ #undef WE_SPY_DEBUG /* Debug enhanced spy support */ @@ -134,11 +140,11 @@ static const struct iw_ioctl_description /* -- hole -- */ { IW_HEADER_TYPE_NULL, 0, 0, 0, 0, 0}, /* SIOCGIWAPLIST */ - { IW_HEADER_TYPE_POINT, 0, (sizeof(struct sockaddr) + sizeof(struct iw_quality)), 0, IW_MAX_AP, 0}, + { IW_HEADER_TYPE_POINT, 0, (sizeof(struct sockaddr) + sizeof(struct iw_quality)), 0, IW_MAX_AP, IW_DESCR_FLAG_NOMAX}, /* SIOCSIWSCAN */ { IW_HEADER_TYPE_PARAM, 0, 0, 0, 0, 0}, /* SIOCGIWSCAN */ - { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_SCAN_MAX_DATA, 0}, + { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_SCAN_MAX_DATA, IW_DESCR_FLAG_NOMAX}, /* SIOCSIWESSID */ { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_ESSID_MAX_SIZE + 1, IW_DESCR_FLAG_EVENT}, /* SIOCGIWESSID */ @@ -203,7 +209,7 @@ static const int standard_event_num = (s sizeof(struct iw_ioctl_description)); /* Size (in bytes) of the various private data types */ -static const char priv_type_size[] = { +static const char iw_priv_type_size[] = { 0, /* IW_PRIV_TYPE_NONE */ 1, /* IW_PRIV_TYPE_BYTE */ 1, /* IW_PRIV_TYPE_CHAR */ @@ -270,12 +276,15 @@ static inline iw_handler get_handler(str */ static inline struct iw_statistics *get_wireless_stats(struct net_device *dev) { + /* New location */ + if((dev->wireless_handlers != NULL) && + (dev->wireless_handlers->get_wireless_stats != NULL)) + return dev->wireless_handlers->get_wireless_stats(dev); + + /* Old location, will be phased out in next WE */ return (dev->get_wireless_stats ? dev->get_wireless_stats(dev) : (struct iw_statistics *) NULL); - /* In the future, get_wireless_stats may move from 'struct net_device' - * to 'struct iw_handler_def', to de-bloat struct net_device. - * Definitely worse a thought... */ } /* ---------------------------------------------------------------- */ @@ -310,14 +319,32 @@ static inline int call_commit_handler(st /* ---------------------------------------------------------------- */ /* - * Number of private arguments + * Calculate size of private arguments */ static inline int get_priv_size(__u16 args) { int num = args & IW_PRIV_SIZE_MASK; int type = (args & IW_PRIV_TYPE_MASK) >> 12; - return num * priv_type_size[type]; + return num * iw_priv_type_size[type]; +} + +/* ---------------------------------------------------------------- */ +/* + * Re-calculate the size of private arguments + */ +static inline int adjust_priv_size(__u16 args, + union iwreq_data * wrqu) +{ + int num = wrqu->data.length; + int max = args & IW_PRIV_SIZE_MASK; + int type = (args & IW_PRIV_TYPE_MASK) >> 12; + + /* Make sure the driver doesn't goof up */ + if (max < num) + num = max; + + return num * iw_priv_type_size[type]; } @@ -350,11 +377,14 @@ static inline int sprintf_wireless_stats dev->name, stats->status, stats->qual.qual, - stats->qual.updated & 1 ? '.' : ' ', + stats->qual.updated & IW_QUAL_QUAL_UPDATED + ? '.' : ' ', ((__u8) stats->qual.level), - stats->qual.updated & 2 ? '.' : ' ', + stats->qual.updated & IW_QUAL_LEVEL_UPDATED + ? '.' : ' ', ((__u8) stats->qual.noise), - stats->qual.updated & 4 ? '.' : ' ', + stats->qual.updated & IW_QUAL_NOISE_UPDATED + ? '.' : ' ', stats->discard.nwid, stats->discard.code, stats->discard.fragment, @@ -470,13 +500,15 @@ static inline int ioctl_export_private(s /* Check NULL pointer */ if(iwr->u.data.pointer == NULL) return -EFAULT; -#ifdef WE_STRICT_WRITE + /* Check if there is enough buffer up there */ if(iwr->u.data.length < dev->wireless_handlers->num_private_args) { - printk(KERN_ERR "%s (WE) : Buffer for request SIOCGIWPRIV too small (%d<%d)\n", dev->name, iwr->u.data.length, dev->wireless_handlers->num_private_args); + /* User space can't know in advance how large the buffer + * needs to be. Give it a hint, so that we can support + * any size buffer we want somewhat efficiently... */ + iwr->u.data.length = dev->wireless_handlers->num_private_args; return -E2BIG; } -#endif /* WE_STRICT_WRITE */ /* Set the number of available ioctls. */ iwr->u.data.length = dev->wireless_handlers->num_private_args; @@ -505,7 +537,6 @@ static inline int ioctl_standard_call(st const struct iw_ioctl_description * descr; struct iw_request_info info; int ret = -EINVAL; - int user_size = 0; /* Get the description of the IOCTL */ if((cmd - SIOCIWFIRST) >= standard_ioctl_num) @@ -536,8 +567,14 @@ static inline int ioctl_standard_call(st #endif /* WE_SET_EVENT */ } else { char * extra; + int extra_size; + int user_length = 0; int err; + /* Calculate space needed by arguments. Always allocate + * for max space. Easier, and won't last long... */ + extra_size = descr->max_tokens * descr->token_size; + /* Check what user space is giving us */ if(IW_IS_SET(cmd)) { /* Check NULL pointer */ @@ -554,18 +591,33 @@ static inline int ioctl_standard_call(st if(iwr->u.data.pointer == NULL) return -EFAULT; /* Save user space buffer size for checking */ - user_size = iwr->u.data.length; + user_length = iwr->u.data.length; + + /* Don't check if user_length > max to allow forward + * compatibility. The test user_length < min is + * implied by the test at the end. */ + + /* Support for very large requests */ + if((descr->flags & IW_DESCR_FLAG_NOMAX) && + (user_length > descr->max_tokens)) { + /* Allow userspace to GET more than max so + * we can support any size GET requests. + * There is still a limit : -ENOMEM. */ + extra_size = user_length * descr->token_size; + /* Note : user_length is originally a __u16, + * and token_size is controlled by us, + * so extra_size won't get negative and + * won't overflow... */ + } } #ifdef WE_IOCTL_DEBUG printk(KERN_DEBUG "%s (WE) : Malloc %d bytes\n", - dev->name, descr->max_tokens * descr->token_size); + dev->name, extra_size); #endif /* WE_IOCTL_DEBUG */ - /* Always allocate for max space. Easier, and won't last - * long... */ - extra = kmalloc(descr->max_tokens * descr->token_size, - GFP_KERNEL); + /* Create the kernel buffer */ + extra = kmalloc(extra_size, GFP_KERNEL); if (extra == NULL) { return -ENOMEM; } @@ -591,14 +643,11 @@ static inline int ioctl_standard_call(st /* If we have something to return to the user */ if (!ret && IW_IS_GET(cmd)) { -#ifdef WE_STRICT_WRITE /* Check if there is enough buffer up there */ - if(user_size < iwr->u.data.length) { - printk(KERN_ERR "%s (WE) : Buffer for request %04X too small (%d<%d)\n", dev->name, cmd, user_size, iwr->u.data.length); + if(user_length < iwr->u.data.length) { kfree(extra); return -E2BIG; } -#endif /* WE_STRICT_WRITE */ err = copy_to_user(iwr->u.data.pointer, extra, iwr->u.data.length * @@ -661,7 +710,7 @@ static inline int ioctl_private_call(str iw_handler handler) { struct iwreq * iwr = (struct iwreq *) ifr; - struct iw_priv_args * descr = NULL; + const struct iw_priv_args * descr = NULL; struct iw_request_info info; int extra_size = 0; int i; @@ -701,7 +750,7 @@ static inline int ioctl_private_call(str ((extra_size + offset) <= IFNAMSIZ)) extra_size = 0; } else { - /* Size of set arguments */ + /* Size of get arguments */ extra_size = get_priv_size(descr->get_args); /* Does it fits in iwr ? */ @@ -771,6 +820,14 @@ static inline int ioctl_private_call(str /* If we have something to return to the user */ if (!ret && IW_IS_GET(cmd)) { + + /* Adjust for the actual length if it's variable, + * avoid leaking kernel bits outside. */ + if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) { + extra_size = adjust_priv_size(descr->get_args, + &(iwr->u)); + } + err = copy_to_user(iwr->u.data.pointer, extra, extra_size); if (err) @@ -1042,9 +1099,25 @@ void wireless_send_event(struct net_devi * One of the main advantage of centralising spy support here is that * it becomes much easier to improve and extend it without having to touch * the drivers. One example is the addition of the Spy-Threshold events. - * Note : IW_WIRELESS_SPY is defined in iw_handler.h */ +/* ---------------------------------------------------------------- */ +/* + * Return the pointer to the spy data in the driver. + * Because this is called on the Rx path via wireless_spy_update(), + * we want it to be efficient... + */ +static inline struct iw_spy_data * get_spydata(struct net_device *dev) +{ + /* This is the new way */ + if(dev->wireless_data) + return(dev->wireless_data->spy_data); + + /* This is the old way. Doesn't work for multi-headed drivers. + * It will be removed in the next version of WE. */ + return (dev->priv + dev->wireless_handlers->spy_offset); +} + /*------------------------------------------------------------------*/ /* * Standard Wireless Handler : set Spy List @@ -1054,16 +1127,26 @@ int iw_handler_set_spy(struct net_device union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct sockaddr * address = (struct sockaddr *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Disable spy collection while we copy the addresses. - * As we don't disable interrupts, we need to do this to avoid races. - * As we are the only writer, this is good enough. */ + * While we copy addresses, any call to wireless_spy_update() + * will NOP. This is OK, as anyway the addresses are changing. */ spydata->spy_number = 0; + /* We want to operate without locking, because wireless_spy_update() + * most likely will happen in the interrupt handler, and therefore + * have its own locking constraints and needs performance. + * The rtnl_lock() make sure we don't race with the other iw_handlers. + * This make sure wireless_spy_update() "see" that the spy list + * is temporarily disabled. */ + wmb(); + /* Are there are addresses to copy? */ if(wrqu->data.length > 0) { int i; @@ -1089,13 +1172,14 @@ int iw_handler_set_spy(struct net_device spydata->spy_address[i][5]); #endif /* WE_SPY_DEBUG */ } + + /* Make sure above is updated before re-enabling */ + wmb(); + /* Enable addresses */ spydata->spy_number = wrqu->data.length; return 0; -#else /* IW_WIRELESS_SPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_SPY */ } /*------------------------------------------------------------------*/ @@ -1107,12 +1191,14 @@ int iw_handler_get_spy(struct net_device union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct sockaddr * address = (struct sockaddr *) extra; int i; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + wrqu->data.length = spydata->spy_number; /* Copy addresses. */ @@ -1129,9 +1215,6 @@ int iw_handler_get_spy(struct net_device for(i = 0; i < spydata->spy_number; i++) spydata->spy_stat[i].updated = 0; return 0; -#else /* IW_WIRELESS_SPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_SPY */ } /*------------------------------------------------------------------*/ @@ -1143,11 +1226,13 @@ int iw_handler_set_thrspy(struct net_dev union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_THRSPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct iw_thrspy * threshold = (struct iw_thrspy *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Just do it */ memcpy(&(spydata->spy_thr_low), &(threshold->low), 2 * sizeof(struct iw_quality)); @@ -1160,9 +1245,6 @@ int iw_handler_set_thrspy(struct net_dev #endif /* WE_SPY_DEBUG */ return 0; -#else /* IW_WIRELESS_THRSPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_THRSPY */ } /*------------------------------------------------------------------*/ @@ -1174,22 +1256,20 @@ int iw_handler_get_thrspy(struct net_dev union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_THRSPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct iw_thrspy * threshold = (struct iw_thrspy *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Just do it */ memcpy(&(threshold->low), &(spydata->spy_thr_low), 2 * sizeof(struct iw_quality)); return 0; -#else /* IW_WIRELESS_THRSPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_THRSPY */ } -#ifdef IW_WIRELESS_THRSPY /*------------------------------------------------------------------*/ /* * Prepare and send a Spy Threshold event @@ -1227,7 +1307,6 @@ static void iw_send_thrspy_event(struct /* Send event to user space */ wireless_send_event(dev, SIOCGIWTHRSPY, &wrqu, (char *) &threshold); } -#endif /* IW_WIRELESS_THRSPY */ /* ---------------------------------------------------------------- */ /* @@ -1240,12 +1319,14 @@ void wireless_spy_update(struct net_devi unsigned char * address, struct iw_quality * wstats) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); int i; int match = -1; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return; + #ifdef WE_SPY_DEBUG printk(KERN_DEBUG "wireless_spy_update() : offset %ld, spydata %p, address %02X:%02X:%02X:%02X:%02X:%02X\n", dev->wireless_handlers->spy_offset, spydata, address[0], address[1], address[2], address[3], address[4], address[5]); #endif /* WE_SPY_DEBUG */ @@ -1257,7 +1338,7 @@ void wireless_spy_update(struct net_devi sizeof(struct iw_quality)); match = i; } -#ifdef IW_WIRELESS_THRSPY + /* Generate an event if we cross the spy threshold. * To avoid event storms, we have a simple hysteresis : we generate * event only when we go under the low threshold or above the @@ -1277,6 +1358,4 @@ void wireless_spy_update(struct net_devi } } } -#endif /* IW_WIRELESS_THRSPY */ -#endif /* IW_WIRELESS_SPY */ } From akpm@osdl.org Thu Feb 3 17:12:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:13:04 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141Cw7a009645 for ; Thu, 3 Feb 2005 17:12:58 -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 j141Cql18180; Thu, 3 Feb 2005 17:12:52 -0800 Date: Thu, 3 Feb 2005 17:17:58 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: kernel26@dush.student.utwente.nl Subject: Fw: [Bugme-new] [Bug 4158] New: bridge always takes the mac i don't want Message-Id: <20050203171758.4805879c.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Thu, 3 Feb 2005 16:59:05 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4158] New: bridge always takes the mac i don't want http://bugme.osdl.org/show_bug.cgi?id=4158 Summary: bridge always takes the mac i don't want Kernel Version: 2.4+ Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: kernel26@dush.student.utwente.nl Problem Description: in some situations your bridge needs to take the mac address of one certain interface. in my case the isp checks my mac address. currently it is not possible to choose which mac the bridge takes. i changed the code somewhat to make it possible to choose the mac of the bridge by changing the order in which you add interfaces to the bridge. please consider changing this in the kernel. code: net/bridge/br_stp_if.c:156 if (addr == br_mac_zero || memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0) addr = p->dev->dev_addr; please change it to: if (addr == br_mac_zero) addr = p->dev->dev_addr; ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From herbert@gondor.apana.org.au Thu Feb 3 17:22:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:22:13 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141M4kH010278 for ; Thu, 3 Feb 2005 17:22:04 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CwsAD-0006Ub-00; Fri, 04 Feb 2005 12:21:37 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cws9W-0002LA-00; Fri, 04 Feb 2005 12:20:54 +1100 Date: Fri, 4 Feb 2005 12:20:53 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204012053.GA8949@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203164922.2627a112.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 04:49:22PM -0800, David S. Miller wrote: > > If we see the count dropped to "1", whoever set it to "1" made > sure that all outstanding memory operations (including things > like __skb_unlink()) are globally visible before the > atomic_dec_and_test() which put the thing to "1" from "2". > (and we did use atomic_dec_and_test() since the refcount was > not "1") Example, assuming skb->users is "2": > > cpu 0 cpu 1 > __skb_unlink() > kfree_skb() > kfree_skb() > > If cpu 0 sees the count at "1", it will always see the > __skb_unlink() as well. This is true if CPU 0 reads the count before reading skb->list. Without a memory barrier, atomic_read and reading skb->list can be reordered. Put it another way, reading skb->list could return a cached value that was read from the main memory prior to the atomic_read. So in order for CPU 0 to always see an up-to-date value of skb->list, it needs to do an smp_rmb() between the atomic_read and reading skb->list. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu Feb 3 17:31:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:31:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141V8r8010972 for ; Thu, 3 Feb 2005 17:31:09 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CwsCT-0000dy-00; Thu, 03 Feb 2005 17:23:57 -0800 Date: Thu, 3 Feb 2005 17:23:57 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203172357.670c3402.davem@davemloft.net> In-Reply-To: <20050204012053.GA8949@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 12:20:53 +1100 Herbert Xu wrote: > This is true if CPU 0 reads the count before reading skb->list. > Without a memory barrier, atomic_read and reading skb->list can > be reordered. Put it another way, reading skb->list could return > a cached value that was read from the main memory prior to the > atomic_read. > > So in order for CPU 0 to always see an up-to-date value of skb->list, > it needs to do an smp_rmb() between the atomic_read and reading > skb->list. You're absolutely right. Ok, so we do need to change kfree_skb(). I believe even with the memory barrier, the atomic_read() optimization is still worth it. atomic ops on sparc64 take a minimum of 40 some odd cycles on UltraSPARC-III and later, whereas the memory barrier will take up a single cycle most of the time. So it'll look something like: if (atomic_read(&skb->users) == 1) smb_rmb(); else if (!atomic_dec_and_test(&skb->users)) return; __kfree_skb(skb); From herbert@gondor.apana.org.au Thu Feb 3 17:56:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:56:38 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141uSMu012534 for ; Thu, 3 Feb 2005 17:56:29 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cwsha-0006n0-00; Fri, 04 Feb 2005 12:56:06 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cwsh9-0002XE-00; Fri, 04 Feb 2005 12:55:39 +1100 Date: Fri, 4 Feb 2005 12:55:39 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204015539.GA9727@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20050203172357.670c3402.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 03, 2005 at 05:23:57PM -0800, David S. Miller wrote: > > You're absolutely right. Ok, so we do need to change kfree_skb(). > I believe even with the memory barrier, the atomic_read() optimization > is still worth it. atomic ops on sparc64 take a minimum of 40 some odd > cycles on UltraSPARC-III and later, whereas the memory barrier will > take up a single cycle most of the time. OK, here is the patch to do that. Let's get rid of kfree_skb_fast while we're at it since it's no longer used. Signed-off-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-04 12:46:15 +11:00 @@ -353,15 +353,11 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); -} - -/* Use this if you didn't touch the skb state [for fast switching] */ -static inline void kfree_skb_fast(struct sk_buff *skb) -{ - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - kfree_skbmem(skb); + if (likely(atomic_read(&skb->users) == 1)) + smp_rmb(); + else if (likely(!atomic_dec_and_test(&skb->users))) + return; + __kfree_skb(skb); } /** --YiEDa0DAkWCtVeE4-- From jgarzik@pobox.com Thu Feb 3 19:06:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 19:06:22 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1436D7j014774 for ; Thu, 3 Feb 2005 19:06:16 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwtnP-0000iu-Ix; Fri, 04 Feb 2005 03:06:11 +0000 Message-ID: <4202E693.90808@pobox.com> Date: Thu, 03 Feb 2005 22:05:55 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel Mailing List CC: schwidefsky@de.ibm.com, akpm@osdl.org, Netdev Subject: Re: [PATCH] s390: qeth network driver References: <200502040211.j142BI35023854@hera.kernel.org> In-Reply-To: <200502040211.j142BI35023854@hera.kernel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1259 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 Linux Kernel Mailing List wrote: > ChangeSet 1.2072, 2005/02/03 17:04:37-08:00, schwidefsky@de.ibm.com > > [PATCH] s390: qeth network driver > > From: Steffen Thoss > From: Frank Pavlic > > qeth network driver changes: > - Improve performance by omitting svs. > - Use function callback mechanism to set layer 2 parameters when getting > a reply for a Layer 2 command. > - dev->hard_header must not be NULL when fake_ll is no set since > IPv6 and Layer2 needs the default function set by network stack. > - ping6 works now when running in layer 2 mode. > - Save original dev->hard_header to restore it when the user doesn't > want to use fake_ll anymore. > - Fake ethernet header in outgoing packets. This currently works > only if qeth is compiled without ipv6 support. > - Add more debug information in case of failures in qeth_set_offline. > - Using fake_ll with HiperSockets devices results in misaligned > ip packets and thus no traffic over HiperSockets. > - Start qeth_remove_device only after the qeth recovery completed. > > Signed-off-by: Martin Schwidefsky > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds It would be nice if this stuff was CC'd to the network, and network driver maintainers. Two immediate concerns I have are, * saving and restoring dev->hard_header is more than a little bit of a hack * overall, I'm not so sure IPv6 support should be conditionalized on anything but CONFIG_IPV6. Though S/390 and qeth are certainly unusual cases, none of the other net drivers in the kernel require a special config option to enable IPv6 support. Jeff From kaber@trash.net Thu Feb 3 19:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 19:11:02 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j143Av4C015482 for ; Thu, 3 Feb 2005 19:10:58 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cwtry-0000sC-AH; Fri, 04 Feb 2005 04:10:54 +0100 Message-ID: <4202E7BE.6050606@trash.net> Date: Fri, 04 Feb 2005 04:10:54 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [PATCH 2.6.11 PKT_SCHED]: ipt action: add back pskb_expand_head call Content-Type: multipart/mixed; boundary="------------090003050808000303010605" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090003050808000303010605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, Jamal asked me to add back the call to pskb_expand_head before 2.6.11. This fixes a regression caused by my tc action cleanup patches, the tc actions most not replace packets, so it must prevent netfilter from doing so. Regards Patrick --------------090003050808000303010605 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/sched/ipt.c 1.13 vs edited ===== --- 1.13/net/sched/ipt.c 2005-01-14 05:41:07 +01:00 +++ edited/net/sched/ipt.c 2005-02-04 04:06:45 +01:00 @@ -207,6 +207,11 @@ struct tcf_ipt *p = PRIV(a, ipt); struct sk_buff *skb = *pskb; + if (skb_cloned(skb)) { + if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + return TC_ACT_UNSPEC; + } + spin_lock(&p->lock); p->tm.lastuse = jiffies; --------------090003050808000303010605-- From kaber@trash.net Thu Feb 3 20:09:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 20:09:49 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1449gLx017407 for ; Thu, 3 Feb 2005 20:09:43 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cwump-00026q-Al; Fri, 04 Feb 2005 05:09:39 +0100 Message-ID: <4202F583.1040601@trash.net> Date: Fri, 04 Feb 2005 05:09:39 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: Re: [PATCH 2.6.11 PKT_SCHED]: ipt action: add back pskb_expand_head call References: <4202E7BE.6050606@trash.net> In-Reply-To: <4202E7BE.6050606@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Patrick McHardy wrote: > Hi Dave, > > Jamal asked me to add back the call to pskb_expand_head before 2.6.11. > This fixes a regression caused by my tc action cleanup patches, the > tc actions most not replace packets, so it must prevent netfilter from > doing so. I forgot the Signed-off-by line, sorry: Signed-off-by: Patrick McHardy >------------------------------------------------------------------------ > >===== net/sched/ipt.c 1.13 vs edited ===== >--- 1.13/net/sched/ipt.c 2005-01-14 05:41:07 +01:00 >+++ edited/net/sched/ipt.c 2005-02-04 04:06:45 +01:00 >@@ -207,6 +207,11 @@ > struct tcf_ipt *p = PRIV(a, ipt); > struct sk_buff *skb = *pskb; > >+ if (skb_cloned(skb)) { >+ if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) >+ return TC_ACT_UNSPEC; >+ } >+ > spin_lock(&p->lock); > > p->tm.lastuse = jiffies; > > From herbert@gondor.apana.org.au Thu Feb 3 23:33:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 23:34:04 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j147XseO025379 for ; Thu, 3 Feb 2005 23:33:55 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CwxyF-0008Np-00; Fri, 04 Feb 2005 18:33:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cwxxn-00033I-00; Fri, 04 Feb 2005 18:33:11 +1100 Date: Fri, 4 Feb 2005 18:33:11 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NET] Add barriers for dst refcnt Message-ID: <20050204073311.GA11716@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: In light of the recent discussion about sk_buff, I think we need the following patch for dst_entry. This adds a memory barrier before dst_release drops the refcnt, and a read memory barrier before dst_destroy starts destroying the entry. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/dst.h 1.24 vs edited ===== --- 1.24/include/net/dst.h 2004-10-26 09:10:25 +10:00 +++ edited/include/net/dst.h 2005-02-04 18:24:46 +11:00 @@ -147,6 +147,7 @@ { if (dst) { WARN_ON(atomic_read(&dst->__refcnt) < 1); + smp_mb__before_atomic_dec(); atomic_dec(&dst->__refcnt); } } ===== net/core/dst.c 1.25 vs edited ===== --- 1.25/net/core/dst.c 2005-01-14 15:41:04 +11:00 +++ edited/net/core/dst.c 2005-02-04 18:26:06 +11:00 @@ -169,6 +169,8 @@ struct neighbour *neigh; struct hh_cache *hh; + smp_rmb(); + again: neigh = dst->neighbour; hh = dst->hh; --OgqxwSJOaUobr8KG-- From linux-netdev@gmane.org Fri Feb 4 01:21:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 01:21:32 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j149LPUE031550 for ; Fri, 4 Feb 2005 01:21:26 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Cwzdj-0002M6-Ra for netdev@oss.sgi.com; Fri, 04 Feb 2005 10:20:35 +0100 Received: from host81-155-183-72.range81-155.btcentralplus.com ([81.155.183.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Feb 2005 10:20:35 +0100 Received: from r.w.hobbs by host81-155-183-72.range81-155.btcentralplus.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Feb 2005 10:20:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Richard Hobbs Subject: [PATCH 4 2.4.27] pcnet32: Add HomePNA parameter for 79C978. Date: Fri, 4 Feb 2005 00:42:07 +0000 (UTC) Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.155.183.72 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: linux-netdev@m.gmane.org X-MailScanner-To: netdev@oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: r.w.hobbs@durham.ac.uk Precedence: bulk X-list: netdev I am trying to set up a hybrid network, part wired, part wireless and part homePNA (the building has some very thick walls and remote computers that can be reached by existing telephone wires). I am using Fedora core 3 with the 2.6.10 kernel. I have checked the pcnet32.c code and the patch 4 2.4.27 appears to be there. I load the pcnet32 module using: modprobe -v pcnet32 homepna=1 I get reply: insmod /lib/modules/2.6.10-1.741_FC3/kernel/drivers/net/pcnet32.ko homepna=1 Looks good. I then try to configure the network through the systems settings interface: eth0 is a e100 ethernet to my router/modem that is OK. Disconnecting eth0 to avoid any conflicts. eth1 should be the AMD79c978 card. Connecting with the telephone wire I set eth1 as an ethernet (I don't see an option for phoneline network) I have tried DHCP get the response on activating the network: Determining IP information for eth1 failed; no link present. Check cable. I have tried a static IP address, card activates but no device is detected at the modem/router. If I unload the module and reload without the homepna option, the card works fine with a standard ethernet cable. Any suggestions please. Thanks Richard Hobbs From okir@suse.de Fri Feb 4 03:17:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 03:17:09 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14BH0RK003887 for ; Fri, 4 Feb 2005 03:17:01 -0800 Received: from hermes.suse.de (hermes-ext.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 A492B13E5A9F; Fri, 4 Feb 2005 12:16:54 +0100 (CET) Date: Fri, 4 Feb 2005 12:16:49 +0100 From: Olaf Kirch To: Herbert Xu Cc: "David S. Miller" , anton@samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204111649.GB32678@suse.de> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> <20050204015539.GA9727@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204015539.GA9727@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1264 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 On Fri, Feb 04, 2005 at 12:55:39PM +1100, Herbert Xu wrote: > OK, here is the patch to do that. Let's get rid of kfree_skb_fast > while we're at it since it's no longer used. Thanks, I'll give that to the PPC folks and ask the to run with it. Regards, Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From herbert@gondor.apana.org.au Fri Feb 4 03:34:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 03:34:29 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14BYJDc004651 for ; Fri, 4 Feb 2005 03:34:20 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cx1ia-0001Nm-00; Fri, 04 Feb 2005 22:33:44 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cx1hx-0003Lu-00; Fri, 04 Feb 2005 22:33:05 +1100 Date: Fri, 4 Feb 2005 22:33:05 +1100 To: "David S. Miller" Cc: Anton Blanchard , okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204113305.GA12764@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203150821.2321130b.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 03:08:21PM -0800, David S. Miller wrote: > > Ok, here goes nothing. Can someone run with this? It should > be rather complete, and require only minor editorial work. Thanks. It's a very nice piece of work. > A missing memory barrier in the cases where they are required > by the atomic_t implementation above can have disasterous > results. Here is an example, which follows a pattern occuring > frequently in the Linux kernel. It is the use of atomic counters > to implement reference counting, and it works such that once > the counter falls to zero it can be guarenteed that no other > entity can be accessing the object. Observe: > > list_del(&obj->list); > if (atomic_dec_and_test(&obj->ref_count)) > kfree(obj); > > Here, the list (say it is some linked list on which object > searches are performed) creates the reference to the object. > The insertion code probably looks something like this: > > atomic_inc(&obj->ref_count); > list_add(&obj->list, &global_obj_list); I think you should probably note that some sort of locking or RCU scheme is required to make this safe. As it is the atomic_inc and the list_add can be reordered such that the atomic_inc occurs after the atomic_dec_and_test. Either that or you can modify the example to add an smp_mb__after_atomic_inc(). That'd be a good way to demonstrate its use. > And searches look something like: > > for_each(obj, &global_obj_list) { > if (key_compare(obj->key, key)) { > atomic_inc(&obj->ref_count); > return obj; > } > } > return NULL; Locking or RCU is definitely needed here. > the object is still visible for lookup on the linked list. So > we'd get a bogus sequence like this: > > cpu 0 cpu 1 > list_del(&obj->list); > ... visibility delayed ... > lookup and find obj on > global_obj_list The visibility only needs to be delayed up until this point for the crash to occur. > atomic_dec_and_test(); > obj refcount hits zero, this > is visible globally > atomic_inc() > obj refcount incremented > to one > list_del() becomes visible > > kfree(obj); > obj is now freed up memory > --> CRASH > > With the memory barrier semantics required of the atomic_t > operations which return values, the above sequence of memory > visibility can never happen. So this isn't exactly correct. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From buytenh@wantstofly.org Fri Feb 4 04:06:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 04:06:41 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14C6U18006186 for ; Fri, 4 Feb 2005 04:06:31 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id D20552B0EC; Fri, 4 Feb 2005 13:06:29 +0100 (MET) Date: Fri, 4 Feb 2005 13:06:29 +0100 From: Lennert Buytenhek To: sudeep list Cc: netdev@oss.sgi.com Subject: Re: pointers in the sk_buff structure. Message-ID: <20050204120629.GB12630@xi.wantstofly.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 03:45:15PM -0700, sudeep list wrote: > hello, Hi, > I figured that the pointer sk_buff->tail points to the end of data in > the buffer attached to the sk_buff. What does the pointer sk_buff->end > point to ? > > Is there any data that lies between the two pointers, or they are two > pointers to the same address (end of data in the buffer area) ? This is a snippet from some docs on the subject I wrote a while ago, hope it helps. I should polish it up and submit it for inclusion. 2. The sk_buff structure. The sk_buff structure ('skb') is actually only used for storing the metadata corresponding to a packet. The packet's data is not stored inside the sk_buff structure itself, but in a separate buffer that is pointed to by skb->head. The skb->end member points one byte past the end of this data buffer. An important design requirement for sk_buffs is being able to add data at the end as well as at the front of the packet. As a packet travels downwards through the network stack, each layer will usually want to add its own header in front of the packet, and it would be nice if we could avoid reallocating and/or copying the entire data portion of the packet around to make more space at the front of the buffer every time we want to do this. To achieve this goal, the packet data is not necessarily stored at the front of the data buffer, but some space between the front of the buffer and the front of the packet is left unused. skb->data and skb->tail are two extra pointers that point to the beginning and one byte past the end of the currently used portion of the data buffer, respectively. Both are guaranteed to point somewhere within the data buffer. ('skb->head <= skb->data <= skb->tail <= skb->end') +----------+-------------------------------------+--------------+ | headroom | packet data | tailroom | +----------+-------------------------------------+--------------+ ^ ^ skb->data ^ skb->end ^ | | + skb->head + skb->tail The function skb_headroom(skb) calculates 'skb->data - skb->head', and indicates how many bytes we can add to the front of the packet without having to reallocate the buffer. Similarly, skb_tailroom(skb) calculates 'skb->end - skb->tail' and indicates how many bytes we can add to the end of the packet before having to reallocate. Adding data to and removing data from the front of the buffer is done with skb_push and skb_pull, respectively. These wrappers do some sanity checks to make sure the relevant constraints on the four pointers are maintained. When an sk_buff is allocated by alloc_skb, skb->{head,data,tail} are all initialised to point to the start of the data buffer. Depending on what the skb will be used for, the caller will usually want to reserve some headroom in anticipation of expansion of the data buffer towards the front. This is done by calling skb_reserve(). From ak@suse.de Fri Feb 4 06:09:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 06:09:12 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14E96bL013598 for ; Fri, 4 Feb 2005 06:09:07 -0800 Received: from hermes.suse.de (hermes-ext.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 D290C1408306; Fri, 4 Feb 2005 15:09:00 +0100 (CET) Date: Fri, 4 Feb 2005 15:09:00 +0100 From: Andi Kleen To: netdev@oss.sgi.com Cc: netfilter-devel@lists.netfilter.org Subject: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050204140900.GD2518@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1268 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: 2382 Lines: 73 On kernels compiled with a big NR_CPUS netfilter rules would eat a lot of memory because all counters would be duplicated for all NR_CPUs CPUs. With NR_CPUS=256 this would add up to many MBs of memory. This patch only allocates enough memory for the possible CPUs, which is usually a much smaller number than NR_CPUS. This allows loading of bigger rule sets on 64bit systems. There is still a limit because someone else broke vmalloc to have a 64MB limit on 64bit systems for single allocations, 129MB on 32bit. It allocates an array of pages with kmalloc and kmalloc has a 128K limit. To be fixed with a separate patch. 64bit systems were hurt worst because they tend to have big NR_CPUS and the counters need more memory there, and the vmalloc limit is lower. But it will raise the limits even on 32bit. And in general it saves a lot of memory. Tested only on a small dual CPU box. Signed-off-by: Andi Kleen diff -u linux/net/ipv4/netfilter/ip_tables.c-o linux/net/ipv4/netfilter/ip_tables.c --- linux/net/ipv4/netfilter/ip_tables.c-o 2005-02-04 09:40:12.000000000 +0100 +++ linux/net/ipv4/netfilter/ip_tables.c 2005-02-04 14:26:56.000000000 +0100 @@ -923,7 +923,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -945,7 +945,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -992,7 +992,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1130,7 +1130,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1460,7 +1460,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; From yoshfuji@linux-ipv6.org Fri Feb 4 08:55:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 08:55:50 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14GtfpS024268 for ; Fri, 4 Feb 2005 08:55:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 7B87233CC2; Sat, 5 Feb 2005 01:56:39 +0900 (JST) Date: Sat, 05 Feb 2005 01:56:33 +0900 (JST) Message-Id: <20050205.015633.45798306.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPV6]: Fix tunnel list locking in ip6_tunnel.c. 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1269 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: 727 Lines: 27 Hello. We need to fix tunnel list locking in ip6_tunnel.c as well. Noticed by jean-mickael guerin . Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/ip6_tunnel.c 1.27 vs edited ===== --- 1.27/net/ipv6/ip6_tunnel.c 2005-01-14 13:41:06 +09:00 +++ edited/net/ipv6/ip6_tunnel.c 2005-02-05 01:50:53 +09:00 @@ -180,10 +180,10 @@ { struct ip6_tnl **tp = ip6ip6_bucket(&t->parms); - write_lock_bh(&ip6ip6_lock); t->next = *tp; - write_unlock_bh(&ip6ip6_lock); + write_lock_bh(&ip6ip6_lock); *tp = t; + write_unlock_bh(&ip6ip6_lock); } /** -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From serue@us.ibm.com Fri Feb 4 08:58:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 08:58:57 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14GwqMD025047 for ; Fri, 4 Feb 2005 08:58:52 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j14GweH5360968 for ; Fri, 4 Feb 2005 11:58:40 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j14Gweev457458 for ; Fri, 4 Feb 2005 09:58:40 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j14GwdXe005968 for ; Fri, 4 Feb 2005 09:58:40 -0700 Received: from IBM-BWN8ZTBWAO1.austin.ibm.com (IBM-BWN8ZTBWAO1.austin.ibm.com [9.41.223.195]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j14GwcaX005926; Fri, 4 Feb 2005 09:58:39 -0700 Received: by IBM-BWN8ZTBWAO1.austin.ibm.com (sSMTP sendmail emulation); Fri, 4 Feb 2005 10:58:40 -0600 Date: Fri, 4 Feb 2005 10:58:40 -0600 From: "Serge E. Hallyn" To: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Cc: linux-audit@redhat.com Subject: [PATCH] Add audit uid to netlink credentials Message-ID: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: serue@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8288 Lines: 223 Most audit control messages are sent over netlink. In order to properly log the identity of the sender of audit control messages, we would like to add the loginuid to the netlink_creds structure, as per the attached patch. thanks, -serge Signed-off-by: Serge Hallyn Index: linux-2.6.10/include/linux/audit.h =================================================================== --- linux-2.6.10.orig/include/linux/audit.h 2005-01-27 10:46:57.887036520 -0600 +++ linux-2.6.10/include/linux/audit.h 2005-01-27 10:51:37.408542792 -0600 @@ -145,7 +145,7 @@ extern void audit_inode(const char *name /* Private API (for audit.c only) */ extern int audit_receive_filter(int type, int pid, int uid, int seq, - void *data); + void *data, uid_t loginuid); extern void audit_get_stamp(struct audit_context *ctx, struct timespec *t, int *serial); extern int audit_set_loginuid(struct audit_context *ctx, uid_t loginuid); @@ -179,10 +179,10 @@ extern void audit_log_d_path(struct const char *prefix, struct dentry *dentry, struct vfsmount *vfsmnt); -extern int audit_set_rate_limit(int limit); -extern int audit_set_backlog_limit(int limit); -extern int audit_set_enabled(int state); -extern int audit_set_failure(int state); +extern int audit_set_rate_limit(int limit, uid_t loginuid); +extern int audit_set_backlog_limit(int limit, uid_t loginuid); +extern int audit_set_enabled(int state, uid_t loginuid); +extern int audit_set_failure(int state, uid_t loginuid); /* Private API (for auditsc.c only) */ extern void audit_send_reply(int pid, int seq, int type, Index: linux-2.6.10/include/linux/netlink.h =================================================================== --- linux-2.6.10.orig/include/linux/netlink.h 2005-01-27 10:46:57.888036368 -0600 +++ linux-2.6.10/include/linux/netlink.h 2005-01-27 10:51:37.409542640 -0600 @@ -110,6 +110,7 @@ struct netlink_skb_parms __u32 dst_pid; __u32 dst_groups; kernel_cap_t eff_cap; + __u32 loginuid; /* Login (audit) uid */ }; #define NETLINK_CB(skb) (*(struct netlink_skb_parms*)&((skb)->cb)) Index: linux-2.6.10/kernel/audit.c =================================================================== --- linux-2.6.10.orig/kernel/audit.c 2005-01-27 10:46:57.888036368 -0600 +++ linux-2.6.10/kernel/audit.c 2005-01-27 10:52:28.753737136 -0600 @@ -236,36 +236,36 @@ void audit_log_lost(const char *message) } -int audit_set_rate_limit(int limit) +int audit_set_rate_limit(int limit, uid_t loginuid) { int old = audit_rate_limit; audit_rate_limit = limit; - audit_log(current->audit_context, "audit_rate_limit=%d old=%d", - audit_rate_limit, old); + audit_log(NULL, "audit_rate_limit=%d old=%d by loginuid %u", + audit_rate_limit, old, loginuid); return old; } -int audit_set_backlog_limit(int limit) +int audit_set_backlog_limit(int limit, uid_t loginuid) { int old = audit_backlog_limit; audit_backlog_limit = limit; - audit_log(current->audit_context, "audit_backlog_limit=%d old=%d", - audit_backlog_limit, old); + audit_log(NULL, "audit_backlog_limit=%d old=%d by loginuid %u", + audit_backlog_limit, old, loginuid); return old; } -int audit_set_enabled(int state) +int audit_set_enabled(int state, uid_t loginuid) { int old = audit_enabled; if (state != 0 && state != 1) return -EINVAL; audit_enabled = state; - audit_log(current->audit_context, "audit_enabled=%d old=%d", - audit_enabled, old); + audit_log(NULL, "audit_enabled=%d old=%d by loginuid %u", + audit_enabled, old, loginuid); return old; } -int audit_set_failure(int state) +int audit_set_failure(int state, uid_t loginuid) { int old = audit_failure; if (state != AUDIT_FAIL_SILENT @@ -273,8 +273,8 @@ int audit_set_failure(int state) && state != AUDIT_FAIL_PANIC) return -EINVAL; audit_failure = state; - audit_log(current->audit_context, "audit_failure=%d old=%d", - audit_failure, old); + audit_log(NULL, "audit_failure=%d old=%d by loginuid %u", + audit_failure, old, loginuid); return old; } @@ -341,6 +341,7 @@ static int audit_receive_msg(struct sk_b int err; struct audit_buffer *ab; u16 msg_type = nlh->nlmsg_type; + uid_t loginuid; /* loginuid of sender */ err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type); if (err) @@ -348,6 +349,7 @@ static int audit_receive_msg(struct sk_b pid = NETLINK_CREDS(skb)->pid; uid = NETLINK_CREDS(skb)->uid; + loginuid = NETLINK_CB(skb).loginuid; seq = nlh->nlmsg_seq; data = NLMSG_DATA(nlh); @@ -368,31 +370,33 @@ static int audit_receive_msg(struct sk_b return -EINVAL; status_get = (struct audit_status *)data; if (status_get->mask & AUDIT_STATUS_ENABLED) { - err = audit_set_enabled(status_get->enabled); + err = audit_set_enabled(status_get->enabled, loginuid); if (err < 0) return err; } if (status_get->mask & AUDIT_STATUS_FAILURE) { - err = audit_set_failure(status_get->failure); + err = audit_set_failure(status_get->failure, loginuid); if (err < 0) return err; } if (status_get->mask & AUDIT_STATUS_PID) { int old = audit_pid; audit_pid = status_get->pid; - audit_log(current->audit_context, - "audit_pid=%d old=%d", audit_pid, old); + audit_log(NULL, "audit_pid=%d old=%d by loginuid %u", + audit_pid, old, loginuid); } if (status_get->mask & AUDIT_STATUS_RATE_LIMIT) - audit_set_rate_limit(status_get->rate_limit); + audit_set_rate_limit(status_get->rate_limit, loginuid); if (status_get->mask & AUDIT_STATUS_BACKLOG_LIMIT) - audit_set_backlog_limit(status_get->backlog_limit); + audit_set_backlog_limit(status_get->backlog_limit, + loginuid); break; case AUDIT_USER: ab = audit_log_start(NULL); if (!ab) break; /* audit_panic has been called */ audit_log_format(ab, - "user pid=%d uid=%d length=%d msg='%.1024s'", - pid, uid, + "user pid=%d uid=%d loginuid=%u length=%d" + " msg='%.1024s'", + pid, uid, loginuid, (int)(nlh->nlmsg_len - ((char *)data - (char *)nlh)), (char *)data); @@ -408,7 +412,7 @@ static int audit_receive_msg(struct sk_b case AUDIT_LIST: #ifdef CONFIG_AUDITSYSCALL err = audit_receive_filter(nlh->nlmsg_type, pid, uid, seq, - data); + data, loginuid); #else err = -EOPNOTSUPP; #endif Index: linux-2.6.10/kernel/auditsc.c =================================================================== --- linux-2.6.10.orig/kernel/auditsc.c 2005-01-27 10:46:57.890036064 -0600 +++ linux-2.6.10/kernel/auditsc.c 2005-01-27 10:52:53.776933032 -0600 @@ -228,7 +228,8 @@ static int audit_copy_rule(struct audit_ return 0; } -int audit_receive_filter(int type, int pid, int uid, int seq, void *data) +int audit_receive_filter(int type, int pid, int uid, int seq, void *data, + uid_t loginuid) { u32 flags; struct audit_entry *entry; @@ -263,6 +264,7 @@ int audit_receive_filter(int type, int p err = audit_add_rule(entry, &audit_entlist); if (!err && (flags & AUDIT_AT_EXIT)) err = audit_add_rule(entry, &audit_extlist); + audit_log(NULL, "loginuid %u added an audit rule\n", loginuid); break; case AUDIT_DEL: flags =((struct audit_rule *)data)->flags; @@ -272,6 +274,8 @@ int audit_receive_filter(int type, int p err = audit_del_rule(data, &audit_entlist); if (!err && (flags & AUDIT_AT_EXIT)) err = audit_del_rule(data, &audit_extlist); + audit_log(NULL, "loginuid %u removed an audit rule\n", + loginuid); break; default: return -EINVAL; Index: linux-2.6.10/net/netlink/af_netlink.c =================================================================== --- linux-2.6.10.orig/net/netlink/af_netlink.c 2005-01-27 10:46:57.891035912 -0600 +++ linux-2.6.10/net/netlink/af_netlink.c 2005-01-27 10:51:37.411542336 -0600 @@ -928,6 +928,7 @@ static int netlink_sendmsg(struct kiocb NETLINK_CB(skb).groups = nlk->groups; NETLINK_CB(skb).dst_pid = dst_pid; NETLINK_CB(skb).dst_groups = dst_groups; + NETLINK_CB(skb).loginuid = audit_get_loginuid(current->audit_context); memcpy(NETLINK_CREDS(skb), &siocb->scm->creds, sizeof(struct ucred)); /* What can I do? Netlink is asynchronous, so that From gandalf@wlug.westbo.se Fri Feb 4 09:34:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 09:34:54 -0800 (PST) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14HYnZ5027467 for ; Fri, 4 Feb 2005 09:34:49 -0800 Received: by null.rsn.bth.se (Postfix, from userid 65534) id CF8402C000E; Fri, 4 Feb 2005 18:34:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 731802C008D; Fri, 4 Feb 2005 18:34:44 +0100 (CET) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id B15D22C000E; Fri, 4 Feb 2005 18:34:43 +0100 (CET) Received: by tux.rsn.bth.se (Postfix, from userid 501) id B0B493F3F; Fri, 4 Feb 2005 18:34:43 +0100 (CET) Subject: Re: [PATCH] Reduce netfilter memory use on MP systems From: Martin Josefsson To: Patrick McHardy Cc: Andi Kleen , netdev@oss.sgi.com, Netfilter-devel In-Reply-To: <20050204140900.GD2518@wotan.suse.de> References: <20050204140900.GD2518@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-A0J9aMmekRjWTUo18QHr" Date: Fri, 04 Feb 2005 18:34:42 +0100 Message-Id: <1107538482.1111.6.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 on null.rsn.bth.se X-Virus-Status: Clean X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 1636 Lines: 47 --=-A0J9aMmekRjWTUo18QHr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 15:09 +0100, Andi Kleen wrote: > On kernels compiled with a big NR_CPUS netfilter rules would=20 > eat a lot of memory because all counters would be duplicated > for all NR_CPUs CPUs. With NR_CPUS=3D256 this would add up > to many MBs of memory. >=20 > This patch only allocates enough memory for the possible CPUs, > which is usually a much smaller number than NR_CPUS. >=20 > This allows loading of bigger rule sets on 64bit systems. > There is still a limit because someone else broke vmalloc to have a 64MB=20 > limit on 64bit systems for single allocations, 129MB on 32bit. > It allocates an array of pages with kmalloc and kmalloc has a 128K limit.= =20 > To be fixed with a separate patch. >=20 > 64bit systems were hurt worst because they tend to have big NR_CPUS > and the counters need more memory there, and the vmalloc limit is lower. > But it will raise the limits even on 32bit.=20 >=20 > And in general it saves a lot of memory. Patrick, could you apply and submit this patch to Davem? Or if Davem applies it himself. It's pretty obvious and would help small SMP machines with distribution kernels and/or strange admins. --=20 /Martin --=-A0J9aMmekRjWTUo18QHr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA7IyWm2vlfa207ERApm/AJ9LEA2DHbXBJhRewpcgZ95JWtcw5QCgsq+v wbiXYM5H1VpufxryKV8ufZU= =GMMw -----END PGP SIGNATURE----- --=-A0J9aMmekRjWTUo18QHr-- From ak@suse.de Fri Feb 4 09:51:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 09:51:44 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14HpexM028307 for ; Fri, 4 Feb 2005 09:51:41 -0800 Received: from hermes.suse.de (hermes-ext.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 E6E15140AAC9; Fri, 4 Feb 2005 18:51:34 +0100 (CET) Date: Fri, 4 Feb 2005 18:51:34 +0100 From: Andi Kleen To: Martin Josefsson Cc: Patrick McHardy , Andi Kleen , netdev@oss.sgi.com, Netfilter-devel Subject: Re: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050204175134.GD2737@wotan.suse.de> References: <20050204140900.GD2518@wotan.suse.de> <1107538482.1111.6.camel@tux.rsn.bth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107538482.1111.6.camel@tux.rsn.bth.se> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1272 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: 575 Lines: 13 > > And in general it saves a lot of memory. > > Patrick, could you apply and submit this patch to Davem? Or if Davem > applies it himself. It's pretty obvious and would help small SMP > machines with distribution kernels and/or strange admins. The main motivation is actually not to save the memory (that's just a useful side effect), but increase the max limit on 64bit systems. Fixing it fully will require fixing vmalloc of course, but it already help. Without it you can't get more than ~3800 rules on a 64bit system with NR_CPUS==128 and 128 byte cache lines. -Andi From chas@cmf.nrl.navy.mil Fri Feb 4 10:11:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:12:04 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IBv4H029337 for ; Fri, 4 Feb 2005 10:11:57 -0800 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 j14IBOna020338; Fri, 4 Feb 2005 13:11:27 -0500 (EST) Message-Id: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> To: Roman Kagan cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-Reply-To: Message from Roman Kagan of "Fri, 21 Jan 2005 11:51:23 +0300." <20050121085123.GA2471@katya> Date: Fri, 04 Feb 2005 13:11:25 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1273 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: 9944 Lines: 383 In message <20050121085123.GA2471@katya>,Roman Kagan writes: >The patch is against 2.6.10. Please comment. i guess i would prefer that entries be named typeN, like he0 instead of just a number. you were printing 7 octets for the address. if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the kfree. i added some other fields that i think are interesting. comments? # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/04 13:05:34-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/atm_sysfs.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +181 -0 # # net/atm/resources.h # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +3 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/resources.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +22 -6 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/atm_sysfs.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +0 -0 # BitKeeper file /scratch/chas/LATEST/2.6/net/atm/atm_sysfs.c # # net/atm/common.h # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +2 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/common.c # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +6 -1 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/Makefile # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # include/linux/atmdev.h # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +2 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # diff -Nru a/include/linux/atmdev.h b/include/linux/atmdev.h --- a/include/linux/atmdev.h 2005-02-04 13:06:48 -05:00 +++ b/include/linux/atmdev.h 2005-02-04 13:06:48 -05:00 @@ -8,6 +8,7 @@ #include +#include #include #include #include @@ -345,6 +346,7 @@ struct proc_dir_entry *proc_entry; /* proc entry */ char *proc_name; /* proc entry name */ #endif + struct class_device class_dev; /* sysfs class device */ struct list_head dev_list; /* linkage */ }; diff -Nru a/net/atm/Makefile b/net/atm/Makefile --- a/net/atm/Makefile 2005-02-04 13:06:48 -05:00 +++ b/net/atm/Makefile 2005-02-04 13:06:48 -05:00 @@ -2,7 +2,7 @@ # Makefile for the ATM Protocol Families. # -atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o +atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o atm_sysfs.o mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o obj-$(CONFIG_ATM) += atm.o diff -Nru a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/atm/atm_sysfs.c 2005-02-04 13:06:48 -05:00 @@ -0,0 +1,181 @@ +/* ATM driver model support. */ + +#include +#include +#include +#include +#include +#include "common.h" +#include "resources.h" + +#define to_atm_dev(cldev) container_of(cldev, struct atm_dev, class_dev) + +static ssize_t show_type(struct class_device *cdev, char *buf) +{ + struct atm_dev *adev = to_atm_dev(cdev); + return sprintf(buf, "%s\n", adev->type); +} + +static ssize_t show_address(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + int i; + + for (i = 0; i < (ESI_LEN - 1); i++) + pos += sprintf(pos, "%02x:", adev->esi[i]); + pos += sprintf(pos, "%02x\n", adev->esi[i]); + + return pos - buf; +} + +static ssize_t show_atmaddress(struct class_device *cdev, char *buf) +{ + unsigned long flags; + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + struct atm_dev_addr *aaddr; + int bin[] = { 1, 2, 10, 6, 1 }, *fmt = bin; + int i, j; + + spin_lock_irqsave(&adev->lock, flags); + list_for_each_entry(aaddr, &adev->local, entry) { + for(i = 0, j = 0; i < ATM_ESA_LEN; ++i, ++j) { + if (j == *fmt) { + pos += sprintf(pos, "."); + ++fmt; + j = 0; + } + pos += sprintf(pos, "%02x", aaddr->addr.sas_addr.prv[i]); + } + pos += sprintf(pos, "\n"); + } + spin_unlock_irqrestore(&adev->lock, flags); + + return pos - buf; +} + +static ssize_t show_carrier(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + + pos += sprintf(pos, "%d\n", + adev->signal == ATM_PHY_SIG_LOST ? 0 : 1); + + return pos - buf; +} + +static ssize_t show_link_rate(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + int link_rate; + + /* show the link rate, not the data rate */ + switch (adev->link_rate) { + case ATM_OC3_PCR: + link_rate = 155520000; + break; + case ATM_OC12_PCR: + link_rate = 622080000; + break; + case ATM_25_PCR: + link_rate = 25600000; + break; + default: + link_rate = adev->link_rate * 8 * 53; + } + pos += sprintf(pos, "%d\n", link_rate); + + return pos - buf; +} + +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); +static CLASS_DEVICE_ATTR(atmaddress, S_IRUGO, show_atmaddress, NULL); +static CLASS_DEVICE_ATTR(carrier, S_IRUGO, show_carrier, NULL); +static CLASS_DEVICE_ATTR(type, S_IRUGO, show_type, NULL); +static CLASS_DEVICE_ATTR(link_rate, S_IRUGO, show_link_rate, NULL); + +static struct class_device_attribute *atm_attrs[] = { + &class_device_attr_atmaddress, + &class_device_attr_address, + &class_device_attr_carrier, + &class_device_attr_type, + &class_device_attr_link_rate, + NULL +}; + +#ifdef CONFIG_HOTPLUG +static int atm_hotplug(struct class_device *cdev, char **envp, int num_envp, char *buf, int size) +{ + struct atm_dev *adev; + int i = 0; + int length = 0; + + if (!cdev) + return -ENODEV; + + adev = to_atm_dev(cdev); + if (!adev) + return -ENODEV; + + if (add_hotplug_env_var(envp, num_envp, &i, buf, size, &length, + "INTERFACE=%s%d", adev->type, adev->number)) + return -ENOMEM; + + envp[i] = NULL; + return 0; +} +#endif + +static void atm_release(struct class_device *cdev) +{ + struct atm_dev *adev = to_atm_dev(cdev); + + kfree(adev); +} + +static struct class atm_class = { + .name = "atm", + .release = atm_release, +#ifdef CONFIG_HOTPLUG + .hotplug = atm_hotplug, +#endif +}; + +int atm_register_sysfs(struct atm_dev *adev) +{ + struct class_device *cdev = &adev->class_dev; + int i, err; + + cdev->class = &atm_class; + class_set_devdata(cdev, adev); + + snprintf(cdev->class_id, BUS_ID_SIZE, "%s%d", adev->type, adev->number); + err = class_device_register(cdev); + if (err < 0) + return err; + + for (i = 0; atm_attrs[i]; i++) + class_device_create_file(cdev, atm_attrs[i]); + + return 0; +} + +void atm_unregister_sysfs(struct atm_dev *adev) +{ + struct class_device *cdev = &adev->class_dev; + + class_device_del(cdev); +} + +int __init atm_sysfs_init(void) +{ + return class_register(&atm_class); +} + +void __exit atm_sysfs_exit(void) +{ + class_unregister(&atm_class); +} diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c 2005-02-04 13:06:48 -05:00 +++ b/net/atm/common.c 2005-02-04 13:06:48 -05:00 @@ -793,6 +793,10 @@ printk(KERN_ERR "atm_proc_init() failed with %d\n",error); goto failure; } + if ((error = atm_sysfs_init()) < 0) { + printk(KERN_ERR "atm_sysfs_init() failed with %d\n",error); + goto failure; + } return 0; failure: @@ -804,11 +808,12 @@ static void __exit atm_exit(void) { atm_proc_exit(); + atm_sysfs_exit(); atmsvc_exit(); atmpvc_exit(); } -module_init(atm_init); +subsys_initcall(atm_init); module_exit(atm_exit); MODULE_LICENSE("GPL"); diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h 2005-02-04 13:06:48 -05:00 +++ b/net/atm/common.h 2005-02-04 13:06:48 -05:00 @@ -28,6 +28,8 @@ void atmpvc_exit(void); int atmsvc_init(void); void atmsvc_exit(void); +int atm_sysfs_init(void); +void atm_sysfs_exit(void); #ifdef CONFIG_PROC_FS int atm_proc_init(void); diff -Nru a/net/atm/resources.c b/net/atm/resources.c --- a/net/atm/resources.c 2005-02-04 13:06:48 -05:00 +++ b/net/atm/resources.c 2005-02-04 13:06:48 -05:00 @@ -47,7 +47,11 @@ static void __free_atm_dev(struct atm_dev *dev) { +#ifdef CONFIG_SYSFS + class_device_put(&dev->class_dev); +#else kfree(dev); +#endif } static struct atm_dev *__atm_dev_lookup(int number) @@ -91,7 +95,7 @@ if ((inuse = __atm_dev_lookup(number))) { atm_dev_put(inuse); spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); + kfree(dev); return NULL; } dev->number = number; @@ -117,14 +121,25 @@ printk(KERN_ERR "atm_dev_register: " "atm_proc_dev_register failed for dev %s\n", type); - spin_lock(&atm_dev_lock); - list_del(&dev->dev_list); - spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); - return NULL; + goto reg_fail; + } + + if (atm_register_sysfs(dev) < 0) { + printk(KERN_ERR "atm_dev_register: " + "atm_register_sysfs failed for dev %s\n", + type); + atm_proc_dev_deregister(dev); + goto reg_fail; } return dev; + +reg_fail: + spin_lock(&atm_dev_lock); + list_del(&dev->dev_list); + spin_unlock(&atm_dev_lock); + kfree(dev); + return NULL; } @@ -132,6 +147,7 @@ { unsigned long warning_time; + atm_unregister_sysfs(dev); atm_proc_dev_deregister(dev); spin_lock(&atm_dev_lock); diff -Nru a/net/atm/resources.h b/net/atm/resources.h --- a/net/atm/resources.h 2005-02-04 13:06:48 -05:00 +++ b/net/atm/resources.h 2005-02-04 13:06:48 -05:00 @@ -43,4 +43,7 @@ #endif /* CONFIG_PROC_FS */ +int atm_register_sysfs(struct atm_dev *adev); +void atm_unregister_sysfs(struct atm_dev *adev); + #endif From kaber@trash.net Fri Feb 4 10:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:13:42 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IDb6g029677 for ; Fri, 4 Feb 2005 10:13:38 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cx7xW-0004Sz-JM; Fri, 04 Feb 2005 19:13:34 +0100 Message-ID: <4203BB4E.3070908@trash.net> Date: Fri, 04 Feb 2005 19:13:34 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Martin Josefsson , netdev@oss.sgi.com, Netfilter-devel Subject: Re: [PATCH] Reduce netfilter memory use on MP systems References: <20050204140900.GD2518@wotan.suse.de> <1107538482.1111.6.camel@tux.rsn.bth.se> <20050204175134.GD2737@wotan.suse.de> In-Reply-To: <20050204175134.GD2737@wotan.suse.de> Content-Type: multipart/mixed; boundary="------------000409090703040601060603" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 6217 Lines: 195 This is a multi-part message in MIME format. --------------000409090703040601060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: >The main motivation is actually not to save the memory (that's just >a useful side effect), but increase the max limit on 64bit systems. >Fixing it fully will require fixing vmalloc of course, but it already >help. Without it you can't get more than ~3800 rules >on a 64bit system with NR_CPUS==128 and 128 byte cache lines. > Thanks Andi, I've added the patch to my 2.6.12 tree. I've also made the same change in arp_tables, ip6_tables and ebtables for consistency. Regards Patrick --------------000409090703040601060603 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/bridge/netfilter/ebtables.c 1.17 vs edited ===== --- 1.17/net/bridge/netfilter/ebtables.c 2004-11-24 08:46:46 +01:00 +++ edited/net/bridge/netfilter/ebtables.c 2005-02-04 19:03:01 +01:00 @@ -822,10 +822,10 @@ /* this will get free'd in do_replace()/ebt_register_table() if an error occurs */ newinfo->chainstack = (struct ebt_chainstack **) - vmalloc(NR_CPUS * sizeof(struct ebt_chainstack)); + vmalloc(num_possible_cpus() * sizeof(struct ebt_chainstack)); if (!newinfo->chainstack) return -ENOMEM; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { newinfo->chainstack[i] = vmalloc(udc_cnt * sizeof(struct ebt_chainstack)); if (!newinfo->chainstack[i]) { @@ -898,7 +898,7 @@ memcpy(counters, oldcounters, sizeof(struct ebt_counter) * nentries); /* add other counters to those of cpu 0 */ - for (cpu = 1; cpu < NR_CPUS; cpu++) { + for (cpu = 1; cpu < num_possible_cpus(); cpu++) { counter_base = COUNTER_BASE(oldcounters, nentries, cpu); for (i = 0; i < nentries; i++) { counters[i].pcnt += counter_base[i].pcnt; @@ -930,7 +930,7 @@ BUGPRINT("Entries_size never zero\n"); return -EINVAL; } - countersize = COUNTER_OFFSET(tmp.nentries) * NR_CPUS; + countersize = COUNTER_OFFSET(tmp.nentries) * num_possible_cpus(); newinfo = (struct ebt_table_info *) vmalloc(sizeof(struct ebt_table_info) + countersize); if (!newinfo) @@ -1023,7 +1023,7 @@ vfree(table->entries); if (table->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(table->chainstack[i]); vfree(table->chainstack); } @@ -1043,7 +1043,7 @@ vfree(counterstmp); /* can be initialized in translate_table() */ if (newinfo->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(newinfo->chainstack[i]); vfree(newinfo->chainstack); } @@ -1137,7 +1137,7 @@ return -EINVAL; } - countersize = COUNTER_OFFSET(table->table->nentries) * NR_CPUS; + countersize = COUNTER_OFFSET(table->table->nentries) * num_possible_cpus(); newinfo = (struct ebt_table_info *) vmalloc(sizeof(struct ebt_table_info) + countersize); ret = -ENOMEM; @@ -1191,7 +1191,7 @@ up(&ebt_mutex); free_chainstack: if (newinfo->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(newinfo->chainstack[i]); vfree(newinfo->chainstack); } @@ -1215,7 +1215,7 @@ if (table->private->entries) vfree(table->private->entries); if (table->private->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(table->private->chainstack[i]); vfree(table->private->chainstack); } ===== net/ipv4/netfilter/arp_tables.c 1.23 vs edited ===== --- 1.23/net/ipv4/netfilter/arp_tables.c 2005-01-11 03:45:54 +01:00 +++ edited/net/ipv4/netfilter/arp_tables.c 2005-02-04 19:01:20 +01:00 @@ -717,7 +717,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -768,7 +768,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; ARPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -886,7 +886,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct arpt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1159,7 +1159,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct arpt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) { ret = -ENOMEM; return ret; ===== net/ipv6/netfilter/ip6_tables.c 1.39 vs edited ===== --- 1.39/net/ipv6/netfilter/ip6_tables.c 2005-01-11 03:45:54 +01:00 +++ edited/net/ipv6/netfilter/ip6_tables.c 2005-02-04 19:01:55 +01:00 @@ -952,7 +952,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -974,7 +974,7 @@ struct ip6t_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -1021,7 +1021,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IP6T_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1155,7 +1155,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ip6t_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1469,7 +1469,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ip6t_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; --------------000409090703040601060603-- From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:23:17 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14INDmE030392 for ; Fri, 4 Feb 2005 10:23:14 -0800 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 j14IN6RU020651; Fri, 4 Feb 2005 13:23:06 -0500 (EST) Message-Id: <200502041823.j14IN6RU020651@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1 of 3][ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() Date: Fri, 04 Feb 2005 13:23:07 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1275 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: 1765 Lines: 50 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 11:38:49-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/horizon.c # 2005/02/03 11:38:31-05:00 chas@relax.cmf.nrl.navy.mil +6 -7 # [ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/horizon.c b/drivers/atm/horizon.c --- a/drivers/atm/horizon.c 2005-02-03 12:17:39 -05:00 +++ b/drivers/atm/horizon.c 2005-02-03 12:17:39 -05:00 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include @@ -1089,13 +1090,11 @@ /********** (queue to) become the next TX thread **********/ static inline int tx_hold (hrz_dev * dev) { - while (test_and_set_bit (tx_busy, &dev->flags)) { - PRINTD (DBG_TX, "sleeping at tx lock %p %lu", dev, dev->flags); - interruptible_sleep_on (&dev->tx_queue); - PRINTD (DBG_TX, "woken at tx lock %p %lu", dev, dev->flags); - if (signal_pending (current)) - return -1; - } + PRINTD (DBG_TX, "sleeping at tx lock %p %lu", dev, dev->flags); + wait_event_interruptible(dev->tx_queue, (!test_and_set_bit(tx_busy, &dev->flags))); + PRINTD (DBG_TX, "woken at tx lock %p %lu", dev, dev->flags); + if (signal_pending (current)) + return -1; PRINTD (DBG_TX, "set tx_busy for dev %p", dev); return 0; } From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:24:03 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14INwC3030763 for ; Fri, 4 Feb 2005 10:23:58 -0800 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 j14INqY4020685; Fri, 4 Feb 2005 13:23:52 -0500 (EST) Message-Id: <200502041823.j14INqY4020685@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 3 of 3][ATM]: [zatm] replace sleep_on() with wait_event() Date: Fri, 04 Feb 2005 13:23:53 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1277 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: 2049 Lines: 72 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 12:05:12-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [zatm] replace sleep_on() with wait_event() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/zatm.c # 2005/02/03 12:04:54-05:00 chas@relax.cmf.nrl.navy.mil +10 -19 # [ATM]: [zatm] replace sleep_on() with wait_event() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c 2005-02-03 12:18:33 -05:00 +++ b/drivers/atm/zatm.c 2005-02-03 12:18:33 -05:00 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -867,31 +868,21 @@ struct zatm_vcc *zatm_vcc; unsigned long flags; int chan; -struct sk_buff *skb; -int once = 1; zatm_vcc = ZATM_VCC(vcc); zatm_dev = ZATM_DEV(vcc->dev); chan = zatm_vcc->tx_chan; if (!chan) return; DPRINTK("close_tx\n"); - while (skb_peek(&zatm_vcc->backlog)) { -if (once) { -printk("waiting for backlog to drain ...\n"); -event_dump(); -once = 0; -} - sleep_on(&zatm_vcc->tx_wait); - } -once = 1; - while ((skb = skb_peek(&zatm_vcc->tx_queue))) { -if (once) { -printk("waiting for TX queue to drain ... %p\n",skb); -event_dump(); -once = 0; -} - DPRINTK("waiting for TX queue to drain ... %p\n",skb); - sleep_on(&zatm_vcc->tx_wait); + if (skb_peek(&zatm_vcc->backlog)) { + printk("waiting for backlog to drain ...\n"); + event_dump(); + wait_event(zatm_vcc->tx_wait, !skb_peek(&zatm_vcc->backlog)); + } + if (skb_peek(&zatm_vcc->tx_queue)) { + printk("waiting for TX queue to drain ...\n"); + event_dump(); + wait_event(zatm_vcc->tx_wait, !skb_peek(&zatm_vcc->tx_queue)); } spin_lock_irqsave(&zatm_dev->lock, flags); #if 0 From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:23:45 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14INfBV030533 for ; Fri, 4 Feb 2005 10:23:41 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j14INXtL020671; Fri, 4 Feb 2005 13:23:33 -0500 (EST) Message-Id: <200502041823.j14INXtL020671@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 2 of 3][ATM]: [iphase] remove sleep_on*() usage Date: Fri, 04 Feb 2005 13:23:34 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1276 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: 3033 Lines: 83 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 11:28:25-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [iphase] remove sleep_on*() usage # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/iphase.c # 2005/02/03 11:26:35-05:00 chas@relax.cmf.nrl.navy.mil +12 -14 # [ATM]: [iphase] remove sleep_on*() usage # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/iphase.c b/drivers/atm/iphase.c --- a/drivers/atm/iphase.c 2005-02-03 12:17:19 -05:00 +++ b/drivers/atm/iphase.c 2005-02-03 12:17:19 -05:00 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include #include @@ -2586,14 +2587,14 @@ } static void ia_close(struct atm_vcc *vcc) -{ +{ + DEFINE_WAIT(wait); u16 *vc_table; IADEV *iadev; struct ia_vcc *ia_vcc; struct sk_buff *skb = NULL; struct sk_buff_head tmp_tx_backlog, tmp_vcc_backlog; unsigned long closetime, flags; - int ctimeout; iadev = INPH_IA_DEV(vcc->dev); ia_vcc = INPH_IA_VCC(vcc); @@ -2606,7 +2607,9 @@ skb_queue_head_init (&tmp_vcc_backlog); if (vcc->qos.txtp.traffic_class != ATM_NONE) { iadev->close_pending++; - sleep_on_timeout(&iadev->timeout_wait, 50); + prepare_to_wait(&iadev->timeout_wait, &wait, TASK_UNINTERRUPTIBLE); + schedule_timeout(50); + finish_wait(&iadev->timeout_wait, &wait); spin_lock_irqsave(&iadev->tx_lock, flags); while((skb = skb_dequeue(&iadev->tx_backlog))) { if (ATM_SKB(skb)->vcc == vcc){ @@ -2619,17 +2622,12 @@ while((skb = skb_dequeue(&tmp_tx_backlog))) skb_queue_tail(&iadev->tx_backlog, skb); IF_EVENT(printk("IA TX Done decs_cnt = %d\n", ia_vcc->vc_desc_cnt);) - closetime = jiffies; - ctimeout = 300000 / ia_vcc->pcr; - if (ctimeout == 0) - ctimeout = 1; - while (ia_vcc->vc_desc_cnt > 0){ - if ((jiffies - closetime) >= ctimeout) - break; - spin_unlock_irqrestore(&iadev->tx_lock, flags); - sleep_on(&iadev->close_wait); - spin_lock_irqsave(&iadev->tx_lock, flags); - } + closetime = 300000 / ia_vcc->pcr; + if (closetime == 0) + closetime = 1; + spin_unlock_irqrestore(&iadev->tx_lock, flags); + wait_event_timeout(iadev->close_wait, (ia_vcc->vc_desc_cnt <= 0), closetime); + spin_lock_irqsave(&iadev->tx_lock, flags); iadev->close_pending--; iadev->testTable[vcc->vci]->lastTime = 0; iadev->testTable[vcc->vci]->fract = 0; From castet.matthieu@free.fr Fri Feb 4 10:27:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:27:15 -0800 (PST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IRAQm031840 for ; Fri, 4 Feb 2005 10:27:11 -0800 Received: from [82.67.62.65] (mutualite-1-82-67-62-65.fbx.proxad.net [82.67.62.65]) by postfix3-1.free.fr (Postfix) with ESMTP id BD7D31734FB; Fri, 4 Feb 2005 19:27:07 +0100 (CET) Message-ID: <4203BE7B.2030503@free.fr> Date: Fri, 04 Feb 2005 19:27:07 +0100 From: matthieu castet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: fr-fr, en, en-us MIME-Version: 1.0 To: chas williams - CONTRACTOR Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) References: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> In-Reply-To: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: castet.matthieu@free.fr Precedence: bulk X-list: netdev Content-Length: 856 Lines: 36 Hi, chas williams - CONTRACTOR wrote: > In message <20050121085123.GA2471@katya>,Roman Kagan writes: > >>The patch is against 2.6.10. Please comment. > > > i guess i would prefer that entries be named typeN, like he0 > instead of just a number. > > you were printing 7 octets for the address. > > if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the > kfree. > > i added some other fields that i think are interesting. > > comments? > > + > +static ssize_t show_carrier(struct class_device *cdev, char *buf) > +{ > + char *pos = buf; > + struct atm_dev *adev = to_atm_dev(cdev); > + > + pos += sprintf(pos, "%d\n", > + adev->signal == ATM_PHY_SIG_LOST ? 0 : 1); > + > + return pos - buf; > +} Shouldn't adev->signal == ATM_PHY_SIG_FOUND ? 1 : 0); be better : in the case of ATM_PHY_SIG_UNKNOWN, it return 1... Matthieu From brazilnut@us.ibm.com Fri Feb 4 10:45:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:45:53 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IjfVq032620 for ; Fri, 4 Feb 2005 10:45:48 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j14IjaZ7428462 for ; Fri, 4 Feb 2005 13:45:36 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j14IjZBC307584 for ; Fri, 4 Feb 2005 11:45:35 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j14IjZmo006042 for ; Fri, 4 Feb 2005 11:45:35 -0700 Received: from DYN319661.beaverton.ibm.com (DYN319661.beaverton.ibm.com [9.47.22.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j14IjZiQ006030; Fri, 4 Feb 2005 11:45:35 -0700 Received: by DYN319661.beaverton.ibm.com (Postfix, from userid 1000) id 0BEED229AFD; Fri, 4 Feb 2005 10:45:32 -0800 (PST) Date: Fri, 4 Feb 2005 10:45:31 -0800 From: Don Fry To: Richard Hobbs Cc: netdev@oss.sgi.com Subject: Re: [PATCH 4 2.4.27] pcnet32: Add HomePNA parameter for 79C978. Message-ID: <20050204184531.GA15595@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1279 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: 2092 Lines: 62 Richard, 2.6.10 has the driver to support the 79c978 card in homepna mode. I have only used the card in a point-to-point configuration when in homepna mode, because all I have is two cards (no modem/router). When you bring up the card with homepna=1, if you look in /var/log/messages it should indicate the speed at which the card is operating. In my system I see: pcnet32: media set to 1Mbit mode. pcnet32: PCnet/Home 79C978 at 0x252c00, 00 90 00 05 dd 27 assigned IRQ 201. eth8: registered as PCnet/Home 79C978 pcnet32: 8 cards_found. With the cards cabled together I see link detected using ethtool. # ethtool eth8 Settings for eth8: Current message level: 0x00000007 (7) Link detected: yes On Fri, Feb 04, 2005 at 12:42:07AM +0000, Richard Hobbs wrote: > > I am trying to set up a hybrid network, part wired, part wireless and part > homePNA (the building has some very thick walls and remote computers that can be > reached by existing telephone wires). I am using Fedora core 3 with the 2.6.10 > kernel. I have checked the pcnet32.c code and the patch 4 2.4.27 appears to be > there. > > I load the pcnet32 module using: > modprobe -v pcnet32 homepna=1 > > I get reply: > insmod /lib/modules/2.6.10-1.741_FC3/kernel/drivers/net/pcnet32.ko homepna=1 > > Looks good. > > I then try to configure the network through the systems settings interface: > eth0 is a e100 ethernet to my router/modem that is OK. > Disconnecting eth0 to avoid any conflicts. > > eth1 should be the AMD79c978 card. Connecting with the telephone wire > > I set eth1 as an ethernet (I don't see an option for phoneline network) > I have tried DHCP get the response on activating the network: > Determining IP information for eth1 failed; no link present. Check cable. > > I have tried a static IP address, card activates but no device is detected at > the modem/router. > > If I unload the module and reload without the homepna option, the card works > fine with a standard ethernet cable. > > Any suggestions please. > > Thanks > Richard Hobbs -- Don Fry brazilnut@us.ibm.com From jketreno@linux.intel.com Fri Feb 4 10:48:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:48:21 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14Im28h000673 for ; Fri, 4 Feb 2005 10:48:03 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j14Ilvtr024069 for ; Fri, 4 Feb 2005 18:47:57 GMT Received: from [192.168.1.154] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j14Ilbv0022747 for ; Fri, 4 Feb 2005 18:47:42 GMT Message-ID: <4203C32A.70402@linux.intel.com> Date: Fri, 04 Feb 2005 12:47:06 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH] ieee80211 subsystem X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040601040104090008060909" X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 147314 Lines: 5008 This is a multi-part message in MIME format. --------------040601040104090008060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 subsystem used by the ipw2100 and ipw2200 projects. I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that use thist stack to the list on Monday. In terms of what the stack currently does: * HW independent -- it only knows about 802.11 data and structures * Performs an 802.3 <-> 802.11 transform for data Tx/Rx * Host based support for fragmentation, WEP, and WPA using the kernel's crypto functions * Beacon and probe response collection and parsing * Default implementation of some of the WE handlers that can be managed without hardware knowledge We are working to merge in Dave Miller's p80211 code into the ieee80211 subsystem so that it hooks into the kernel as a true network layer as opposed to a mutated offspring of ethernet. Once that is done, hopefully the skb to txb code can be reworked and 802.11 fragments can be treated either as normal skbs, or skbs can be modified to directly support them (ideally so that encrypted 802.11 frames in support of IP packets can be cached by the stack instead of having to be re-encrypted on TCP retries) Support for HW/FW crypto and fragmentation offload, in a HW independent fashion, is also on the short-term list. When you look through the patch you'll likely notice the #ifdef NOTYET/#endif sequences surrounding portions of code from the hostap project. Portions of this subsystem were based on an earlier version of the hostap project. Those areas that weren't directly supported by the ipw* projects weren't ported to be completely hardware independent (since I don't have the hardware to test it), and so are still wrapped in the ifdefs. These sections mainly cover support for MASTER and WDS modes. Anyway, please let me know what you think. Hopefully I built the patch right... Thanks, James --------------040601040104090008060909 Content-Type: text/x-patch; name="netdev-2.6-ieee80211.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdev-2.6-ieee80211.patch" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/Kconfig netdev-2.6-ipw/drivers/net/wireless/Kconfig --- netdev-2.6/drivers/net/wireless/Kconfig 2005-02-04 10:10:44 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/Kconfig 2005-02-04 10:20:02 -06:00 @@ -28,6 +28,8 @@ special kernel support are available from . +source "drivers/net/wireless/ieee80211/Kconfig" + # Note : the cards are obsolete (can't buy them anymore), but the drivers # are not, as people are still using them... comment "Obsolete Wireless cards support (pre-802.11)" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/Kconfig netdev-2.6-ipw/drivers/net/wireless/ieee80211/Kconfig --- netdev-2.6/drivers/net/wireless/ieee80211/Kconfig 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/Kconfig 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,72 @@ +config IEEE80211 + tristate "Generic IEEE 802.11 Networking Stack" + depends on NET_RADIO + +config IEEE80211_DEBUG + bool "Enable full debugging output" + depends on IEEE80211 + ---help--- + This option will enable debug tracing output for the + ieee80211 network stack. + + This will result in the kernel module being ~70k larger. You + can control which debug output is sent to the kernel log by + setting the value in + + /proc/net/ieee80211/debug_level + + For example: + + % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level + + For a list of values you can assign to debug_level, simply + perform: + + % . idvals + + From within drivers/net/wireless/ipw2200 + + If you are not trying to debug or develop the IPW2200 driver, + you + most likely want to say N here. + +config IEEE80211_CRYPT + tristate "IEEE 802.11 encryption" + depends on IEEE80211 + select CRYPTO + select CRYPTO_ARC4 + select CRC32 + ---help--- + Software implementation of IEEE 802.11 encryption. This module + adds WEP support, and the baseline capabilities required for + WPA. + + This can be compiled as a modules and it will be called + "ieee80211_crypt.ko". + +config IEEE80211_WPA + tristate "IEEE 802.11 WPA" + depends on IEEE80211_CRYPT + ---help--- + Software implementation of IEEE 802.11 WPA. You will need + to select the WPA algorithms you wish to use. + +config IEEE80211_CRYPT_CCMP + tristate "IEEE 802.11 CCMP encryption" + depends on IEEE80211_WPA + select CRYPTO_AES_586 + ---help--- + Software implementation of IEEE 802.11 CCMP encryption. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_ccmp.ko". + +config IEEE80211_CRYPT_TKIP + tristate "IEEE 802.11 TKIP encryption" + depends on IEEE80211_WPA + select CRYPTO_MICHAEL_MIC + ---help--- + Software implementation of IEEE 802.11 TKIP encryption. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_tkip.ko". diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/Makefile netdev-2.6-ipw/drivers/net/wireless/ieee80211/Makefile --- netdev-2.6/drivers/net/wireless/ieee80211/Makefile 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/Makefile 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,11 @@ +obj-$(CONFIG_IEEE80211) += ieee80211.o +obj-$(CONFIG_IEEE80211_CRYPT) += ieee80211_crypt.o +obj-$(CONFIG_IEEE80211_CRYPT) += ieee80211_crypt_wep.o +obj-$(CONFIG_IEEE80211_CRYPT_WPA) += ieee80211_crypt_ccmp.o +obj-$(CONFIG_IEEE80211_CRYPT_WPA) += ieee80211_crypt_tkip.o +ieee80211-objs := \ + ieee80211_module.o \ + ieee80211_tx.o \ + ieee80211_rx.o \ + ieee80211_wx.o + diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,253 @@ +/* + * Host AP crypto routines + * + * Copyright (c) 2002-2003, Jouni Malinen + * Portions Copyright (C) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("HostAP crypto"); +MODULE_LICENSE("GPL"); + +struct ieee80211_crypto_alg { + struct list_head list; + struct ieee80211_crypto_ops *ops; +}; + + +struct ieee80211_crypto { + struct list_head algs; + spinlock_t lock; +}; + +static struct ieee80211_crypto *hcrypt; + +void ieee80211_crypt_deinit_entries(struct ieee80211_device *ieee, + int force) +{ + struct list_head *ptr, *n; + struct ieee80211_crypt_data *entry; + + for (ptr = ieee->crypt_deinit_list.next, n = ptr->next; + ptr != &ieee->crypt_deinit_list; ptr = n, n = ptr->next) { + entry = list_entry(ptr, struct ieee80211_crypt_data, list); + + if (atomic_read(&entry->refcnt) != 0 && !force) + continue; + + list_del(ptr); + + if (entry->ops) { + entry->ops->deinit(entry->priv); + module_put(entry->ops->owner); + } + kfree(entry); + } +} + +void ieee80211_crypt_deinit_handler(unsigned long data) +{ + struct ieee80211_device *ieee = (struct ieee80211_device *)data; + unsigned long flags; + + spin_lock_irqsave(&ieee->lock, flags); + ieee80211_crypt_deinit_entries(ieee, 0); + if (!list_empty(&ieee->crypt_deinit_list)) { + printk(KERN_DEBUG "%s: entries remaining in delayed crypt " + "deletion list\n", ieee->dev->name); + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); + +} + +void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee, + struct ieee80211_crypt_data **crypt) +{ + struct ieee80211_crypt_data *tmp; + unsigned long flags; + + if (*crypt == NULL) + return; + + tmp = *crypt; + *crypt = NULL; + + /* must not run ops->deinit() while there may be pending encrypt or + * decrypt operations. Use a list of delayed deinits to avoid needing + * locking. */ + + spin_lock_irqsave(&ieee->lock, flags); + list_add(&tmp->list, &ieee->crypt_deinit_list); + if (!timer_pending(&ieee->crypt_deinit_timer)) { + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); +} + +int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct ieee80211_crypto_alg *alg; + + if (hcrypt == NULL) + return -1; + + alg = kmalloc(sizeof(*alg), GFP_KERNEL); + if (alg == NULL) + return -ENOMEM; + + memset(alg, 0, sizeof(*alg)); + alg->ops = ops; + + spin_lock_irqsave(&hcrypt->lock, flags); + list_add(&alg->list, &hcrypt->algs); + spin_unlock_irqrestore(&hcrypt->lock, flags); + + printk(KERN_DEBUG "ieee80211_crypt: registered algorithm '%s'\n", + ops->name); + + return 0; +} + +int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *del_alg = NULL; + + if (hcrypt == NULL) + return -1; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (alg->ops == ops) { + list_del(&alg->list); + del_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (del_alg) { + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s'\n", ops->name); + kfree(del_alg); + } + + return del_alg ? 0 : -1; +} + + +struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *found_alg = NULL; + + if (hcrypt == NULL) + return NULL; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (strcmp(alg->ops->name, name) == 0) { + found_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (found_alg) + return found_alg->ops; + else + return NULL; +} + + +static void * ieee80211_crypt_null_init(int keyidx) { return (void *) 1; } +static void ieee80211_crypt_null_deinit(void *priv) {} + +static struct ieee80211_crypto_ops ieee80211_crypt_null = { + .name = "NULL", + .init = ieee80211_crypt_null_init, + .deinit = ieee80211_crypt_null_deinit, + .encrypt_mpdu = NULL, + .decrypt_mpdu = NULL, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = NULL, + .get_key = NULL, + .extra_prefix_len = 0, + .extra_postfix_len = 0, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_init(void) +{ + hcrypt = kmalloc(sizeof(*hcrypt), GFP_KERNEL); + if (hcrypt == NULL) + return -ENOMEM; + + memset(hcrypt, 0, sizeof(*hcrypt)); + INIT_LIST_HEAD(&hcrypt->algs); + spin_lock_init(&hcrypt->lock); + + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); + + return 0; +} + + +static void __exit ieee80211_crypto_deinit(void) +{ + struct list_head *ptr, *n; + + if (hcrypt == NULL) + return; + + for (ptr = hcrypt->algs.next, n = ptr->next; ptr != &hcrypt->algs; + ptr = n, n = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + list_del(ptr); + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s' (deinit)\n", alg->ops->name); + kfree(alg); + } + + kfree(hcrypt); +} + +EXPORT_SYMBOL(ieee80211_crypt_deinit_entries); +EXPORT_SYMBOL(ieee80211_crypt_deinit_handler); +EXPORT_SYMBOL(ieee80211_crypt_delayed_deinit); + +EXPORT_SYMBOL(ieee80211_register_crypto_ops); +EXPORT_SYMBOL(ieee80211_unregister_crypto_ops); +EXPORT_SYMBOL(ieee80211_get_crypto_ops); + +module_init(ieee80211_crypto_init); +module_exit(ieee80211_crypto_deinit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,477 @@ +/* + * Host AP crypt: host-based CCMP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif + +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: CCMP"); +MODULE_LICENSE("GPL"); + +#define AES_BLOCK_LEN 16 +#define CCMP_HDR_LEN 8 +#define CCMP_MIC_LEN 8 +#define CCMP_TK_LEN 16 +#define CCMP_PN_LEN 6 + +struct ieee80211_ccmp_data { + u8 key[CCMP_TK_LEN]; + int key_set; + + u8 tx_pn[CCMP_PN_LEN]; + u8 rx_pn[CCMP_PN_LEN]; + + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; + + int key_idx; + + struct crypto_tfm *tfm; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN], + tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN]; + u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN]; +}; + +void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm, + const u8 pt[16], u8 ct[16]) +{ + struct scatterlist src, dst; + + src.page = virt_to_page(pt); + src.offset = offset_in_page(pt); + src.length = AES_BLOCK_LEN; + + dst.page = virt_to_page(ct); + dst.offset = offset_in_page(ct); + dst.length = AES_BLOCK_LEN; + + crypto_cipher_encrypt(tfm, &dst, &src, AES_BLOCK_LEN); +} + +static void * ieee80211_ccmp_init(int key_idx) +{ + struct ieee80211_ccmp_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) { + goto fail; + } + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm = crypto_alloc_tfm("aes", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_ccmp: could not allocate " + "crypto API aes\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_ccmp_deinit(void *priv) +{ + struct ieee80211_ccmp_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +static inline void xor_block(u8 *b, u8 *a, size_t len) +{ + int i; + for (i = 0; i < len; i++) + b[i] ^= a[i]; +} + + +static void ccmp_init_blocks(struct crypto_tfm *tfm, + struct ieee80211_hdr *hdr, + u8 *pn, size_t dlen, u8 *b0, u8 *auth, + u8 *s0) +{ + u8 *pos, qc = 0; + size_t aad_len; + u16 fc; + int a4_included, qc_included; + u8 aad[2 * AES_BLOCK_LEN]; + + fc = le16_to_cpu(hdr->frame_ctl); + a4_included = ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)); + qc_included = ((WLAN_FC_GET_TYPE(fc) == IEEE80211_FTYPE_DATA) && + (WLAN_FC_GET_STYPE(fc) & 0x08)); + aad_len = 22; + if (a4_included) + aad_len += 6; + if (qc_included) { + pos = (u8 *) &hdr->addr4; + if (a4_included) + pos += 6; + qc = *pos & 0x0f; + aad_len += 2; + } + + /* CCM Initial Block: + * Flag (Include authentication header, M=3 (8-octet MIC), + * L=1 (2-octet Dlen)) + * Nonce: 0x00 | A2 | PN + * Dlen */ + b0[0] = 0x59; + b0[1] = qc; + memcpy(b0 + 2, hdr->addr2, ETH_ALEN); + memcpy(b0 + 8, pn, CCMP_PN_LEN); + b0[14] = (dlen >> 8) & 0xff; + b0[15] = dlen & 0xff; + + /* AAD: + * FC with bits 4..6 and 11..13 masked to zero; 14 is always one + * A1 | A2 | A3 + * SC with bits 4..15 (seq#) masked to zero + * A4 (if present) + * QC (if present) + */ + pos = (u8 *) hdr; + aad[0] = 0; /* aad_len >> 8 */ + aad[1] = aad_len & 0xff; + aad[2] = pos[0] & 0x8f; + aad[3] = pos[1] & 0xc7; + memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN); + pos = (u8 *) &hdr->seq_ctl; + aad[22] = pos[0] & 0x0f; + aad[23] = 0; /* all bits masked */ + memset(aad + 24, 0, 8); + if (a4_included) + memcpy(aad + 24, hdr->addr4, ETH_ALEN); + if (qc_included) { + aad[a4_included ? 30 : 24] = qc; + /* rest of QC masked */ + } + + /* Start with the first block and AAD */ + ieee80211_ccmp_aes_encrypt(tfm, b0, auth); + xor_block(auth, aad, AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + b0[0] &= 0x07; + b0[14] = b0[15] = 0; + ieee80211_ccmp_aes_encrypt(tfm, b0, s0); +} + + +static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + int data_len, i, blocks, last, len; + u8 *pos, *mic; + struct ieee80211_hdr *hdr; + u8 *b0 = key->tx_b0; + u8 *b = key->tx_b; + u8 *e = key->tx_e; + u8 *s0 = key->tx_s0; + + if (skb_headroom(skb) < CCMP_HDR_LEN || + skb_tailroom(skb) < CCMP_MIC_LEN || + skb->len < hdr_len) + return -1; + + data_len = skb->len - hdr_len; + pos = skb_push(skb, CCMP_HDR_LEN); + memmove(pos, pos + CCMP_HDR_LEN, hdr_len); + pos += hdr_len; + mic = skb_put(skb, CCMP_MIC_LEN); + + i = CCMP_PN_LEN - 1; + while (i >= 0) { + key->tx_pn[i]++; + if (key->tx_pn[i] != 0) + break; + i--; + } + + *pos++ = key->tx_pn[5]; + *pos++ = key->tx_pn[4]; + *pos++ = 0; + *pos++ = (key->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = key->tx_pn[3]; + *pos++ = key->tx_pn[2]; + *pos++ = key->tx_pn[1]; + *pos++ = key->tx_pn[0]; + + hdr = (struct ieee80211_hdr *) skb->data; + ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Authentication */ + xor_block(b, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, b, b); + /* Encryption, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, e); + xor_block(pos, e, len); + pos += len; + } + + for (i = 0; i < CCMP_MIC_LEN; i++) + mic[i] = b[i] ^ s0[i]; + + return 0; +} + + +static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + u8 keyidx, *pos; + struct ieee80211_hdr *hdr; + u8 *b0 = key->rx_b0; + u8 *b = key->rx_b; + u8 *a = key->rx_a; + u8 pn[6]; + int i, blocks, last, len; + size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN; + u8 *mic = skb->data + skb->len - CCMP_MIC_LEN; + + if (skb->len < hdr_len + CCMP_HDR_LEN + CCMP_MIC_LEN) { + key->dot11RSNAStatsCCMPFormatErrors++; + return -1; + } + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPFormatErrors++; + return -2; + } + keyidx >>= 6; + if (key->key_idx != keyidx) { + printk(KERN_DEBUG "CCMP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", key->key_idx, keyidx, priv); + return -6; + } + if (!key->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + + pn[0] = pos[7]; + pn[1] = pos[6]; + pn[2] = pos[5]; + pn[3] = pos[4]; + pn[4] = pos[1]; + pn[5] = pos[0]; + pos += 8; + + if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT + " previous PN %02x%02x%02x%02x%02x%02x " + "received PN %02x%02x%02x%02x%02x%02x\n", + MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn), + MAC_ARG(pn)); + } + key->dot11RSNAStatsCCMPReplays++; + return -4; + } + + ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b); + xor_block(mic, b, CCMP_MIC_LEN); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Decrypt, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, b); + xor_block(pos, b, len); + /* Authentication */ + xor_block(a, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, a, a); + pos += len; + } + + if (memcmp(mic, a, CCMP_MIC_LEN) != 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: decrypt failed: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPDecryptErrors++; + return -5; + } + + memcpy(key->rx_pn, pn, CCMP_PN_LEN); + + /* Remove hdr and MIC */ + memmove(skb->data + CCMP_HDR_LEN, skb->data, hdr_len); + skb_pull(skb, CCMP_HDR_LEN); + skb_trim(skb, skb->len - CCMP_MIC_LEN); + + return keyidx; +} + + +static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + int keyidx; + struct crypto_tfm *tfm = data->tfm; + + keyidx = data->key_idx; + memset(data, 0, sizeof(*data)); + data->key_idx = keyidx; + data->tfm = tfm; + if (len == CCMP_TK_LEN) { + memcpy(data->key, key, CCMP_TK_LEN); + data->key_set = 1; + if (seq) { + data->rx_pn[0] = seq[5]; + data->rx_pn[1] = seq[4]; + data->rx_pn[2] = seq[3]; + data->rx_pn[3] = seq[2]; + data->rx_pn[4] = seq[1]; + data->rx_pn[5] = seq[0]; + } + crypto_cipher_setkey(data->tfm, data->key, CCMP_TK_LEN); + } else if (len == 0) { + data->key_set = 0; + } else + return -1; + + return 0; +} + + +static int ieee80211_ccmp_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + + if (len < CCMP_TK_LEN) + return -1; + + if (!data->key_set) + return 0; + memcpy(key, data->key, CCMP_TK_LEN); + + if (seq) { + seq[0] = data->tx_pn[5]; + seq[1] = data->tx_pn[4]; + seq[2] = data->tx_pn[3]; + seq[3] = data->tx_pn[2]; + seq[4] = data->tx_pn[1]; + seq[5] = data->tx_pn[0]; + } + + return CCMP_TK_LEN; +} + + +static char * ieee80211_ccmp_print_stats(char *p, void *priv) +{ + struct ieee80211_ccmp_data *ccmp = priv; + p += sprintf(p, "key[%d] alg=CCMP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "format_errors=%d replays=%d decrypt_errors=%d\n", + ccmp->key_idx, ccmp->key_set, + MAC_ARG(ccmp->tx_pn), MAC_ARG(ccmp->rx_pn), + ccmp->dot11RSNAStatsCCMPFormatErrors, + ccmp->dot11RSNAStatsCCMPReplays, + ccmp->dot11RSNAStatsCCMPDecryptErrors); + + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_ccmp = { + .name = "CCMP", + .init = ieee80211_ccmp_init, + .deinit = ieee80211_ccmp_deinit, + .encrypt_mpdu = ieee80211_ccmp_encrypt, + .decrypt_mpdu = ieee80211_ccmp_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = ieee80211_ccmp_set_key, + .get_key = ieee80211_ccmp_get_key, + .print_stats = ieee80211_ccmp_print_stats, + .extra_prefix_len = CCMP_HDR_LEN, + .extra_postfix_len = CCMP_MIC_LEN, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_ccmp_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_ccmp) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_ccmp_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_ccmp); +} + + +module_init(ieee80211_crypto_ccmp_init); +module_exit(ieee80211_crypto_ccmp_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,714 @@ +/* + * Host AP crypt: host-based TKIP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif + +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: TKIP"); +MODULE_LICENSE("GPL"); + +struct ieee80211_tkip_data { +#define TKIP_KEY_LEN 32 + u8 key[TKIP_KEY_LEN]; + int key_set; + + u32 tx_iv32; + u16 tx_iv16; + u16 tx_ttak[5]; + int tx_phase1_done; + + u32 rx_iv32; + u16 rx_iv16; + u16 rx_ttak[5]; + int rx_phase1_done; + u32 rx_iv32_new; + u16 rx_iv16_new; + + u32 dot11RSNAStatsTKIPReplays; + u32 dot11RSNAStatsTKIPICVErrors; + u32 dot11RSNAStatsTKIPLocalMICFailures; + + int key_idx; + + struct crypto_tfm *tfm_arc4; + struct crypto_tfm *tfm_michael; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 rx_hdr[16], tx_hdr[16]; +}; + +static void * ieee80211_tkip_init(int key_idx) +{ + struct ieee80211_tkip_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm_arc4 = crypto_alloc_tfm("arc4", 0); + if (priv->tfm_arc4 == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + priv->tfm_michael = crypto_alloc_tfm("michael_mic", 0); + if (priv->tfm_michael == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API michael_mic\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm_michael) + crypto_free_tfm(priv->tfm_michael); + if (priv->tfm_arc4) + crypto_free_tfm(priv->tfm_arc4); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_tkip_deinit(void *priv) +{ + struct ieee80211_tkip_data *_priv = priv; + if (_priv && _priv->tfm_michael) + crypto_free_tfm(_priv->tfm_michael); + if (_priv && _priv->tfm_arc4) + crypto_free_tfm(_priv->tfm_arc4); + kfree(priv); +} + + +static inline u16 RotR1(u16 val) +{ + return (val >> 1) | (val << 15); +} + + +static inline u8 Lo8(u16 val) +{ + return val & 0xff; +} + + +static inline u8 Hi8(u16 val) +{ + return val >> 8; +} + + +static inline u16 Lo16(u32 val) +{ + return val & 0xffff; +} + + +static inline u16 Hi16(u32 val) +{ + return val >> 16; +} + + +static inline u16 Mk16(u8 hi, u8 lo) +{ + return lo | (((u16) hi) << 8); +} + + +static inline u16 Mk16_le(u16 *v) +{ + return le16_to_cpu(*v); +} + + +static const u16 Sbox[256] = +{ + 0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154, + 0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A, + 0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B, + 0x41EC, 0xB367, 0x5FFD, 0x45EA, 0x23BF, 0x53F7, 0xE496, 0x9B5B, + 0x75C2, 0xE11C, 0x3DAE, 0x4C6A, 0x6C5A, 0x7E41, 0xF502, 0x834F, + 0x685C, 0x51F4, 0xD134, 0xF908, 0xE293, 0xAB73, 0x6253, 0x2A3F, + 0x080C, 0x9552, 0x4665, 0x9D5E, 0x3028, 0x37A1, 0x0A0F, 0x2FB5, + 0x0E09, 0x2436, 0x1B9B, 0xDF3D, 0xCD26, 0x4E69, 0x7FCD, 0xEA9F, + 0x121B, 0x1D9E, 0x5874, 0x342E, 0x362D, 0xDCB2, 0xB4EE, 0x5BFB, + 0xA4F6, 0x764D, 0xB761, 0x7DCE, 0x527B, 0xDD3E, 0x5E71, 0x1397, + 0xA6F5, 0xB968, 0x0000, 0xC12C, 0x4060, 0xE31F, 0x79C8, 0xB6ED, + 0xD4BE, 0x8D46, 0x67D9, 0x724B, 0x94DE, 0x98D4, 0xB0E8, 0x854A, + 0xBB6B, 0xC52A, 0x4FE5, 0xED16, 0x86C5, 0x9AD7, 0x6655, 0x1194, + 0x8ACF, 0xE910, 0x0406, 0xFE81, 0xA0F0, 0x7844, 0x25BA, 0x4BE3, + 0xA2F3, 0x5DFE, 0x80C0, 0x058A, 0x3FAD, 0x21BC, 0x7048, 0xF104, + 0x63DF, 0x77C1, 0xAF75, 0x4263, 0x2030, 0xE51A, 0xFD0E, 0xBF6D, + 0x814C, 0x1814, 0x2635, 0xC32F, 0xBEE1, 0x35A2, 0x88CC, 0x2E39, + 0x9357, 0x55F2, 0xFC82, 0x7A47, 0xC8AC, 0xBAE7, 0x322B, 0xE695, + 0xC0A0, 0x1998, 0x9ED1, 0xA37F, 0x4466, 0x547E, 0x3BAB, 0x0B83, + 0x8CCA, 0xC729, 0x6BD3, 0x283C, 0xA779, 0xBCE2, 0x161D, 0xAD76, + 0xDB3B, 0x6456, 0x744E, 0x141E, 0x92DB, 0x0C0A, 0x486C, 0xB8E4, + 0x9F5D, 0xBD6E, 0x43EF, 0xC4A6, 0x39A8, 0x31A4, 0xD337, 0xF28B, + 0xD532, 0x8B43, 0x6E59, 0xDAB7, 0x018C, 0xB164, 0x9CD2, 0x49E0, + 0xD8B4, 0xACFA, 0xF307, 0xCF25, 0xCAAF, 0xF48E, 0x47E9, 0x1018, + 0x6FD5, 0xF088, 0x4A6F, 0x5C72, 0x3824, 0x57F1, 0x73C7, 0x9751, + 0xCB23, 0xA17C, 0xE89C, 0x3E21, 0x96DD, 0x61DC, 0x0D86, 0x0F85, + 0xE090, 0x7C42, 0x71C4, 0xCCAA, 0x90D8, 0x0605, 0xF701, 0x1C12, + 0xC2A3, 0x6A5F, 0xAEF9, 0x69D0, 0x1791, 0x9958, 0x3A27, 0x27B9, + 0xD938, 0xEB13, 0x2BB3, 0x2233, 0xD2BB, 0xA970, 0x0789, 0x33A7, + 0x2DB6, 0x3C22, 0x1592, 0xC920, 0x8749, 0xAAFF, 0x5078, 0xA57A, + 0x038F, 0x59F8, 0x0980, 0x1A17, 0x65DA, 0xD731, 0x84C6, 0xD0B8, + 0x82C3, 0x29B0, 0x5A77, 0x1E11, 0x7BCB, 0xA8FC, 0x6DD6, 0x2C3A, +}; + + +static inline u16 _S_(u16 v) +{ + u16 t = Sbox[Hi8(v)]; + return Sbox[Lo8(v)] ^ ((t << 8) | (t >> 8)); +} + + +#define PHASE1_LOOP_COUNT 8 + +static void tkip_mixing_phase1(u16 *TTAK, const u8 *TK, const u8 *TA, u32 IV32) +{ + int i, j; + + /* Initialize the 80-bit TTAK from TSC (IV32) and TA[0..5] */ + TTAK[0] = Lo16(IV32); + TTAK[1] = Hi16(IV32); + TTAK[2] = Mk16(TA[1], TA[0]); + TTAK[3] = Mk16(TA[3], TA[2]); + TTAK[4] = Mk16(TA[5], TA[4]); + + for (i = 0; i < PHASE1_LOOP_COUNT; i++) { + j = 2 * (i & 1); + TTAK[0] += _S_(TTAK[4] ^ Mk16(TK[1 + j], TK[0 + j])); + TTAK[1] += _S_(TTAK[0] ^ Mk16(TK[5 + j], TK[4 + j])); + TTAK[2] += _S_(TTAK[1] ^ Mk16(TK[9 + j], TK[8 + j])); + TTAK[3] += _S_(TTAK[2] ^ Mk16(TK[13 + j], TK[12 + j])); + TTAK[4] += _S_(TTAK[3] ^ Mk16(TK[1 + j], TK[0 + j])) + i; + } +} + + +static void tkip_mixing_phase2(u8 *WEPSeed, const u8 *TK, const u16 *TTAK, + u16 IV16) +{ + /* Make temporary area overlap WEP seed so that the final copy can be + * avoided on little endian hosts. */ + u16 *PPK = (u16 *) &WEPSeed[4]; + + /* Step 1 - make copy of TTAK and bring in TSC */ + PPK[0] = TTAK[0]; + PPK[1] = TTAK[1]; + PPK[2] = TTAK[2]; + PPK[3] = TTAK[3]; + PPK[4] = TTAK[4]; + PPK[5] = TTAK[4] + IV16; + + /* Step 2 - 96-bit bijective mixing using S-box */ + PPK[0] += _S_(PPK[5] ^ Mk16_le((u16 *) &TK[0])); + PPK[1] += _S_(PPK[0] ^ Mk16_le((u16 *) &TK[2])); + PPK[2] += _S_(PPK[1] ^ Mk16_le((u16 *) &TK[4])); + PPK[3] += _S_(PPK[2] ^ Mk16_le((u16 *) &TK[6])); + PPK[4] += _S_(PPK[3] ^ Mk16_le((u16 *) &TK[8])); + PPK[5] += _S_(PPK[4] ^ Mk16_le((u16 *) &TK[10])); + + PPK[0] += RotR1(PPK[5] ^ Mk16_le((u16 *) &TK[12])); + PPK[1] += RotR1(PPK[0] ^ Mk16_le((u16 *) &TK[14])); + PPK[2] += RotR1(PPK[1]); + PPK[3] += RotR1(PPK[2]); + PPK[4] += RotR1(PPK[3]); + PPK[5] += RotR1(PPK[4]); + + /* Step 3 - bring in last of TK bits, assign 24-bit WEP IV value + * WEPSeed[0..2] is transmitted as WEP IV */ + WEPSeed[0] = Hi8(IV16); + WEPSeed[1] = (Hi8(IV16) | 0x20) & 0x7F; + WEPSeed[2] = Lo8(IV16); + WEPSeed[3] = Lo8((PPK[5] ^ Mk16_le((u16 *) &TK[0])) >> 1); + +#ifdef __BIG_ENDIAN + { + int i; + for (i = 0; i < 6; i++) + PPK[i] = (PPK[i] << 8) | (PPK[i] >> 8); + } +#endif +} + +static int ieee80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int len; + u8 rc4key[16], *pos, *icv; + struct ieee80211_hdr *hdr; + u32 crc; + struct scatterlist sg; + + if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + if (!tkey->tx_phase1_done) { + tkip_mixing_phase1(tkey->tx_ttak, tkey->key, hdr->addr2, + tkey->tx_iv32); + tkey->tx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, tkey->tx_iv16); + + len = skb->len - hdr_len; + pos = skb_push(skb, 8); + memmove(pos, pos + 8, hdr_len); + pos += hdr_len; + icv = skb_put(skb, 4); + + *pos++ = rc4key[0]; + *pos++ = rc4key[1]; + *pos++ = rc4key[2]; + *pos++ = (tkey->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = tkey->tx_iv32 & 0xff; + *pos++ = (tkey->tx_iv32 >> 8) & 0xff; + *pos++ = (tkey->tx_iv32 >> 16) & 0xff; + *pos++ = (tkey->tx_iv32 >> 24) & 0xff; + + crc = ~crc32_le(~0, pos, len); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(tkey->tfm_arc4, &sg, &sg, len + 4); + + tkey->tx_iv16++; + if (tkey->tx_iv16 == 0) { + tkey->tx_phase1_done = 0; + tkey->tx_iv32++; + } + + return 0; +} + +static int ieee80211_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 rc4key[16]; + u8 keyidx, *pos; + u32 iv32; + u16 iv16; + struct ieee80211_hdr *hdr; + u8 icv[4]; + u32 crc; + struct scatterlist sg; + int plen; + + if (skb->len < hdr_len + 8 + 4) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + return -2; + } + keyidx >>= 6; + if (tkey->key_idx != keyidx) { + printk(KERN_DEBUG "TKIP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", tkey->key_idx, keyidx, priv); + return -6; + } + if (!tkey->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + iv16 = (pos[0] << 8) | pos[2]; + iv32 = pos[4] | (pos[5] << 8) | (pos[6] << 16) | (pos[7] << 24); + pos += 8; + + if (iv32 < tkey->rx_iv32 || + (iv32 == tkey->rx_iv32 && iv16 <= tkey->rx_iv16)) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: replay detected: STA=" MAC_FMT + " previous TSC %08x%04x received TSC " + "%08x%04x\n", MAC_ARG(hdr->addr2), + tkey->rx_iv32, tkey->rx_iv16, iv32, iv16); + } + tkey->dot11RSNAStatsTKIPReplays++; + return -4; + } + + if (iv32 != tkey->rx_iv32 || !tkey->rx_phase1_done) { + tkip_mixing_phase1(tkey->rx_ttak, tkey->key, hdr->addr2, iv32); + tkey->rx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->rx_ttak, iv16); + + plen = skb->len - hdr_len - 12; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(tkey->tfm_arc4, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + if (iv32 != tkey->rx_iv32) { + /* Previously cached Phase1 result was already lost, so + * it needs to be recalculated for the next packet. */ + tkey->rx_phase1_done = 0; + } + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: ICV error detected: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + tkey->dot11RSNAStatsTKIPICVErrors++; + return -5; + } + + /* Update real counters only after Michael MIC verification has + * completed */ + tkey->rx_iv32_new = iv32; + tkey->rx_iv16_new = iv16; + + /* Remove IV and ICV */ + memmove(skb->data + 8, skb->data, hdr_len); + skb_pull(skb, 8); + skb_trim(skb, skb->len - 4); + + return keyidx; +} + + +static int michael_mic(struct ieee80211_tkip_data *tkey, u8 *key, u8 *hdr, + u8 *data, size_t data_len, u8 *mic) +{ + struct scatterlist sg[2]; + + if (tkey->tfm_michael == NULL) { + printk(KERN_WARNING "michael_mic: tfm_michael == NULL\n"); + return -1; + } + sg[0].page = virt_to_page(hdr); + sg[0].offset = offset_in_page(hdr); + sg[0].length = 16; + + sg[1].page = virt_to_page(data); + sg[1].offset = offset_in_page(data); + sg[1].length = data_len; + + crypto_digest_init(tkey->tfm_michael); + crypto_digest_setkey(tkey->tfm_michael, key, 8); + crypto_digest_update(tkey->tfm_michael, sg, 2); + crypto_digest_final(tkey->tfm_michael, mic); + + return 0; +} + +static void michael_mic_hdr(struct sk_buff *skb, u8 *hdr) +{ + struct ieee80211_hdr *hdr11; + + hdr11 = (struct ieee80211_hdr *) skb->data; + switch (le16_to_cpu(hdr11->frame_ctl) & + (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr3, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */ + break; + case 0: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + } + + hdr[12] = 0; /* priority */ + hdr[13] = hdr[14] = hdr[15] = 0; /* reserved */ +} + + +static int ieee80211_michael_mic_add(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 *pos; + + if (skb_tailroom(skb) < 8 || skb->len < hdr_len) { + printk(KERN_DEBUG "Invalid packet for Michael MIC add " + "(tailroom=%d hdr_len=%d skb->len=%d)\n", + skb_tailroom(skb), hdr_len, skb->len); + return -1; + } + + michael_mic_hdr(skb, tkey->tx_hdr); + pos = skb_put(skb, 8); + if (michael_mic(tkey, &tkey->key[16], tkey->tx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, pos)) + return -1; + + return 0; +} + + +#if WIRELESS_EXT >= 18 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + struct iw_michaelmicfailure ev; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + memset(&ev, 0, sizeof(ev)); + ev.flags = keyidx & IW_MICFAILURE_KEY_ID; + if (hdr->addr1[0] & 0x01) + ev.flags |= IW_MICFAILURE_GROUP; + else + ev.flags |= IW_MICFAILURE_PAIRWISE; + ev.src_addr.sa_family = ARPHRD_ETHER; + memcpy(ev.src_addr.sa_data, hdr->addr2, ETH_ALEN); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = sizeof(ev); + wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *) &ev); +} +#elif WIRELESS_EXT >= 15 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + char buf[128]; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + sprintf(buf, "MLME-MICHAELMICFAILURE.indication(keyid=%d %scast addr=" + MAC_FMT ")", keyidx, hdr->addr1[0] & 0x01 ? "broad" : "uni", + MAC_ARG(hdr->addr2)); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = strlen(buf); + wireless_send_event(dev, IWEVCUSTOM, &wrqu, buf); +} +#else /* WIRELESS_EXT >= 15 */ +static inline void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ +} +#endif /* WIRELESS_EXT >= 15 */ + + +static int ieee80211_michael_mic_verify(struct sk_buff *skb, int keyidx, + int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 mic[8]; + + if (!tkey->key_set) + return -1; + + michael_mic_hdr(skb, tkey->rx_hdr); + if (michael_mic(tkey, &tkey->key[24], tkey->rx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, mic)) + return -1; + if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) { + struct ieee80211_hdr *hdr; + hdr = (struct ieee80211_hdr *) skb->data; + printk(KERN_DEBUG "%s: Michael MIC verification failed for " + "MSDU from " MAC_FMT " keyidx=%d\n", + skb->dev ? skb->dev->name : "N/A", MAC_ARG(hdr->addr2), + keyidx); + if (skb->dev) + ieee80211_michael_mic_failure(skb->dev, hdr, keyidx); + tkey->dot11RSNAStatsTKIPLocalMICFailures++; + return -1; + } + + /* Update TSC counters for RX now that the packet verification has + * completed. */ + tkey->rx_iv32 = tkey->rx_iv32_new; + tkey->rx_iv16 = tkey->rx_iv16_new; + + skb_trim(skb, skb->len - 8); + + return 0; +} + + +static int ieee80211_tkip_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int keyidx; + struct crypto_tfm *tfm = tkey->tfm_michael; + struct crypto_tfm *tfm2 = tkey->tfm_arc4; + + keyidx = tkey->key_idx; + memset(tkey, 0, sizeof(*tkey)); + tkey->key_idx = keyidx; + tkey->tfm_michael = tfm; + tkey->tfm_arc4 = tfm2; + if (len == TKIP_KEY_LEN) { + memcpy(tkey->key, key, TKIP_KEY_LEN); + tkey->key_set = 1; + tkey->tx_iv16 = 1; /* TSC is initialized to 1 */ + if (seq) { + tkey->rx_iv32 = (seq[5] << 24) | (seq[4] << 16) | + (seq[3] << 8) | seq[2]; + tkey->rx_iv16 = (seq[1] << 8) | seq[0]; + } + } else if (len == 0) { + tkey->key_set = 0; + } else + return -1; + + return 0; +} + + +static int ieee80211_tkip_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + + if (len < TKIP_KEY_LEN) + return -1; + + if (!tkey->key_set) + return 0; + memcpy(key, tkey->key, TKIP_KEY_LEN); + + if (seq) { + /* Return the sequence number of the last transmitted frame. */ + u16 iv16 = tkey->tx_iv16; + u32 iv32 = tkey->tx_iv32; + if (iv16 == 0) + iv32--; + iv16--; + seq[0] = tkey->tx_iv16; + seq[1] = tkey->tx_iv16 >> 8; + seq[2] = tkey->tx_iv32; + seq[3] = tkey->tx_iv32 >> 8; + seq[4] = tkey->tx_iv32 >> 16; + seq[5] = tkey->tx_iv32 >> 24; + } + + return TKIP_KEY_LEN; +} + + +static char * ieee80211_tkip_print_stats(char *p, void *priv) +{ + struct ieee80211_tkip_data *tkip = priv; + p += sprintf(p, "key[%d] alg=TKIP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "replays=%d icv_errors=%d local_mic_failures=%d\n", + tkip->key_idx, tkip->key_set, + (tkip->tx_iv32 >> 24) & 0xff, + (tkip->tx_iv32 >> 16) & 0xff, + (tkip->tx_iv32 >> 8) & 0xff, + tkip->tx_iv32 & 0xff, + (tkip->tx_iv16 >> 8) & 0xff, + tkip->tx_iv16 & 0xff, + (tkip->rx_iv32 >> 24) & 0xff, + (tkip->rx_iv32 >> 16) & 0xff, + (tkip->rx_iv32 >> 8) & 0xff, + tkip->rx_iv32 & 0xff, + (tkip->rx_iv16 >> 8) & 0xff, + tkip->rx_iv16 & 0xff, + tkip->dot11RSNAStatsTKIPReplays, + tkip->dot11RSNAStatsTKIPICVErrors, + tkip->dot11RSNAStatsTKIPLocalMICFailures); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_tkip = { + .name = "TKIP", + .init = ieee80211_tkip_init, + .deinit = ieee80211_tkip_deinit, + .encrypt_mpdu = ieee80211_tkip_encrypt, + .decrypt_mpdu = ieee80211_tkip_decrypt, + .encrypt_msdu = ieee80211_michael_mic_add, + .decrypt_msdu = ieee80211_michael_mic_verify, + .set_key = ieee80211_tkip_set_key, + .get_key = ieee80211_tkip_get_key, + .print_stats = ieee80211_tkip_print_stats, + .extra_prefix_len = 4 + 4, /* IV + ExtIV */ + .extra_postfix_len = 8 + 4, /* MIC + ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_tkip_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_tkip) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_tkip_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_tkip); +} + + +module_init(ieee80211_crypto_tkip_init); +module_exit(ieee80211_crypto_tkip_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,277 @@ +/* + * Host AP crypt: host-based WEP encryption implementation for Host AP driver + * + * Copyright (c) 2002-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: WEP"); +MODULE_LICENSE("GPL"); + + +struct prism2_wep_data { + u32 iv; +#define WEP_KEY_LEN 13 + u8 key[WEP_KEY_LEN + 1]; + u8 key_len; + u8 key_idx; + struct crypto_tfm *tfm; +}; + + +static void * prism2_wep_init(int keyidx) +{ + struct prism2_wep_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = keyidx; + + priv->tfm = crypto_alloc_tfm("arc4", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + /* start WEP IV from a random value */ + get_random_bytes(&priv->iv, 4); + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + return NULL; +} + + +static void prism2_wep_deinit(void *priv) +{ + struct prism2_wep_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +/* Perform WEP encryption on given skb that has at least 4 bytes of headroom + * for IV and 4 bytes of tailroom for ICV. Both IV and ICV will be transmitted, + * so the payload length increases with 8 bytes. + * + * WEP frame payload: IV + TX key idx, RC4(data), ICV = RC4(CRC32(data)) + */ +static int prism2_wep_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, len; + u8 key[WEP_KEY_LEN + 3]; + u8 *pos, *icv; + struct scatterlist sg; + + if (skb_headroom(skb) < 4 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + len = skb->len - hdr_len; + pos = skb_push(skb, 4); + memmove(pos, pos + 4, hdr_len); + pos += hdr_len; + + klen = 3 + wep->key_len; + + wep->iv++; + + /* Fluhrer, Mantin, and Shamir have reported weaknesses in the key + * scheduling algorithm of RC4. At least IVs (KeyByte + 3, 0xff, N) + * can be used to speedup attacks, so avoid using them. */ + if ((wep->iv & 0xff00) == 0xff00) { + u8 B = (wep->iv >> 16) & 0xff; + if (B >= 3 && B < klen) + wep->iv += 0x0100; + } + + /* Prepend 24-bit IV to RC4 key and TX frame */ + *pos++ = key[0] = (wep->iv >> 16) & 0xff; + *pos++ = key[1] = (wep->iv >> 8) & 0xff; + *pos++ = key[2] = wep->iv & 0xff; + *pos++ = wep->key_idx << 6; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Append little-endian CRC32 and encrypt it to produce ICV */ + crc = ~crc32_le(~0, pos, len); + icv = skb_put(skb, 4); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(wep->tfm, &sg, &sg, len + 4); + + return 0; +} + + +/* Perform WEP decryption on given buffer. Buffer includes whole WEP part of + * the frame: IV (4 bytes), encrypted payload (including SNAP header), + * ICV (4 bytes). len includes both IV and ICV. + * + * Returns 0 if frame was decrypted successfully and ICV was correct and -1 on + * failure. If frame is OK, IV and ICV will be removed. + */ +static int prism2_wep_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, plen; + u8 key[WEP_KEY_LEN + 3]; + u8 keyidx, *pos, icv[4]; + struct scatterlist sg; + + if (skb->len < hdr_len + 8) + return -1; + + pos = skb->data + hdr_len; + key[0] = *pos++; + key[1] = *pos++; + key[2] = *pos++; + keyidx = *pos++ >> 6; + if (keyidx != wep->key_idx) + return -1; + + klen = 3 + wep->key_len; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Apply RC4 to data and compute CRC32 over decrypted data */ + plen = skb->len - hdr_len - 8; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(wep->tfm, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + /* ICV mismatch - drop frame */ + return -2; + } + + /* Remove IV and ICV */ + memmove(skb->data + 4, skb->data, hdr_len); + skb_pull(skb, 4); + skb_trim(skb, skb->len - 4); + + return 0; +} + + +static int prism2_wep_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < 0 || len > WEP_KEY_LEN) + return -1; + + memcpy(wep->key, key, len); + wep->key_len = len; + + return 0; +} + + +static int prism2_wep_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < wep->key_len) + return -1; + + memcpy(key, wep->key, wep->key_len); + + return wep->key_len; +} + + +static char * prism2_wep_print_stats(char *p, void *priv) +{ + struct prism2_wep_data *wep = priv; + p += sprintf(p, "key[%d] alg=WEP len=%d\n", + wep->key_idx, wep->key_len); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_wep = { + .name = "WEP", + .init = prism2_wep_init, + .deinit = prism2_wep_deinit, + .encrypt_mpdu = prism2_wep_encrypt, + .decrypt_mpdu = prism2_wep_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = prism2_wep_set_key, + .get_key = prism2_wep_get_key, + .print_stats = prism2_wep_print_stats, + .extra_prefix_len = 4, /* IV */ + .extra_postfix_len = 4, /* ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_wep_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_wep) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_wep_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_wep); +} + + +module_init(ieee80211_crypto_wep_init); +module_exit(ieee80211_crypto_wep_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_rx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_rx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_rx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_rx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,1215 @@ +/* + * Original code based Host AP (software wireless LAN access point) driver + * for Intersil Prism2/2.5/3 - hostap.o module, common routines + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ieee80211.h" + +static inline void ieee80211_monitor_rx(struct ieee80211_device *ieee, + struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + u16 fc = le16_to_cpu(hdr->frame_ctl); + + skb->dev = ieee->dev; + skb->mac.raw = skb->data; + skb_pull(skb, ieee80211_get_hdrlen(fc)); + skb->pkt_type = PACKET_OTHERHOST; + skb->protocol = __constant_htons(ETH_P_80211_RAW); + memset(skb->cb, 0, sizeof(skb->cb)); + netif_rx(skb); +} + + +/* Called only as a tasklet (software IRQ) */ +static struct ieee80211_frag_entry * +ieee80211_frag_cache_find(struct ieee80211_device *ieee, unsigned int seq, + unsigned int frag, u8 *src, u8 *dst) +{ + struct ieee80211_frag_entry *entry; + int i; + + for (i = 0; i < IEEE80211_FRAG_CACHE_LEN; i++) { + entry = &ieee->frag_cache[i]; + if (entry->skb != NULL && + time_after(jiffies, entry->first_frag_time + 2 * HZ)) { + IEEE80211_DEBUG_FRAG( + "expiring fragment cache entry " + "seq=%u last_frag=%u\n", + entry->seq, entry->last_frag); + dev_kfree_skb_any(entry->skb); + entry->skb = NULL; + } + + if (entry->skb != NULL && entry->seq == seq && + (entry->last_frag + 1 == frag || frag == -1) && + memcmp(entry->src_addr, src, ETH_ALEN) == 0 && + memcmp(entry->dst_addr, dst, ETH_ALEN) == 0) + return entry; + } + + return NULL; +} + +/* Called only as a tasklet (software IRQ) */ +static struct sk_buff * +ieee80211_frag_cache_get(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + struct sk_buff *skb = NULL; + u16 sc; + unsigned int frag, seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + seq = WLAN_GET_SEQ_SEQ(sc); + + if (frag == 0) { + /* Reserve enough space to fit maximum frame length */ + skb = dev_alloc_skb(ieee->dev->mtu + + sizeof(struct ieee80211_hdr) + + 8 /* LLC */ + + 2 /* alignment */ + + 8 /* WEP */ + ETH_ALEN /* WDS */); + if (skb == NULL) + return NULL; + + entry = &ieee->frag_cache[ieee->frag_next_idx]; + ieee->frag_next_idx++; + if (ieee->frag_next_idx >= IEEE80211_FRAG_CACHE_LEN) + ieee->frag_next_idx = 0; + + if (entry->skb != NULL) + dev_kfree_skb_any(entry->skb); + + entry->first_frag_time = jiffies; + entry->seq = seq; + entry->last_frag = frag; + entry->skb = skb; + memcpy(entry->src_addr, hdr->addr2, ETH_ALEN); + memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN); + } else { + /* received a fragment of a frame for which the head fragment + * should have already been received */ + entry = ieee80211_frag_cache_find(ieee, seq, frag, hdr->addr2, + hdr->addr1); + if (entry != NULL) { + entry->last_frag = frag; + skb = entry->skb; + } + } + + return skb; +} + + +/* Called only as a tasklet (software IRQ) */ +static int ieee80211_frag_cache_invalidate(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + u16 sc; + unsigned int seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + seq = WLAN_GET_SEQ_SEQ(sc); + + entry = ieee80211_frag_cache_find(ieee, seq, -1, hdr->addr2, + hdr->addr1); + + if (entry == NULL) { + IEEE80211_DEBUG_FRAG( + "could not invalidate fragment cache " + "entry (seq=%u)\n", seq); + return -1; + } + + entry->skb = NULL; + return 0; +} + + +#ifdef NOT_YET +/* ieee80211_rx_frame_mgtmt + * + * Responsible for handling management control frames + * + * Called by ieee80211_rx */ +static inline int +ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats, u16 type, + u16 stype) +{ + if (ieee->iw_mode == IW_MODE_MASTER) { + printk(KERN_DEBUG "%s: Master mode not yet suppported.\n", + ieee->dev->name); + return 0; +/* + hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr *) + skb->data);*/ + } + + if (ieee->hostapd && type == WLAN_FC_TYPE_MGMT) { + if (stype == WLAN_FC_STYPE_BEACON && + ieee->iw_mode == IW_MODE_MASTER) { + struct sk_buff *skb2; + /* Process beacon frames also in kernel driver to + * update STA(AP) table statistics */ + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2) + hostap_rx(skb2->dev, skb2, rx_stats); + } + + /* send management frames to the user space daemon for + * processing */ + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT); + return 0; + } + + if (ieee->iw_mode == IW_MODE_MASTER) { + if (type != WLAN_FC_TYPE_MGMT && type != WLAN_FC_TYPE_CTRL) { + printk(KERN_DEBUG "%s: unknown management frame " + "(type=0x%02x, stype=0x%02x) dropped\n", + skb->dev->name, type, stype); + return -1; + } + + hostap_rx(skb->dev, skb, rx_stats); + return 0; + } + + printk(KERN_DEBUG "%s: hostap_rx_frame_mgmt: management frame " + "received in non-Host AP mode\n", skb->dev->name); + return -1; +} +#endif + + +/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */ +/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ +static unsigned char rfc1042_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 }; +/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */ +static unsigned char bridge_tunnel_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 }; +/* No encapsulation header if EtherType < 0x600 (=length) */ + +#ifdef CONFIG_IEEE80211_CRYPT +/* Called by ieee80211_rx_frame_decrypt */ +static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, + struct sk_buff *skb) +{ + struct net_device *dev = ieee->dev; + u16 fc, ethertype; + struct ieee80211_hdr *hdr; + u8 *pos; + + if (skb->len < 24) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + fc = le16_to_cpu(hdr->frame_ctl); + + /* check that the frame is unicast frame to us */ + if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 && + memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) { + /* ToDS frame with own addr BSSID and DA */ + } else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_FROMDS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) { + /* FromDS frame with own addr as DA */ + } else + return 0; + + if (skb->len < 24 + 8) + return 0; + + /* check for port access entity Ethernet type */ + pos = skb->data + 24; + ethertype = (pos[6] << 8) | pos[7]; + if (ethertype == ETH_P_PAE) + return 1; + + return 0; +} + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt(struct ieee80211_device* ieee, struct sk_buff *skb, + struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_mpdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + +#ifdef CONFIG_IEEE80211_WPA + if (ieee->tkip_countermeasures && + strcmp(crypt->ops->name, "TKIP") == 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "received packet from " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(hdr->addr2)); + } + return -1; + } +#endif + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_mpdu(skb, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + IEEE80211_DEBUG_DROP( + "decryption failed (SA=" MAC_FMT + ") res=%d\n", MAC_ARG(hdr->addr2), res); + if (res == -2) + IEEE80211_DEBUG_DROP("WEP decryption failed ICV " + "mismatch (key %d)\n", + skb->data[hdrlen + 3] >> 6); + ieee->ieee_stats.rx_discards_wep_undecryptable++; + return -1; + } + + return res; +} + + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt_msdu(struct ieee80211_device* ieee, struct sk_buff *skb, + int keyidx, struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_msdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed" + " (SA=" MAC_FMT " keyidx=%d)\n", + ieee->dev->name, MAC_ARG(hdr->addr2), keyidx); + return -1; + } + + return 0; +} +#endif /* CONFIG_IEEE80211_CRYPT */ + + +/* All received frames are sent to this function. @skb contains the frame in + * IEEE 802.11 format, i.e., in the format it was sent over air. + * This function is called only as a tasklet (software IRQ). */ +int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct net_device *dev = ieee->dev; + struct ieee80211_hdr *hdr; + size_t hdrlen; + u16 fc, type, stype, sc; + struct net_device_stats *stats; + unsigned int frag; + u8 *payload; + u16 ethertype; +#ifdef NOT_YET + struct net_device *wds = NULL; + struct sk_buff *skb2 = NULL; + struct net_device *wds = NULL; + int frame_authorized = 0; + int from_assoc_ap = 0; + void *sta = NULL; +#endif + u8 dst[ETH_ALEN]; + u8 src[ETH_ALEN]; +#ifdef CONFIG_IEEE80211_CRYPT + struct ieee80211_crypt_data *crypt = NULL; + int keyidx = 0; +#endif + + hdr = (struct ieee80211_hdr *)skb->data; + stats = &ieee->stats; + + if (skb->len < 10) { + printk(KERN_INFO "%s: SKB length < 10\n", + dev->name); + goto rx_dropped; + } + + fc = le16_to_cpu(hdr->frame_ctl); + type = WLAN_FC_GET_TYPE(fc); + stype = WLAN_FC_GET_STYPE(fc); + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + hdrlen = ieee80211_get_hdrlen(fc); + +#ifdef NOT_YET +#if WIRELESS_EXT > 15 + /* Put this code here so that we avoid duplicating it in all + * Rx paths. - Jean II */ +#ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */ + /* If spy monitoring on */ + if (iface->spy_data.spy_number > 0) { + struct iw_quality wstats; + wstats.level = rx_stats->signal; + wstats.noise = rx_stats->noise; + wstats.updated = 6; /* No qual value */ + /* Update spy records */ + wireless_spy_update(dev, hdr->addr2, &wstats); + } +#endif /* IW_WIRELESS_SPY */ +#endif /* WIRELESS_EXT > 15 */ + hostap_update_rx_stats(local->ap, hdr, rx_stats); +#endif + +#if WIRELESS_EXT > 15 + if (ieee->iw_mode == IW_MODE_MONITOR) { + ieee80211_monitor_rx(ieee, skb, rx_stats); + stats->rx_packets++; + stats->rx_bytes += skb->len; + return 1; + } +#endif + +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt) { + int idx = 0; + if (skb->len >= hdrlen + 3) + idx = skb->data[hdrlen + 3] >> 6; + crypt = ieee->crypt[idx]; +#ifdef NOT_YET + sta = NULL; + + /* Use station specific key to override default keys if the + * receiver address is a unicast address ("individual RA"). If + * bcrx_sta_key parameter is set, station specific key is used + * even with broad/multicast targets (this is against IEEE + * 802.11, but makes it easier to use different keys with + * stations that do not support WEP key mapping). */ + + if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key) + (void) hostap_handle_sta_crypto(local, hdr, &crypt, + &sta); +#endif + + /* allow NULL decrypt to indicate an station specific override + * for default encryption */ + if (crypt && (crypt->ops == NULL || + crypt->ops->decrypt_mpdu == NULL)) + crypt = NULL; + + if (!crypt && (fc & IEEE80211_FCTL_WEP)) { + /* This seems to be triggered by some (multicast?) + * frames from other than current BSS, so just drop the + * frames silently instead of filling system log with + * these reports. */ + IEEE80211_DEBUG_DROP("WEP decryption failed (not set)" + " (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + ieee->ieee_stats.rx_discards_wep_undecryptable++; + goto rx_dropped; + } + } +#endif /* CONFIG_IEEE80211_CRYPT */ + +#ifdef NOT_YET + if (type != WLAN_FC_TYPE_DATA) { + if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH && + fc & IEEE80211_FCTL_WEP && ieee->host_decrypt && + (keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0) + { + printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth " + "from " MAC_FMT "\n", dev->name, + MAC_ARG(hdr->addr2)); + /* TODO: could inform hostapd about this so that it + * could send auth failure report */ + goto rx_dropped; + } + + if (ieee80211_rx_frame_mgmt(ieee, skb, rx_stats, type, stype)) + goto rx_dropped; + else + goto rx_exit; + } +#endif + + /* Data frame - extract src/dst addresses */ + if (skb->len < IEEE80211_DATA_HDR3_LEN) + goto rx_dropped; + + switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_FROMDS: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr3, ETH_ALEN); + break; + case IEEE80211_FCTL_TODS: + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + if (skb->len < IEEE80211_DATA_HDR4_LEN) + goto rx_dropped; + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr4, ETH_ALEN); + break; + case 0: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + } + +#ifdef NOT_YET + if (hostap_rx_frame_wds(ieee, hdr, fc, &wds)) + goto rx_dropped; + if (wds) { + skb->dev = dev = wds; + stats = hostap_get_stats(dev); + } + + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && + ieee->stadev && + memcmp(hdr->addr2, ieee->assoc_ap_addr, ETH_ALEN) == 0) { + /* Frame from BSSID of the AP for which we are a client */ + skb->dev = dev = ieee->stadev; + stats = hostap_get_stats(dev); + from_assoc_ap = 1; + } +#endif + + dev->last_rx = jiffies; + +#ifdef NOT_YET + if ((ieee->iw_mode == IW_MODE_MASTER || + ieee->iw_mode == IW_MODE_REPEAT) && + !from_assoc_ap) { + switch (hostap_handle_sta_rx(ieee, dev, skb, rx_stats, + wds != NULL)) { + case AP_RX_CONTINUE_NOT_AUTHORIZED: + frame_authorized = 0; + break; + case AP_RX_CONTINUE: + frame_authorized = 1; + break; + case AP_RX_DROP: + goto rx_dropped; + case AP_RX_EXIT: + goto rx_exit; + } + } +#endif + + /* Nullfunc frames may have PS-bit set, so they must be passed to + * hostap_handle_sta_rx() before being dropped here. */ + if (stype != IEEE80211_STYPE_DATA && + stype != IEEE80211_STYPE_DATA_CFACK && + stype != IEEE80211_STYPE_DATA_CFPOLL && + stype != IEEE80211_STYPE_DATA_CFACKPOLL) { + if (stype != IEEE80211_STYPE_NULLFUNC) + IEEE80211_DEBUG_DROP( + "RX: dropped data frame " + "with no data (type=0x%02x, " + "subtype=0x%02x, len=%d)\n", + type, stype, skb->len); + goto rx_dropped; + } + + /* skb: hdr + (possibly fragmented, possibly encrypted) payload */ + +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + (keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0) + goto rx_dropped; +#endif + hdr = (struct ieee80211_hdr *) skb->data; + + /* skb: hdr + (possibly fragmented) plaintext payload */ + // PR: FIXME: hostap has additional conditions in the "if" below: + // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) { + int flen; + struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr); + IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag); + + if (!frag_skb) { + IEEE80211_DEBUG(IEEE80211_DL_RX | IEEE80211_DL_FRAG, + "Rx cannot get skb from fragment " + "cache (morefrag=%d seq=%u frag=%u)\n", + (fc & IEEE80211_FCTL_MOREFRAGS) != 0, + WLAN_GET_SEQ_SEQ(sc), frag); + goto rx_dropped; + } + + flen = skb->len; + if (frag != 0) + flen -= hdrlen; + + if (frag_skb->tail + flen > frag_skb->end) { + printk(KERN_WARNING "%s: host decrypted and " + "reassembled frame did not fit skb\n", + dev->name); + ieee80211_frag_cache_invalidate(ieee, hdr); + goto rx_dropped; + } + + if (frag == 0) { + /* copy first fragment (including full headers) into + * beginning of the fragment cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data, flen); + } else { + /* append frame payload to the end of the fragment + * cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data + hdrlen, + flen); + } + dev_kfree_skb_any(skb); + skb = NULL; + + if (fc & IEEE80211_FCTL_MOREFRAGS) { + /* more fragments expected - leave the skb in fragment + * cache for now; it will be delivered to upper layers + * after all fragments have been received */ + goto rx_exit; + } + + /* this was the last fragment and the frame will be + * delivered, so remove skb from fragment cache */ + skb = frag_skb; + hdr = (struct ieee80211_hdr *) skb->data; + ieee80211_frag_cache_invalidate(ieee, hdr); + } + + /* skb: hdr + (possible reassembled) full MSDU payload; possibly still + * encrypted/authenticated */ +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt)) + goto rx_dropped; + + hdr = (struct ieee80211_hdr *) skb->data; + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) { + if (/*ieee->ieee802_1x &&*/ + ieee80211_is_eapol_frame(ieee, skb)) { +#ifdef CONFIG_IEEE80211_DEBUG + /* pass unencrypted EAPOL frames even if encryption is + * configured */ + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); +#endif + } else { + IEEE80211_DEBUG_DROP( + "encryption configured, but RX " + "frame not encrypted (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } + } + +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !(fc & IEEE80211_FCTL_WEP) && + ieee80211_is_eapol_frame(ieee, skb)) { + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif + + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep && + !ieee80211_is_eapol_frame(ieee, skb)) { + IEEE80211_DEBUG_DROP( + "dropped unencrypted RX data " + "frame from " MAC_FMT + " (drop_unencrypted=1)\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } +#endif /* CONFIG_IEEE80211_CRYPT */ + + /* skb: hdr + (possible reassembled) full plaintext payload */ + + payload = skb->data + hdrlen; + ethertype = (payload[6] << 8) | payload[7]; + +#ifdef NOT_YET + /* If IEEE 802.1X is used, check whether the port is authorized to send + * the received frame. */ + if (ieee->ieee802_1x && ieee->iw_mode == IW_MODE_MASTER) { + if (ethertype == ETH_P_PAE) { + printk(KERN_DEBUG "%s: RX: IEEE 802.1X frame\n", + dev->name); + if (ieee->hostapd && ieee->apdev) { + /* Send IEEE 802.1X frames to the user + * space daemon for processing */ + prism2_rx_80211(ieee->apdev, skb, rx_stats, + PRISM2_RX_MGMT); + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + goto rx_exit; + } + } else if (!frame_authorized) { + printk(KERN_DEBUG "%s: dropped frame from " + "unauthorized port (IEEE 802.1X): " + "ethertype=0x%04x\n", + dev->name, ethertype); + goto rx_dropped; + } + } +#endif + + /* convert hdr + possible LLC headers into Ethernet header */ + if (skb->len - hdrlen >= 8 && + ((memcmp(payload, rfc1042_header, SNAP_SIZE) == 0 && + ethertype != ETH_P_AARP && ethertype != ETH_P_IPX) || + memcmp(payload, bridge_tunnel_header, SNAP_SIZE) == 0)) { + /* remove RFC1042 or Bridge-Tunnel encapsulation and + * replace EtherType */ + skb_pull(skb, hdrlen + SNAP_SIZE); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } else { + u16 len; + /* Leave Ethernet header part of hdr and full payload */ + skb_pull(skb, hdrlen); + len = htons(skb->len); + memcpy(skb_push(skb, 2), &len, 2); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } + +#ifdef NOT_YET + if (wds && ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS) && + skb->len >= ETH_HLEN + ETH_ALEN) { + /* Non-standard frame: get addr4 from its bogus location after + * the payload */ + memcpy(skb->data + ETH_ALEN, + skb->data + skb->len - ETH_ALEN, ETH_ALEN); + skb_trim(skb, skb->len - ETH_ALEN); + } +#endif + + stats->rx_packets++; + stats->rx_bytes += skb->len; + +#ifdef NOT_YET + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + ieee->ap->bridge_packets) { + if (dst[0] & 0x01) { + /* copy multicast frame both to the higher layers and + * to the wireless media */ + ieee->ap->bridged_multicast++; + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 == NULL) + printk(KERN_DEBUG "%s: skb_clone failed for " + "multicast frame\n", dev->name); + } else if (hostap_is_sta_assoc(ieee->ap, dst)) { + /* send frame directly to the associated STA using + * wireless media and not passing to higher layers */ + ieee->ap->bridged_unicast++; + skb2 = skb; + skb = NULL; + } + } + + if (skb2 != NULL) { + /* send to wireless media */ + skb2->protocol = __constant_htons(ETH_P_802_3); + skb2->mac.raw = skb2->nh.raw = skb2->data; + /* skb2->nh.raw = skb2->data + ETH_HLEN; */ + skb2->dev = dev; + dev_queue_xmit(skb2); + } + +#endif + + if (skb) { + skb->protocol = eth_type_trans(skb, dev); + memset(skb->cb, 0, sizeof(skb->cb)); + skb->dev = dev; + skb->ip_summed = CHECKSUM_NONE; /* 802.11 crc not sufficient */ + netif_rx(skb); + } + + rx_exit: +#ifdef NOT_YET + if (sta) + hostap_handle_sta_release(sta); +#endif + return 1; + + rx_dropped: + stats->rx_dropped++; + + /* Returning 0 indicates to caller that we have not handled the SKB-- + * so it is still allocated and can be used again by underlying + * hardware as a DMA target */ + return 0; +} + +#define MGMT_FRAME_FIXED_PART_LENGTH 0x24 + +static inline int ieee80211_is_ofdm_rate(u8 rate) +{ + switch (rate & ~IEEE80211_BASIC_RATE_MASK) { + case IEEE80211_OFDM_RATE_6MB: + case IEEE80211_OFDM_RATE_9MB: + case IEEE80211_OFDM_RATE_12MB: + case IEEE80211_OFDM_RATE_18MB: + case IEEE80211_OFDM_RATE_24MB: + case IEEE80211_OFDM_RATE_36MB: + case IEEE80211_OFDM_RATE_48MB: + case IEEE80211_OFDM_RATE_54MB: + return 1; + } + return 0; +} + + +static inline int ieee80211_network_init( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_network *network, + struct ieee80211_rx_stats *stats) +{ +#ifdef CONFIG_IEEE80211_DEBUG + char rates_str[64]; + char *p; +#endif + struct ieee80211_info_element *info_element; + u16 left; + u8 i; + + /* Pull out fixed field data */ + memcpy(network->bssid, beacon->header.addr3, ETH_ALEN); + network->capability = beacon->capability; + network->last_scanned = jiffies; + network->time_stamp[0] = beacon->time_stamp[0]; + network->time_stamp[1] = beacon->time_stamp[1]; + network->beacon_interval = beacon->beacon_interval; + /* Where to pull this? beacon->listen_interval;*/ + network->listen_interval = 0x0A; + network->rates_len = network->rates_ex_len = 0; + network->last_associate = 0; + network->ssid_len = 0; + network->flags = 0; + network->atim_window = 0; + + if (stats->freq == IEEE80211_52GHZ_BAND) { + /* for A band (No DS info) */ + network->channel = stats->received_channel; + } else + network->flags |= NETWORK_HAS_CCK; + +#ifdef CONFIG_IEEE80211_WPA + network->wpa_ie_len = 0; + network->rsn_ie_len = 0; +#endif /* CONFIG_IEEE80211_WPA */ + + info_element = &beacon->info_element; + left = stats->len - ((void *)info_element - (void *)beacon); + while (left >= sizeof(struct ieee80211_info_element_hdr)) { + if (sizeof(struct ieee80211_info_element_hdr) + info_element->len > left) { + IEEE80211_DEBUG_SCAN("SCAN: parse failed: info_element->len + 2 > left : info_element->len+2=%d left=%d.\n", + info_element->len + sizeof(struct ieee80211_info_element), + left); + return 1; + } + + switch (info_element->id) { + case MFIE_TYPE_SSID: + if (ieee80211_is_empty_essid(info_element->data, + info_element->len)) { + network->flags |= NETWORK_EMPTY_ESSID; + break; + } + + network->ssid_len = min(info_element->len, + (u8)IW_ESSID_MAX_SIZE); + memcpy(network->ssid, info_element->data, network->ssid_len); + if (network->ssid_len < IW_ESSID_MAX_SIZE) + memset(network->ssid + network->ssid_len, 0, + IW_ESSID_MAX_SIZE - network->ssid_len); + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_SSID: '%s' len=%d.\n", + network->ssid, network->ssid_len); + break; + + case MFIE_TYPE_RATES: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_len = min(info_element->len, MAX_RATES_LENGTH); + for (i = 0; i < network->rates_len; i++) { + network->rates[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES: '%s' (%d)\n", + rates_str, network->rates_len); + break; + + case MFIE_TYPE_RATES_EX: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_ex_len = min(info_element->len, MAX_RATES_EX_LENGTH); + for (i = 0; i < network->rates_ex_len; i++) { + network->rates_ex[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES_EX: '%s' (%d)\n", + rates_str, network->rates_ex_len); + break; + + case MFIE_TYPE_DS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_DS_SET: %d\n", + info_element->data[0]); + if (stats->freq == IEEE80211_24GHZ_BAND) + network->channel = info_element->data[0]; + break; + + case MFIE_TYPE_FH_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_FH_SET: ignored\n"); + break; + + case MFIE_TYPE_CF_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CF_SET: ignored\n"); + break; + + case MFIE_TYPE_TIM: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_TIM: ignored\n"); + break; + + case MFIE_TYPE_IBSS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_IBSS_SET: ignored\n"); + break; + + case MFIE_TYPE_CHALLENGE: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CHALLENGE: ignored\n"); + break; + +#ifdef CONFIG_IEEE80211_WPA + case MFIE_TYPE_GENERIC: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_GENERIC: %d bytes\n", + info_element->len); + if (info_element->len >= 4 && + info_element->data[0] == 0x00 && + info_element->data[1] == 0x50 && + info_element->data[2] == 0xf2 && + info_element->data[3] == 0x01) { + network->wpa_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->wpa_ie, info_element, + network->wpa_ie_len); + } + break; + + case MFIE_TYPE_RSN: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RSN: %d bytes\n", + info_element->len); + network->rsn_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->rsn_ie, info_element, + network->rsn_ie_len); + break; +#endif + + default: + IEEE80211_DEBUG_SCAN("unsupported IE %d\n", + info_element->id); + break; + } + + left -= sizeof(struct ieee80211_info_element_hdr) + + info_element->len; + info_element = (struct ieee80211_info_element *) + &info_element->data[info_element->len]; + } + + network->mode = 0; + if (stats->freq == IEEE80211_52GHZ_BAND) { + network->mode = IEEE_A; + } else { + if (network->flags & NETWORK_HAS_OFDM) + network->mode |= IEEE_G; + if (network->flags & NETWORK_HAS_CCK) + network->mode |= IEEE_B; + } + + if (network->mode == 0) { + IEEE80211_DEBUG_SCAN("Filtered out '%s (" MAC_FMT ")' " + "network.\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid)); + return 1; + } + + if (ieee80211_is_empty_essid(network->ssid, network->ssid_len)) + network->flags |= NETWORK_EMPTY_ESSID; + + memcpy(&network->stats, stats, sizeof(network->stats)); + + return 0; +} + +static inline int is_same_network(struct ieee80211_network *src, + struct ieee80211_network *dst) +{ + /* A network is only a duplicate if the channel, BSSID, and ESSID + * all match. We treat all with the same BSSID and channel + * as one network */ + return ((src->ssid_len == dst->ssid_len) && + (src->channel == dst->channel) && + !memcmp(src->bssid, dst->bssid, ETH_ALEN) && + !memcmp(src->ssid, dst->ssid, src->ssid_len)); +} + +static inline void update_network(struct ieee80211_network *dst, + struct ieee80211_network *src) +{ + memcpy(&dst->stats, &src->stats, sizeof(struct ieee80211_rx_stats)); + dst->capability = src->capability; + memcpy(dst->rates, src->rates, src->rates_len); + dst->rates_len = src->rates_len; + memcpy(dst->rates_ex, src->rates_ex, src->rates_ex_len); + dst->rates_ex_len = src->rates_ex_len; + + dst->mode = src->mode; + dst->flags = src->flags; + dst->time_stamp[0] = src->time_stamp[0]; + dst->time_stamp[1] = src->time_stamp[1]; + + dst->beacon_interval = src->beacon_interval; + dst->listen_interval = src->listen_interval; + dst->atim_window = src->atim_window; + +#ifdef CONFIG_IEEE80211_WPA + memcpy(dst->wpa_ie, src->wpa_ie, src->wpa_ie_len); + dst->wpa_ie_len = src->wpa_ie_len; + memcpy(dst->rsn_ie, src->rsn_ie, src->rsn_ie_len); + dst->rsn_ie_len = src->rsn_ie_len; +#endif /* CONFIG_IEEE80211_WPA */ + + dst->last_scanned = jiffies; + /* dst->last_associate is not overwritten */ +} + +static inline void ieee80211_process_probe_response( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_rx_stats *stats) +{ + struct ieee80211_network network; + struct ieee80211_network *target; + struct ieee80211_network *oldest = NULL; +#ifdef CONFIG_IEEE80211_DEBUG + struct ieee80211_info_element *info_element = &beacon->info_element; +#endif + + IEEE80211_DEBUG_SCAN( + "'%s' (" MAC_FMT "): %c%c%c%c %c%c%c%c-%c%c%c%c %c%c%c%c\n", + escape_essid(info_element->data, info_element->len), + MAC_ARG(beacon->header.addr3), + (beacon->capability & BIT(0xf)) ? '1' : '0', + (beacon->capability & BIT(0xe)) ? '1' : '0', + (beacon->capability & BIT(0xd)) ? '1' : '0', + (beacon->capability & BIT(0xc)) ? '1' : '0', + (beacon->capability & BIT(0xb)) ? '1' : '0', + (beacon->capability & BIT(0xa)) ? '1' : '0', + (beacon->capability & BIT(0x9)) ? '1' : '0', + (beacon->capability & BIT(0x8)) ? '1' : '0', + (beacon->capability & BIT(0x7)) ? '1' : '0', + (beacon->capability & BIT(0x6)) ? '1' : '0', + (beacon->capability & BIT(0x5)) ? '1' : '0', + (beacon->capability & BIT(0x4)) ? '1' : '0', + (beacon->capability & BIT(0x3)) ? '1' : '0', + (beacon->capability & BIT(0x2)) ? '1' : '0', + (beacon->capability & BIT(0x1)) ? '1' : '0', + (beacon->capability & BIT(0x0)) ? '1' : '0'); + + if (ieee80211_network_init(ieee, beacon, &network, stats)) { + IEEE80211_DEBUG_SCAN("Dropped '%s' (" MAC_FMT ") via %s.\n", + escape_essid(info_element->data, + info_element->len), + MAC_ARG(beacon->header.addr3), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + return; + } + + /* The network parsed correctly -- so now we scan our known networks + * to see if we can find it in our list. + * + * NOTE: This search is definitely not optimized. Once its doing + * the "right thing" we'll optimize it for efficiency if + * necessary */ + + /* Search for this entry in the list and update it if it is + * already there. */ + list_for_each_entry(target, &ieee->network_list, list) { + if (is_same_network(target, &network)) + break; + + if ((oldest == NULL) || + (target->last_scanned < oldest->last_scanned)) + oldest = target; + } + + /* If we didn't find a match, then get a new network slot to initialize + * with this beacon's information */ + if (&target->list == &ieee->network_list) { + if (list_empty(&ieee->network_free_list)) { + /* If there are no more slots, expire the oldest */ + list_del(&oldest->list); + target = oldest; + IEEE80211_DEBUG_SCAN("Expired '%s' (" MAC_FMT ") from " + "network list.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid)); + } else { + /* Otherwise just pull from the free list */ + target = list_entry(ieee->network_free_list.next, + struct ieee80211_network, list); + list_del(ieee->network_free_list.next); + } + + +#ifdef CONFIG_IEEE80211_DEBUG + IEEE80211_DEBUG_SCAN("Adding '%s' (" MAC_FMT ") via %s.\n", + escape_essid(network.ssid, + network.ssid_len), + MAC_ARG(network.bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); +#endif + memcpy(target, &network, sizeof(*target)); + list_add_tail(&target->list, &ieee->network_list); + } else { + IEEE80211_DEBUG_SCAN("Updating '%s' (" MAC_FMT ") via %s.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + update_network(target, &network); + } +} + +void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats) +{ + switch (WLAN_FC_GET_STYPE(header->frame_ctl)) { + case IEEE80211_STYPE_ASSOC_RESP: + IEEE80211_DEBUG_MGMT("received ASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_REASSOC_RESP: + IEEE80211_DEBUG_MGMT("received REASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_PROBE_RESP: + IEEE80211_DEBUG_MGMT("received PROBE RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Probe response\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + case IEEE80211_STYPE_BEACON: + IEEE80211_DEBUG_MGMT("received BEACON (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Beacon\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + default: + IEEE80211_DEBUG_MGMT("received UNKNOWN (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_WARNING("%s: Unknown management packet: %d\n", + ieee->dev->name, + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + } +} + + +EXPORT_SYMBOL(ieee80211_rx_mgt); +EXPORT_SYMBOL(ieee80211_rx); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_tx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_tx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_tx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_tx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,464 @@ +/****************************************************************************** + + Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved. + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + The full GNU General Public License is included in this distribution in the + file called LICENSE. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + + +/* + + +802.11 Data Frame + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | Frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `--------------------------------------------------| |------' +Total: 28 non-data bytes `----.----' + | + .- 'Frame data' expands to <---------------------------' + | + V + ,---------------------------------------------------. +Bytes | 1 | 1 | 1 | 3 | 2 | 0-2304 | + |------|------|---------|----------|------|---------| +Desc. | SNAP | SNAP | Control |Eth Tunnel| Type | IP | + | DSAP | SSAP | | | | Packet | + | 0xAA | 0xAA |0x03 (UI)|0x00-00-F8| | | + `-----------------------------------------| | +Total: 8 non-data bytes `----.----' + | + .- 'IP Packet' expands, if WEP enabled, to <--' + | + V + ,-----------------------. +Bytes | 4 | 0-2296 | 4 | + |-----|-----------|-----| +Desc. | IV | Encrypted | ICV | + | | IP Packet | | + `-----------------------' +Total: 8 non-data bytes + + +802.3 Ethernet Data Frame + + ,-----------------------------------------. +Bytes | 6 | 6 | 2 | Variable | 4 | + |-------|-------|------|-----------|------| +Desc. | Dest. | Source| Type | IP Packet | fcs | + | MAC | MAC | | | | + `-----------------------------------------' +Total: 18 non-data bytes + +In the event that fragmentation is required, the incoming payload is split into +N parts of size ieee->fts. The first fragment contains the SNAP header and the +remaining packets are just data. + +If encryption is enabled, each fragment payload size is reduced by enough space +to add the prefix and postfix (IV and ICV totalling 8 bytes in the case of WEP) +So if you have 1500 bytes of payload with ieee->fts set to 500 without +encryption it will take 3 frames. With WEP it will take 4 frames as the +payload of each frame is reduced to 492 bytes. + +* SKB visualization +* +* ,- skb->data +* | +* | ETHERNET HEADER ,-<-- PAYLOAD +* | | 14 bytes from skb->data +* | 2 bytes for Type --> ,T. | (sizeof ethhdr) +* | | | | +* |,-Dest.--. ,--Src.---. | | | +* | 6 bytes| | 6 bytes | | | | +* v | | | | | | +* 0 | v 1 | v | v 2 +* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +* ^ | ^ | ^ | +* | | | | | | +* | | | | `T' <---- 2 bytes for Type +* | | | | +* | | '---SNAP--' <-------- 6 bytes for SNAP +* | | +* `-IV--' <-------------------- 4 bytes for IV (WEP) +* +* SNAP HEADER +* +*/ + +static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; +static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; + +static inline int ieee80211_put_snap(u8 *data, u16 h_proto) +{ + struct ieee80211_snap_hdr *snap; + u8 *oui; + + snap = (struct ieee80211_snap_hdr *)data; + snap->dsap = 0xaa; + snap->ssap = 0xaa; + snap->ctrl = 0x03; + + if (h_proto == 0x8137 || h_proto == 0x80f3) + oui = P802_1H_OUI; + else + oui = RFC1042_OUI; + snap->oui[0] = oui[0]; + snap->oui[1] = oui[1]; + snap->oui[2] = oui[2]; + + *(u16 *)(data + SNAP_SIZE) = htons(h_proto); + + return SNAP_SIZE + sizeof(u16); +} + +#ifdef CONFIG_IEEE80211_CRYPT +static inline int ieee80211_encrypt_fragment( + struct ieee80211_device *ieee, + struct sk_buff *frag, + int hdr_len) +{ + struct ieee80211_crypt_data* crypt = ieee->crypt[ieee->tx_keyidx]; + int res; +#ifdef CONFIG_IEEE80211_WPA + struct ieee80211_hdr *header; + + if (ieee->tkip_countermeasures && + crypt && crypt->ops && strcmp(crypt->ops->name, "TKIP") == 0) { + header = (struct ieee80211_hdr *) frag->data; + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "TX packet to " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(header->addr1)); + } + return -1; + } +#endif + /* To encrypt, frame format is: + * IV (4 bytes), clear payload (including SNAP), ICV (4 bytes) */ + + // PR: FIXME: Copied from hostap. Check fragmentation/MSDU/MPDU encryption. + /* Host-based IEEE 802.11 fragmentation for TX is not yet supported, so + * call both MSDU and MPDU encryption functions from here. */ + atomic_inc(&crypt->refcnt); + res = 0; + if (crypt->ops->encrypt_msdu) + res = crypt->ops->encrypt_msdu(frag, hdr_len, crypt->priv); + if (res == 0 && crypt->ops->encrypt_mpdu) + res = crypt->ops->encrypt_mpdu(frag, hdr_len, crypt->priv); + + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_INFO "%s: Encryption failed: len=%d.\n", + ieee->dev->name, frag->len); + ieee->ieee_stats.tx_discards++; + return -1; + } + + return 0; +} +#endif + + +void ieee80211_txb_free(struct ieee80211_txb *txb) { + int i; + if (unlikely(!txb)) + return; + for (i = 0; i < txb->nr_frags; i++) + if (txb->fragments[i]) + dev_kfree_skb_any(txb->fragments[i]); + kfree(txb); +} + +struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size, + int gfp_mask) +{ + struct ieee80211_txb *txb; + int i; + txb = kmalloc( + sizeof(struct ieee80211_txb) + (sizeof(u8*) * nr_frags), + gfp_mask); + if (!txb) + return NULL; + + memset(txb, sizeof(struct ieee80211_txb), 0); + txb->nr_frags = nr_frags; + txb->frag_size = txb_size; + + for (i = 0; i < nr_frags; i++) { + txb->fragments[i] = dev_alloc_skb(txb_size); + if (unlikely(!txb->fragments[i])) { + i--; + break; + } + } + if (unlikely(i != nr_frags)) { + while (i >= 0) + dev_kfree_skb_any(txb->fragments[i--]); + kfree(txb); + return NULL; + } + return txb; +} + +/* SKBs are added to the ieee->tx_queue. */ +int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_txb *txb = NULL; + struct ieee80211_hdr *frag_hdr; + int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size; + unsigned long flags; + struct net_device_stats *stats = &ieee->stats; + int ether_type, encrypt; + int bytes, fc, hdr_len; + struct sk_buff *skb_frag; + struct ieee80211_hdr header; + u8 dest[ETH_ALEN], src[ETH_ALEN]; + +#ifdef CONFIG_IEEE80211_CRYPT + struct ieee80211_crypt_data* crypt; +#endif + + spin_lock_irqsave(&ieee->lock, flags); + + /* If there is no driver handler to take the TXB, dont' bother + * creating it... */ + if (!ieee->hard_start_xmit) { + printk(KERN_WARNING "%s: No xmit handler.\n", + ieee->dev->name); + goto success; + } + + if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { + printk(KERN_WARNING "%s: skb too small (%d).\n", + ieee->dev->name, skb->len); + goto success; + } + + ether_type = ntohs(((struct ethhdr *)skb->data)->h_proto); + +#ifndef CONFIG_IEEE80211_CRYPT + encrypt = 0; +#else /* CONFIG_IEEE80211_CRYPT */ + crypt = ieee->crypt[ieee->tx_keyidx]; + +#ifndef CONFIG_IEEE80211_WPA + encrypt = (ether_type != ETH_P_PAE) && + ieee->host_encrypt && crypt && crypt->ops; + +#else /* CONFIG_IEEE80211_WPA */ + encrypt = !(ether_type == ETH_P_PAE && ieee->ieee802_1x) && + ieee->host_encrypt && crypt && crypt->ops; + + if (!encrypt && ieee->ieee802_1x && + ieee->drop_unencrypted && ether_type != ETH_P_PAE) { + stats->tx_dropped++; + goto success; + } + +#endif /* CONFIG_IEEE80211_WPA */ +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !encrypt && ether_type == ETH_P_PAE) { + struct eapol *eap = (struct eapol *)(skb->data + + sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16)); + IEEE80211_DEBUG_EAP("TX: IEEE 802.11 EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif +#endif /* CONFIG_IEEE80211_CRYPT */ + + /* Save source and destination addresses */ + memcpy(&dest, skb->data, ETH_ALEN); + memcpy(&src, skb->data+ETH_ALEN, ETH_ALEN); + + /* Advance the SKB to the start of the payload */ + skb_pull(skb, sizeof(struct ethhdr)); + + /* Determine total amount of storage required for TXB packets */ + bytes = skb->len + SNAP_SIZE + sizeof(u16); + + if (encrypt) + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | + IEEE80211_FCTL_WEP; + else + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(&header.addr1, ieee->bssid, ETH_ALEN); + memcpy(&header.addr2, &src, ETH_ALEN); + memcpy(&header.addr3, &dest, ETH_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + memcpy(&header.addr1, dest, ETH_ALEN); + memcpy(&header.addr2, src, ETH_ALEN); + memcpy(&header.addr3, ieee->bssid, ETH_ALEN); + } + header.frame_ctl = cpu_to_le16(fc); + hdr_len = IEEE80211_3ADDR_LEN; + + /* Determine fragmentation size based on destination (multicast + * and broadcast are not fragmented) */ + if (is_multicast_ether_addr(dest) || + is_broadcast_ether_addr(dest)) + frag_size = MAX_FRAG_THRESHOLD; + else + frag_size = ieee->fts; + + /* Determine amount of payload per fragment. Regardless of if + * this stack is providing the full 802.11 header, one will + * eventually be affixed to this fragment -- so we must account for + * it when determining the amount of payload space. */ + bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN; + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + bytes_per_frag -= IEEE80211_FCS_LEN; + +#ifdef CONFIG_IEEE80211_CRYPT + /* Each fragment may need to have room for encryptiong pre/postfix */ + if (encrypt) + bytes_per_frag -= crypt->ops->extra_prefix_len + + crypt->ops->extra_postfix_len; +#endif + + /* Number of fragments is the total bytes_per_frag / + * payload_per_fragment */ + nr_frags = bytes / bytes_per_frag; + bytes_last_frag = bytes % bytes_per_frag; + if (bytes_last_frag) + nr_frags++; + else + bytes_last_frag = bytes_per_frag; + + /* When we allocate the TXB we allocate enough space for the reserve + * and full fragment bytes (bytes_per_frag doesn't include prefix, + * postfix, header, FCS, etc.) */ + txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC); + if (unlikely(!txb)) { + printk(KERN_WARNING "%s: Could not allocate TXB\n", + ieee->dev->name); + goto failed; + } + txb->encrypted = encrypt; + txb->payload_size = bytes; + + for (i = 0; i < nr_frags; i++) { + skb_frag = txb->fragments[i]; + +#ifdef CONFIG_IEEE80211_CRYPT + if (encrypt) + skb_reserve(skb_frag, crypt->ops->extra_prefix_len); +#endif + + frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); + memcpy(frag_hdr, &header, hdr_len); + + /* If this is not the last fragment, then add the MOREFRAGS + * bit to the frame control */ + if (i != nr_frags - 1) { + frag_hdr->frame_ctl = cpu_to_le16( + fc | IEEE80211_FCTL_MOREFRAGS); + bytes = bytes_per_frag; + } else { + /* The last fragment takes the remaining length */ + bytes = bytes_last_frag; + } + + /* Put a SNAP header on the first fragment */ + if (i == 0) { + ieee80211_put_snap( + skb_put(skb_frag, SNAP_SIZE + sizeof(u16)), + ether_type); + bytes -= SNAP_SIZE + sizeof(u16); + } + + memcpy(skb_put(skb_frag, bytes), skb->data, bytes); + + /* Advance the SKB... */ + skb_pull(skb, bytes); + +#ifdef CONFIG_IEEE80211_CRYPT + /* Encryption routine will move the header forward in order + * to insert the IV between the header and the payload */ + if (encrypt) + ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len); +#endif + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + skb_put(skb_frag, 4); + } + + + success: + spin_unlock_irqrestore(&ieee->lock, flags); + + dev_kfree_skb_any(skb); + + if (txb) { + if ((*ieee->hard_start_xmit)(txb, dev) == 0) { + stats->tx_packets++; + stats->tx_bytes += txb->payload_size; + return 0; + } + ieee80211_txb_free(txb); + } + + return 0; + + failed: + spin_unlock_irqrestore(&ieee->lock, flags); + netif_stop_queue(dev); + stats->tx_errors++; + return 1; + +} + +EXPORT_SYMBOL(ieee80211_txb_free); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_wx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_wx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_wx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_wx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,526 @@ +/****************************************************************************** + + Copyright(c) 2004 Intel Corporation. All rights reserved. + + Portions of this file are based on the WEP enablement code provided by the + Host AP project hostap-drivers v0.1.3 + Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + + Copyright (c) 2002-2003, Jouni Malinen + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + The full GNU General Public License is included in this distribution in the + file called LICENSE. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include + +#include "../ieee80211.h" +static const char *ieee80211_modes[] = { + "?", "a", "b", "ab", "g", "ag", "bg", "abg" +}; + +#if 0 +static u32 ieee80211_frequency(u8 channel, u8 mode) +{ + if (mode == IEEE_A) { + if (channel >= 8 && channel <= 161) + return 5000000 + 5000 * channel; + + if (channel >= 240 && channel <= 252) + return 4960000 + 5000 * (channel - 240); + } + + if (channel == 14) + return 2484000; + + if (channel >= 1 && channel <= 13) + return 2407000 + 5000 * channel; + + return 0; +} +#endif + +#define MAX_CUSTOM_LEN 64 +static inline char *ipw2100_translate_scan(struct ieee80211_device *ieee, + char *start, char *stop, + struct ieee80211_network *network) +{ + char custom[MAX_CUSTOM_LEN]; + char *p; + struct iw_event iwe; + int i, j; + u8 max_rate, rate; + + /* First entry *MUST* be the AP MAC address */ + iwe.cmd = SIOCGIWAP; + iwe.u.ap_addr.sa_family = ARPHRD_ETHER; + memcpy(iwe.u.ap_addr.sa_data, network->bssid, ETH_ALEN); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_ADDR_LEN); + + /* Remaining entries will be displayed in the order we provide them */ + + /* Add the ESSID */ + iwe.cmd = SIOCGIWESSID; + iwe.u.data.flags = 1; + if (network->flags & NETWORK_EMPTY_ESSID) { + iwe.u.data.length = sizeof(""); + start = iwe_stream_add_point(start, stop, &iwe, ""); + } else { + iwe.u.data.length = min(network->ssid_len, (u8)32); + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + } + + /* Add the protocol name */ + iwe.cmd = SIOCGIWNAME; + snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11%s", ieee80211_modes[network->mode]); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_CHAR_LEN); + + /* Add mode */ + iwe.cmd = SIOCGIWMODE; + if (network->capability & + (WLAN_CAPABILITY_BSS | WLAN_CAPABILITY_IBSS)) { + if (network->capability & WLAN_CAPABILITY_BSS) + iwe.u.mode = IW_MODE_MASTER; + else + iwe.u.mode = IW_MODE_ADHOC; + + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_UINT_LEN); + } + + /* Add frequency/channel */ + iwe.cmd = SIOCGIWFREQ; +/* iwe.u.freq.m = ieee80211_frequency(network->channel, network->mode); + iwe.u.freq.e = 3; */ + iwe.u.freq.m = network->channel; + iwe.u.freq.e = 0; + iwe.u.freq.i = 0; + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_FREQ_LEN); + + /* Add encryption capability */ + iwe.cmd = SIOCGIWENCODE; + if (network->capability & WLAN_CAPABILITY_PRIVACY) + iwe.u.data.flags = IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags = IW_ENCODE_DISABLED; + iwe.u.data.length = 0; + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + + /* Add basic and extended rates */ + max_rate = 0; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), " Rates (Mb/s): "); + for (i = 0, j = 0; i < network->rates_len; ) { + if (j < network->rates_ex_len && + ((network->rates_ex[j] & 0x7F) < + (network->rates[i] & 0x7F))) + rate = network->rates_ex[j++] & 0x7F; + else + rate = network->rates[i++] & 0x7F; + if (rate > max_rate) + max_rate = rate; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + } + for (; j < network->rates_ex_len; j++) { + rate = network->rates_ex[j] & 0x7F; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + if (rate > max_rate) + max_rate = rate; + } + + iwe.cmd = SIOCGIWRATE; + iwe.u.bitrate.fixed = iwe.u.bitrate.disabled = 0; + iwe.u.bitrate.value = max_rate * 500000; + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_PARAM_LEN); + + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + /* Add quality statistics */ + /* TODO: Fix these values... */ + iwe.cmd = IWEVQUAL; + iwe.u.qual.qual = network->stats.signal; + iwe.u.qual.level = network->stats.rssi; + iwe.u.qual.noise = network->stats.noise; + iwe.u.qual.updated = network->stats.mask & IEEE80211_STATMASK_WEMASK; + if (!(network->stats.mask & IEEE80211_STATMASK_RSSI)) + iwe.u.qual.updated |= IW_QUAL_LEVEL_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_NOISE)) + iwe.u.qual.updated |= IW_QUAL_NOISE_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_SIGNAL)) + iwe.u.qual.updated |= IW_QUAL_QUAL_INVALID; + + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_QUAL_LEN); + + iwe.cmd = IWEVCUSTOM; + p = custom; + +#if 0 + if (network->stats.mask & IEEE80211_STATMASK_RSSI) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " RSSI: %-4d dBm ", + (s8)network->stats.rssi); + + if (network->stats.mask & IEEE80211_STATMASK_NOISE) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Noise: %-4d dBm ", + (s8)network->stats.noise); + + if (network->stats.mask & IEEE80211_STATMASK_SIGNAL) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Signal: %-4d dBm ", + (s8)network->stats.signal); +#endif + + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + +#ifdef CONFIG_IEEE80211_WPA + if (ieee->wpa_enabled && network->wpa_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "wpa_ie="); + for (i = 0; i < network->wpa_ie_len; i++) { + p += sprintf(p, "%02x", network->wpa_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + + if (ieee->wpa_enabled && network->rsn_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "rsn_ie="); + for (i = 0; i < network->rsn_ie_len; i++) { + p += sprintf(p, "%02x", network->rsn_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + +#endif /* CONFIG_IEEE80211_WPA */ + + /* Add EXTRA: Age to display seconds since last beacon/probe response + * for given network. */ + iwe.cmd = IWEVCUSTOM; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Last beacon: %lums ago", (jiffies - network->last_scanned) / (HZ / 100)); + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + + return start; +} + +int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *extra) +{ + struct ieee80211_network *network; + unsigned long flags; + + char *ev = extra; + char *stop = ev + IW_SCAN_MAX_DATA; + int i = 0; + + IEEE80211_DEBUG_WX("Getting scan\n"); + + spin_lock_irqsave(&ieee->lock, flags); + + list_for_each_entry(network, &ieee->network_list, list) { + i++; + if (ieee->scan_age == 0 || + time_after(network->last_scanned + ieee->scan_age, jiffies)) + ev = ipw2100_translate_scan(ieee, ev, stop, network); + else + IEEE80211_DEBUG_SCAN( + "Not showing network '%s (" + MAC_FMT ")' due to age (%lums).\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid), + (jiffies - network->last_scanned) / (HZ / 100)); + } + + spin_unlock_irqrestore(&ieee->lock, flags); + + wrqu->data.length = ev - extra; + wrqu->data.flags = 0; + + IEEE80211_DEBUG_WX("exit: %d networks returned.\n", i); + + return 0; +} + +int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); +#ifndef CONFIG_IEEE80211_CRYPT + if (erq->flags & IW_ENCODE_DISABLED) + return 0; + return -EOPNOTSUPP; +#else + struct net_device *dev = ieee->dev; + struct ieee80211_security sec = { + .flags = 0 + }; + int i, key, key_provided, len; + struct ieee80211_crypt_data **crypt; + + IEEE80211_DEBUG_WX("SET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + key_provided = 1; + } else { + key_provided = 0; + key = ieee->tx_keyidx; + } + + IEEE80211_DEBUG_WX("Key: %d [%s]\n", key, key_provided ? + "provided" : "default"); + + crypt = &ieee->crypt[key]; + + if (erq->flags & IW_ENCODE_DISABLED) { + if (key_provided && *crypt) { + IEEE80211_DEBUG_WX("Disabling encryption on key %d.\n", + key); + ieee80211_crypt_delayed_deinit(ieee, crypt); + } else + IEEE80211_DEBUG_WX("Disabling encryption.\n"); + + /* Check all the keys to see if any are still configured, + * and if no key index was provided, de-init them all */ + for (i = 0; i < WEP_KEYS; i++) { + if (ieee->crypt[i] != NULL) { + if (key_provided) + break; + ieee80211_crypt_delayed_deinit( + ieee, &ieee->crypt[i]); + } + } + + if (i == WEP_KEYS) { + sec.enabled = 0; + sec.level = SEC_LEVEL_0; + sec.flags |= SEC_ENABLED | SEC_LEVEL; + } + + goto done; + } + + + + sec.enabled = 1; + sec.flags |= SEC_ENABLED; + + if (*crypt != NULL && (*crypt)->ops != NULL && + strcmp((*crypt)->ops->name, "WEP") != 0) { + /* changing to use WEP; deinit previously used algorithm + * on this key */ + ieee80211_crypt_delayed_deinit(ieee, crypt); + } + + if (*crypt == NULL) { + struct ieee80211_crypt_data *new_crypt; + + /* take WEP into use */ + new_crypt = kmalloc(sizeof(struct ieee80211_crypt_data), + GFP_KERNEL); + if (new_crypt == NULL) + return -ENOMEM; + memset(new_crypt, 0, sizeof(struct ieee80211_crypt_data)); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + if (!new_crypt->ops) { + request_module("ieee80211_crypt_wep"); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + } + + if (new_crypt->ops && try_module_get(new_crypt->ops->owner)) + new_crypt->priv = new_crypt->ops->init(key); + + if (!new_crypt->ops || !new_crypt->priv) { + kfree(new_crypt); + new_crypt = NULL; + + printk(KERN_WARNING "%s: could not initialize WEP: " + "load module ieee80211_crypt_wep\n", + dev->name); + return -EOPNOTSUPP; + } + *crypt = new_crypt; + } + + /* If a new key was provided, set it up */ + if (erq->length > 0) { + len = erq->length <= 5 ? 5 : 13; + memcpy(sec.keys[key], keybuf, erq->length); + if (len > erq->length) + memset(sec.keys[key] + erq->length, 0, + len - erq->length); + IEEE80211_DEBUG_WX("Setting key %d to '%s' (%d:%d bytes)\n", + key, escape_essid(sec.keys[key], len), + erq->length, len); + sec.key_sizes[key] = len; + (*crypt)->ops->set_key(sec.keys[key], len, NULL, + (*crypt)->priv); + sec.flags |= (1 << key); + /* This ensures a key will be activated if no key is + * explicitely set */ + if (key == sec.active_key) + sec.flags |= SEC_ACTIVE_KEY; + } else { + len = (*crypt)->ops->get_key(sec.keys[key], WEP_KEY_LEN, + NULL, (*crypt)->priv); + if (len == 0) { + /* Set a default key of all 0 */ + IEEE80211_DEBUG_WX("Setting key %d to all zero.\n", + key); + memset(sec.keys[key], 0, 13); + (*crypt)->ops->set_key(sec.keys[key], 13, NULL, + (*crypt)->priv); + sec.key_sizes[key] = 13; + sec.flags |= (1 << key); + } + + /* No key data - just set the default TX key index */ + if (key_provided) { + IEEE80211_DEBUG_WX( + "Setting key %d to default Tx key.\n", key); + ieee->tx_keyidx = key; + sec.active_key = key; + sec.flags |= SEC_ACTIVE_KEY; + } + } + + done: + ieee->open_wep = !(erq->flags & IW_ENCODE_RESTRICTED); + sec.auth_mode = ieee->open_wep ? WLAN_AUTH_OPEN : WLAN_AUTH_SHARED_KEY; + sec.flags |= SEC_AUTH_MODE; + IEEE80211_DEBUG_WX("Auth: %s\n", sec.auth_mode == WLAN_AUTH_OPEN ? + "OPEN" : "SHARED KEY"); + + /* For now we just support WEP, so only set that security level... + * TODO: When WPA is added this is one place that needs to change */ + sec.flags |= SEC_LEVEL; + sec.level = SEC_LEVEL_1; /* 40 and 104 bit WEP */ + + if (ieee->set_security) + ieee->set_security(dev, &sec); + + /* Do not reset port if card is in Managed mode since resetting will + * generate new IEEE 802.11 authentication which may end up in looping + * with IEEE 802.1X. If your hardware requires a reset after WEP + * configuration (for example... Prism2), implement the reset_port in + * the callbacks structures used to initialize the 802.11 stack. */ + if (ieee->reset_on_keychange && + ieee->iw_mode != IW_MODE_INFRA && + ieee->reset_port && ieee->reset_port(dev)) { + printk(KERN_DEBUG "%s: reset_port failed\n", dev->name); + return -EINVAL; + } + return 0; +#endif +} + +int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); +#ifndef CONFIG_IEEE80211_CRYPT + printk(KERN_WARNING "%s: Encryption requested but not enabled in " + "build.\n", ieee->dev->name); + erq->length = 0; + erq->flags = IW_ENCODE_DISABLED; + return 0; +#else + int len, key; + struct ieee80211_crypt_data *crypt; + + IEEE80211_DEBUG_WX("GET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + } else + key = ieee->tx_keyidx; + + crypt = ieee->crypt[key]; + erq->flags = key + 1; + + if (crypt == NULL || crypt->ops == NULL) { + erq->length = 0; + erq->flags |= IW_ENCODE_DISABLED; + return 0; + } + + if (strcmp(crypt->ops->name, "WEP") != 0) { + /* only WEP is supported with wireless extensions, so just + * report that encryption is used */ + erq->length = 0; + erq->flags |= IW_ENCODE_ENABLED; + return 0; + } + + len = crypt->ops->get_key(keybuf, WEP_KEY_LEN, NULL, crypt->priv); + erq->length = (len >= 0 ? len : 0); + + erq->flags |= IW_ENCODE_ENABLED; + + if (ieee->open_wep) + erq->flags |= IW_ENCODE_OPEN; + else + erq->flags |= IW_ENCODE_RESTRICTED; + + return 0; +#endif +} + +EXPORT_SYMBOL(ieee80211_wx_get_scan); +EXPORT_SYMBOL(ieee80211_wx_set_encode); +EXPORT_SYMBOL(ieee80211_wx_get_encode); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211.h netdev-2.6-ipw/drivers/net/wireless/ieee80211.h --- netdev-2.6/drivers/net/wireless/ieee80211.h 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211.h 2005-02-04 10:20:02 -06:00 @@ -0,0 +1,888 @@ +/* + * Merged with mainline ieee80211.h in Aug 2004. Original ieee802_11 + * remains copyright by the original authors + * + * Portions of the merged code are based on Host AP (software wireless + * LAN access point) driver for Intersil Prism2/2.5/3. + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * + * Adaption to a generic IEEE 802.11 stack by James Ketrenos + * + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ +#ifndef IEEE80211_H +#define IEEE80211_H +#include /* ETH_ALEN */ +#include /* ARRAY_SIZE */ + +#if WIRELESS_EXT < 17 +#define IW_QUAL_QUAL_INVALID 0x10 +#define IW_QUAL_LEVEL_INVALID 0x20 +#define IW_QUAL_NOISE_INVALID 0x40 +#define IW_QUAL_QUAL_UPDATED 0x1 +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define IW_QUAL_NOISE_UPDATED 0x4 +#endif + +#define IEEE80211_DATA_LEN 2304 +/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section + 6.2.1.1.2. + + The figure in section 7.1.2 suggests a body size of up to 2312 + bytes is allowed, which is a bit confusing, I suspect this + represents the 2304 bytes of real data, plus a possible 8 bytes of + WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ + + +#define IEEE80211_HLEN 30 +#define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN) + +struct ieee80211_hdr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; + u8 addr4[ETH_ALEN]; +} __attribute__ ((packed)); + +struct ieee80211_hdr_3addr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; +} __attribute__ ((packed)); + +static const char *eap_types[] = { + "EAP-Packet", "EAPOL-Start", "EAPOL-Logoff", "EAPOL-Key", + "EAPOL-Encap-ASF-Alert", "Unknown" +}; + +static inline const char *eap_get_type(int type) +{ + if (type > ARRAY_SIZE(eap_types)) + type = ARRAY_SIZE(eap_types) - 1; + return eap_types[type]; +} + +struct eapol { + u8 snap[6]; + u16 ethertype; + u8 version; + u8 type; + u16 length; +} __attribute__ ((packed)); + +#define IEEE80211_3ADDR_LEN (24) +#define IEEE80211_4ADDR_LEN (30) +#define IEEE80211_FCS_LEN (4) + +#define MIN_FRAG_THRESHOLD 256U +#define MAX_FRAG_THRESHOLD 2346U + +/* Frame control field constants */ +#define IEEE80211_FCTL_VERS 0x0002 +#define IEEE80211_FCTL_FTYPE 0x000c +#define IEEE80211_FCTL_STYPE 0x00f0 +#define IEEE80211_FCTL_TODS 0x0100 +#define IEEE80211_FCTL_FROMDS 0x0200 +#define IEEE80211_FCTL_MOREFRAGS 0x0400 +#define IEEE80211_FCTL_RETRY 0x0800 +#define IEEE80211_FCTL_PM 0x1000 +#define IEEE80211_FCTL_MOREDATA 0x2000 +#define IEEE80211_FCTL_WEP 0x4000 +#define IEEE80211_FCTL_ORDER 0x8000 + +#define IEEE80211_FTYPE_MGMT 0x0000 +#define IEEE80211_FTYPE_CTL 0x0004 +#define IEEE80211_FTYPE_DATA 0x0008 + +/* management */ +#define IEEE80211_STYPE_ASSOC_REQ 0x0000 +#define IEEE80211_STYPE_ASSOC_RESP 0x0010 +#define IEEE80211_STYPE_REASSOC_REQ 0x0020 +#define IEEE80211_STYPE_REASSOC_RESP 0x0030 +#define IEEE80211_STYPE_PROBE_REQ 0x0040 +#define IEEE80211_STYPE_PROBE_RESP 0x0050 +#define IEEE80211_STYPE_BEACON 0x0080 +#define IEEE80211_STYPE_ATIM 0x0090 +#define IEEE80211_STYPE_DISASSOC 0x00A0 +#define IEEE80211_STYPE_AUTH 0x00B0 +#define IEEE80211_STYPE_DEAUTH 0x00C0 + +/* control */ +#define IEEE80211_STYPE_PSPOLL 0x00A0 +#define IEEE80211_STYPE_RTS 0x00B0 +#define IEEE80211_STYPE_CTS 0x00C0 +#define IEEE80211_STYPE_ACK 0x00D0 +#define IEEE80211_STYPE_CFEND 0x00E0 +#define IEEE80211_STYPE_CFENDACK 0x00F0 + +/* data */ +#define IEEE80211_STYPE_DATA 0x0000 +#define IEEE80211_STYPE_DATA_CFACK 0x0010 +#define IEEE80211_STYPE_DATA_CFPOLL 0x0020 +#define IEEE80211_STYPE_DATA_CFACKPOLL 0x0030 +#define IEEE80211_STYPE_NULLFUNC 0x0040 +#define IEEE80211_STYPE_CFACK 0x0050 +#define IEEE80211_STYPE_CFPOLL 0x0060 +#define IEEE80211_STYPE_CFACKPOLL 0x0070 + +#define IEEE80211_SCTL_FRAG 0x000F +#define IEEE80211_SCTL_SEQ 0xFFF0 + + +/* debug macros */ + +#ifdef CONFIG_IEEE80211_DEBUG +extern u32 ieee80211_debug_level; +#define IEEE80211_DEBUG(level, fmt, args...) \ +do { if (ieee80211_debug_level & (level)) \ + printk(KERN_DEBUG "ieee80211: %c %s " fmt, \ + in_interrupt() ? 'I' : 'U', __FUNCTION__ , ## args); } while (0) +#else +#define IEEE80211_DEBUG(level, fmt, args...) do {} while (0); +#endif /* CONFIG_IEEE80211_DEBUG */ + +/* + * To use the debug system; + * + * If you are defining a new debug classification, simply add it to the #define + * list here in the form of: + * + * #define IEEE80211_DL_xxxx VALUE + * + * shifting value to the left one bit from the previous entry. xxxx should be + * the name of the classification (for example, WEP) + * + * You then need to either add a IEEE80211_xxxx_DEBUG() macro definition for your + * classification, or use IEEE80211_DEBUG(IEEE80211_DL_xxxx, ...) whenever you want + * to send output to that classification. + * + * To add your debug level to the list of levels seen when you perform + * + * % cat /proc/net/ipw/debug_level + * + * you simply need to add your entry to the ipw_debug_levels array. + * + * If you do not see debug_level in /proc/net/ipw then you do not have + * CONFIG_IEEE80211_DEBUG defined in your kernel configuration + * + */ + +#define IEEE80211_DL_INFO BIT(0) +#define IEEE80211_DL_WX BIT(1) +#define IEEE80211_DL_SCAN BIT(2) +#define IEEE80211_DL_STATE BIT(3) +#define IEEE80211_DL_MGMT BIT(4) +#define IEEE80211_DL_FRAG BIT(5) +#define IEEE80211_DL_EAP BIT(6) +#define IEEE80211_DL_DROP BIT(7) + +#define IEEE80211_DL_TX BIT(8) +#define IEEE80211_DL_RX BIT(9) + +#define IEEE80211_ERROR(f, a...) printk(KERN_ERR "ieee80211: " f, ## a) +#define IEEE80211_WARNING(f, a...) printk(KERN_WARNING "ieee80211: " f, ## a) +#define IEEE80211_DEBUG_INFO(f, a...) IEEE80211_DEBUG(IEEE80211_DL_INFO, f, ## a) + +#define IEEE80211_DEBUG_WX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_WX, f, ## a) +#define IEEE80211_DEBUG_SCAN(f, a...) IEEE80211_DEBUG(IEEE80211_DL_SCAN, f, ## a) +#define IEEE80211_DEBUG_STATE(f, a...) IEEE80211_DEBUG(IEEE80211_DL_STATE, f, ## a) +#define IEEE80211_DEBUG_MGMT(f, a...) IEEE80211_DEBUG(IEEE80211_DL_MGMT, f, ## a) +#define IEEE80211_DEBUG_FRAG(f, a...) IEEE80211_DEBUG(IEEE80211_DL_FRAG, f, ## a) +#define IEEE80211_DEBUG_EAP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_EAP, f, ## a) +#define IEEE80211_DEBUG_DROP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_DROP, f, ## a) +#define IEEE80211_DEBUG_TX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_TX, f, ## a) +#define IEEE80211_DEBUG_RX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_RX, f, ## a) +#include +#include +#include /* ARPHRD_ETHER */ + +#ifndef WIRELESS_SPY +#define WIRELESS_SPY // enable iwspy support +#endif +#include // new driver API + +#define BIT(x) (1 << (x)) +#ifndef ETH_P_PAE +#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ +#endif /* ETH_P_PAE */ + +#define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ + +#ifndef ETH_P_80211_RAW +#define ETH_P_80211_RAW (ETH_P_ECONET + 1) +#endif + +/* IEEE 802.11 defines */ + +#define P80211_OUI_LEN 3 + +struct ieee80211_snap_hdr { + + u8 dsap; /* always 0xAA */ + u8 ssap; /* always 0xAA */ + u8 ctrl; /* always 0x03 */ + u8 oui[P80211_OUI_LEN]; /* organizational universal id */ + +} __attribute__ ((packed)); + +#define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) + +#define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) +#define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) + +#define WLAN_GET_SEQ_FRAG(seq) ((seq) & IEEE80211_SCTL_FRAG) +#define WLAN_GET_SEQ_SEQ(seq) ((seq) & IEEE80211_SCTL_SEQ) + +/* Authentication algorithms */ +#define WLAN_AUTH_OPEN 0 +#define WLAN_AUTH_SHARED_KEY 1 + +#define WLAN_AUTH_CHALLENGE_LEN 128 + +#define WLAN_CAPABILITY_BSS BIT(0) +#define WLAN_CAPABILITY_IBSS BIT(1) +#define WLAN_CAPABILITY_CF_POLLABLE BIT(2) +#define WLAN_CAPABILITY_CF_POLL_REQUEST BIT(3) +#define WLAN_CAPABILITY_PRIVACY BIT(4) +#define WLAN_CAPABILITY_SHORT_PREAMBLE BIT(5) +#define WLAN_CAPABILITY_PBCC BIT(6) +#define WLAN_CAPABILITY_CHANNEL_AGILITY BIT(7) + +/* Status codes */ +#define WLAN_STATUS_SUCCESS 0 +#define WLAN_STATUS_UNSPECIFIED_FAILURE 1 +#define WLAN_STATUS_CAPS_UNSUPPORTED 10 +#define WLAN_STATUS_REASSOC_NO_ASSOC 11 +#define WLAN_STATUS_ASSOC_DENIED_UNSPEC 12 +#define WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG 13 +#define WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION 14 +#define WLAN_STATUS_CHALLENGE_FAIL 15 +#define WLAN_STATUS_AUTH_TIMEOUT 16 +#define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17 +#define WLAN_STATUS_ASSOC_DENIED_RATES 18 +/* 802.11b */ +#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19 +#define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20 +#define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21 + +/* Reason codes */ +#define WLAN_REASON_UNSPECIFIED 1 +#define WLAN_REASON_PREV_AUTH_NOT_VALID 2 +#define WLAN_REASON_DEAUTH_LEAVING 3 +#define WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY 4 +#define WLAN_REASON_DISASSOC_AP_BUSY 5 +#define WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA 6 +#define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7 +#define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8 +#define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 + + +/* Information Element IDs */ +#define WLAN_EID_SSID 0 +#define WLAN_EID_SUPP_RATES 1 +#define WLAN_EID_FH_PARAMS 2 +#define WLAN_EID_DS_PARAMS 3 +#define WLAN_EID_CF_PARAMS 4 +#define WLAN_EID_TIM 5 +#define WLAN_EID_IBSS_PARAMS 6 +#define WLAN_EID_CHALLENGE 16 +#define WLAN_EID_RSN 48 +#define WLAN_EID_GENERIC 221 + +#define IEEE80211_MGMT_HDR_LEN 24 +#define IEEE80211_DATA_HDR3_LEN 24 +#define IEEE80211_DATA_HDR4_LEN 30 + + +#define IEEE80211_STATMASK_SIGNAL BIT(0) +#define IEEE80211_STATMASK_RSSI BIT(1) +#define IEEE80211_STATMASK_NOISE BIT(2) +#define IEEE80211_STATMASK_RATE BIT(3) +#define IEEE80211_STATMASK_WEMASK 0x7 + + +#define IEEE80211_CCK_MODULATION BIT(0) +#define IEEE80211_OFDM_MODULATION BIT(1) + +#define IEEE80211_24GHZ_BAND BIT(0) +#define IEEE80211_52GHZ_BAND BIT(1) + +#define IEEE80211_CCK_RATE_1MB 0x02 +#define IEEE80211_CCK_RATE_2MB 0x04 +#define IEEE80211_CCK_RATE_5MB 0x0B +#define IEEE80211_CCK_RATE_11MB 0x16 +#define IEEE80211_OFDM_RATE_6MB 0x0C +#define IEEE80211_OFDM_RATE_9MB 0x12 +#define IEEE80211_OFDM_RATE_12MB 0x18 +#define IEEE80211_OFDM_RATE_18MB 0x24 +#define IEEE80211_OFDM_RATE_24MB 0x30 +#define IEEE80211_OFDM_RATE_36MB 0x48 +#define IEEE80211_OFDM_RATE_48MB 0x60 +#define IEEE80211_OFDM_RATE_54MB 0x6C +#define IEEE80211_BASIC_RATE_MASK 0x80 + +#define IEEE80211_CCK_RATE_1MB_MASK BIT(0) +#define IEEE80211_CCK_RATE_2MB_MASK BIT(1) +#define IEEE80211_CCK_RATE_5MB_MASK BIT(2) +#define IEEE80211_CCK_RATE_11MB_MASK BIT(3) +#define IEEE80211_OFDM_RATE_6MB_MASK BIT(4) +#define IEEE80211_OFDM_RATE_9MB_MASK BIT(5) +#define IEEE80211_OFDM_RATE_12MB_MASK BIT(6) +#define IEEE80211_OFDM_RATE_18MB_MASK BIT(7) +#define IEEE80211_OFDM_RATE_24MB_MASK BIT(8) +#define IEEE80211_OFDM_RATE_36MB_MASK BIT(9) +#define IEEE80211_OFDM_RATE_48MB_MASK BIT(10) +#define IEEE80211_OFDM_RATE_54MB_MASK BIT(11) + +#define IEEE80211_CCK_RATES_MASK 0x0000000F +#define IEEE80211_CCK_BASIC_RATES_MASK (IEEE80211_CCK_RATE_1MB_MASK | \ + IEEE80211_CCK_RATE_2MB_MASK) +#define IEEE80211_CCK_DEFAULT_RATES_MASK (IEEE80211_CCK_BASIC_RATES_MASK | \ + IEEE80211_CCK_RATE_5MB_MASK | \ + IEEE80211_CCK_RATE_11MB_MASK) + +#define IEEE80211_OFDM_RATES_MASK 0x00000FF0 +#define IEEE80211_OFDM_BASIC_RATES_MASK (IEEE80211_OFDM_RATE_6MB_MASK | \ + IEEE80211_OFDM_RATE_12MB_MASK | \ + IEEE80211_OFDM_RATE_24MB_MASK) +#define IEEE80211_OFDM_DEFAULT_RATES_MASK (IEEE80211_OFDM_BASIC_RATES_MASK | \ + IEEE80211_OFDM_RATE_9MB_MASK | \ + IEEE80211_OFDM_RATE_18MB_MASK | \ + IEEE80211_OFDM_RATE_36MB_MASK | \ + IEEE80211_OFDM_RATE_48MB_MASK | \ + IEEE80211_OFDM_RATE_54MB_MASK) +#define IEEE80211_DEFAULT_RATES_MASK (IEEE80211_OFDM_DEFAULT_RATES_MASK | \ + IEEE80211_CCK_DEFAULT_RATES_MASK) + +#define IEEE80211_NUM_OFDM_RATES 8 +#define IEEE80211_NUM_CCK_RATES 4 +#define IEEE80211_OFDM_SHIFT_MASK_A 4 + + + + +/* NOTE: This data is for statistical purposes; not all hardware provides this + * information for frames received. Not setting these will not cause + * any adverse affects. */ +struct ieee80211_rx_stats { + u32 mac_time; + s8 rssi; + u8 signal; + u8 noise; + u16 rate; /* in 100 kbps */ + u8 received_channel; + u8 control; + u8 mask; + u8 freq; + u16 len; +}; + +/* IEEE 802.11 requires that STA supports concurrent reception of at least + * three fragmented frames. This define can be increased to support more + * concurrent frames, but it should be noted that each entry can consume about + * 2 kB of RAM and increasing cache size will slow down frame reassembly. */ +#define IEEE80211_FRAG_CACHE_LEN 4 + +struct ieee80211_frag_entry { + unsigned long first_frag_time; + unsigned int seq; + unsigned int last_frag; + struct sk_buff *skb; + u8 src_addr[ETH_ALEN]; + u8 dst_addr[ETH_ALEN]; +}; + +struct ieee80211_stats { + unsigned int tx_unicast_frames; + unsigned int tx_multicast_frames; + unsigned int tx_fragments; + unsigned int tx_unicast_octets; + unsigned int tx_multicast_octets; + unsigned int tx_deferred_transmissions; + unsigned int tx_single_retry_frames; + unsigned int tx_multiple_retry_frames; + unsigned int tx_retry_limit_exceeded; + unsigned int tx_discards; + unsigned int rx_unicast_frames; + unsigned int rx_multicast_frames; + unsigned int rx_fragments; + unsigned int rx_unicast_octets; + unsigned int rx_multicast_octets; + unsigned int rx_fcs_errors; + unsigned int rx_discards_no_buffer; + unsigned int tx_discards_wrong_sa; + unsigned int rx_discards_wep_undecryptable; + unsigned int rx_message_in_msg_fragments; + unsigned int rx_message_in_bad_msg_fragments; +}; + +struct ieee80211_device; + +#include "ieee80211_crypt.h" + +#define SEC_KEY_1 BIT(0) +#define SEC_KEY_2 BIT(1) +#define SEC_KEY_3 BIT(2) +#define SEC_KEY_4 BIT(3) +#define SEC_ACTIVE_KEY BIT(4) +#define SEC_AUTH_MODE BIT(5) +#define SEC_UNICAST_GROUP BIT(6) +#define SEC_LEVEL BIT(7) +#define SEC_ENABLED BIT(8) + +#define SEC_LEVEL_0 0 /* None */ +#define SEC_LEVEL_1 1 /* WEP 40 and 104 bit */ +#define SEC_LEVEL_2 2 /* Level 1 + TKIP */ +#define SEC_LEVEL_2_CKIP 3 /* Level 1 + CKIP */ +#define SEC_LEVEL_3 4 /* Level 2 + CCMP */ + +#define WEP_KEYS 4 +#define WEP_KEY_LEN 13 + +struct ieee80211_security { + u16 active_key:2, + enabled:1, + auth_mode:2, + auth_algo:4, + unicast_uses_group:1; + u8 key_sizes[WEP_KEYS]; + u8 keys[WEP_KEYS][WEP_KEY_LEN]; + u8 level; + u16 flags; +} __attribute__ ((packed)); + + +/* + + 802.11 data frame from AP + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `-------------------------------------------------------------------' + +Total: 28-2340 bytes + +*/ + +struct ieee80211_header_data { + u16 frame_ctl; + u16 duration_id; + u8 addr1[6]; + u8 addr2[6]; + u8 addr3[6]; + u16 seq_ctrl; +}; + +#define BEACON_PROBE_SSID_ID_POSITION 12 + +/* Management Frame Information Element Types */ +#define MFIE_TYPE_SSID 0 +#define MFIE_TYPE_RATES 1 +#define MFIE_TYPE_FH_SET 2 +#define MFIE_TYPE_DS_SET 3 +#define MFIE_TYPE_CF_SET 4 +#define MFIE_TYPE_TIM 5 +#define MFIE_TYPE_IBSS_SET 6 +#define MFIE_TYPE_CHALLENGE 16 +#define MFIE_TYPE_RSN 48 +#define MFIE_TYPE_RATES_EX 50 +#define MFIE_TYPE_GENERIC 221 + +struct ieee80211_info_element_hdr { + u8 id; + u8 len; +} __attribute__ ((packed)); + +struct ieee80211_info_element { + u8 id; + u8 len; + u8 data[0]; +} __attribute__ ((packed)); + +/* + * These are the data types that can make up management packets + * + u16 auth_algorithm; + u16 auth_sequence; + u16 beacon_interval; + u16 capability; + u8 current_ap[ETH_ALEN]; + u16 listen_interval; + struct { + u16 association_id:14, reserved:2; + } __attribute__ ((packed)); + u32 time_stamp[2]; + u16 reason; + u16 status; +*/ + +struct ieee80211_authentication { + struct ieee80211_header_data header; + u16 algorithm; + u16 transaction; + u16 status; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + + +struct ieee80211_probe_response { + struct ieee80211_header_data header; + u32 time_stamp[2]; + u16 beacon_interval; + u16 capability; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_request_frame { + u16 capability; + u16 listen_interval; + u8 current_ap[ETH_ALEN]; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_response_frame { + struct ieee80211_hdr_3addr header; + u16 capability; + u16 status; + u16 aid; + struct ieee80211_info_element info_element; /* supported rates */ +} __attribute__ ((packed)); + + +struct ieee80211_txb { + u8 nr_frags; + u8 encrypted; + u16 reserved; + u16 frag_size; + u16 payload_size; + struct sk_buff *fragments[0]; +}; + + +/* SWEEP TABLE ENTRIES NUMBER*/ +#define MAX_SWEEP_TAB_ENTRIES 42 +#define MAX_SWEEP_TAB_ENTRIES_PER_PACKET 7 +/* MAX_RATES_LENGTH needs to be 12. The spec says 8, and many APs + * only use 8, and then use extended rates for the remaining supported + * rates. Other APs, however, stick all of their supported rates on the + * main rates information element... */ +#define MAX_RATES_LENGTH ((u8)12) +#define MAX_RATES_EX_LENGTH ((u8)16) +#define MAX_NETWORK_COUNT 128 + +#define CRC_LENGTH 4U + +#define MAX_WPA_IE_LEN 64 + +#define NETWORK_EMPTY_ESSID BIT(0) +#define NETWORK_HAS_OFDM BIT(1) +#define NETWORK_HAS_CCK BIT(2) + +struct ieee80211_network { + /* These entries are used to identify a unique network */ + u8 bssid[ETH_ALEN]; + u8 channel; + /* Ensure null-terminated for any debug msgs */ + u8 ssid[IW_ESSID_MAX_SIZE + 1]; + u8 ssid_len; + + /* These are network statistics */ + struct ieee80211_rx_stats stats; + u16 capability; + u8 rates[MAX_RATES_LENGTH]; + u8 rates_len; + u8 rates_ex[MAX_RATES_EX_LENGTH]; + u8 rates_ex_len; + unsigned long last_scanned; + u8 mode; + u8 flags; + u32 last_associate; + u32 time_stamp[2]; + u16 beacon_interval; + u16 listen_interval; + u16 atim_window; +#ifdef CONFIG_IEEE80211_WPA + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; + u8 rsn_ie[MAX_WPA_IE_LEN]; + size_t rsn_ie_len; +#endif /* CONFIG_IEEE80211_WPA */ + struct list_head list; +}; + +enum ieee80211_state { + IEEE80211_UNINITIALIZED = 0, + IEEE80211_INITIALIZED, + IEEE80211_ASSOCIATING, + IEEE80211_ASSOCIATED, + IEEE80211_AUTHENTICATING, + IEEE80211_AUTHENTICATED, + IEEE80211_SHUTDOWN +}; + +#define DEFAULT_MAX_SCAN_AGE (15 * HZ) +#define DEFAULT_FTS 2346 +#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x" +#define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5] + + +extern inline int is_multicast_ether_addr(const u8 *addr) +{ + return ((addr[0] != 0xff) && (0x01 & addr[0])); +} + +extern inline int is_broadcast_ether_addr(const u8 *addr) +{ + return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) && \ + (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff)); +} + +#define CFG_IEEE80211_RESERVE_FCS BIT(0) +#define CFG_IEEE80211_COMPUTE_FCS BIT(1) + +struct ieee80211_device { + struct net_device *dev; + + /* Bookkeeping structures */ + struct net_device_stats stats; + struct ieee80211_stats ieee_stats; + + /* Probe / Beacon management */ + struct list_head network_free_list; + struct list_head network_list; + struct ieee80211_network *networks; + int scans; + int scan_age; + + int iw_mode; /* operating mode (IW_MODE_*) */ + + spinlock_t lock; + + int tx_headroom; /* Set to size of any additional room needed at front + * of allocated Tx SKBs */ + u32 config; + + /* WEP and other encryption related settings at the device level */ + int open_wep; /* Set to 1 to allow unencrypted frames */ + + int reset_on_keychange; /* Set to 1 if the HW needs to be reset on + * WEP key changes */ + + /* If the host performs {en,de}cryption, then set to 1 */ + int host_encrypt; + int host_decrypt; + int ieee802_1x; /* is IEEE 802.1X used */ + +#ifdef CONFIG_IEEE80211_WPA + /* WPA data */ + int wpa_enabled; + int drop_unencrypted; + int tkip_countermeasures; + int privacy_invoked; + size_t wpa_ie_len; + u8 *wpa_ie; +#endif /* CONFIG_IEEE80211_WPA */ + + struct list_head crypt_deinit_list; + struct ieee80211_crypt_data *crypt[WEP_KEYS]; + int tx_keyidx; /* default TX key index (crypt[tx_keyidx]) */ + struct timer_list crypt_deinit_timer; + + int bcrx_sta_key; /* use individual keys to override default keys even + * with RX of broad/multicast frames */ + + /* Fragmentation structures */ + struct ieee80211_frag_entry frag_cache[IEEE80211_FRAG_CACHE_LEN]; + unsigned int frag_next_idx; + u16 fts; /* Fragmentation Threshold */ + + /* Association info */ + u8 bssid[ETH_ALEN]; + + enum ieee80211_state state; + + int mode; /* A, B, G */ + int modulation; /* CCK, OFDM */ + int freq_band; /* 2.4Ghz, 5.2Ghz, Mixed */ + int abg_ture; /* ABG flag */ + + /* Callback functions */ + void (*set_security)(struct net_device *dev, + struct ieee80211_security *sec); + int (*hard_start_xmit)(struct ieee80211_txb *txb, + struct net_device *dev); + int (*reset_port)(struct net_device *dev); + + /* This must be the last item so that it points to the data + * allocated beyond this structure by alloc_ieee80211 */ + u8 priv[0]; +}; + +#define IEEE_A BIT(0) +#define IEEE_B BIT(1) +#define IEEE_G BIT(2) +#define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G) + +extern inline void *ieee80211_priv(struct net_device *dev) +{ + return ((struct ieee80211_device *)netdev_priv(dev))->priv; +} + +extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len) +{ + /* Single white space is for Linksys APs */ + if (essid_len == 1 && essid[0] == ' ') + return 1; + + /* Otherwise, if the entire essid is 0, we assume it is hidden */ + while (essid_len) { + essid_len--; + if (essid[essid_len] != '\0') + return 0; + } + + return 1; +} + +extern inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode) +{ + /* + * It is possible for both access points and our device to support + * combinations of modes, so as long as there is one valid combination + * of ap/device supported modes, then return success + * + */ + if ((mode & IEEE_A) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_52GHZ_BAND)) + return 1; + + if ((mode & IEEE_G) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + if ((mode & IEEE_B) && + (ieee->modulation & IEEE80211_CCK_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + return 0; +} + +extern inline int ieee80211_get_hdrlen(u16 fc) +{ + int hdrlen = 24; + + switch (WLAN_FC_GET_TYPE(fc)) { + case IEEE80211_FTYPE_DATA: + if ((fc & IEEE80211_FCTL_FROMDS) && (fc & IEEE80211_FCTL_TODS)) + hdrlen = 30; /* Addr4 */ + break; + case IEEE80211_FTYPE_CTL: + switch (WLAN_FC_GET_STYPE(fc)) { + case IEEE80211_STYPE_CTS: + case IEEE80211_STYPE_ACK: + hdrlen = 10; + break; + default: + hdrlen = 16; + break; + } + break; + } + + return hdrlen; +} + + + +/* ieee80211.c */ +extern void free_ieee80211(struct net_device *dev); +extern struct net_device *alloc_ieee80211(int sizeof_priv); + +extern int ieee80211_set_encryption(struct ieee80211_device *ieee); + +/* ieee80211_tx.c */ + + +extern int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev); +extern void ieee80211_txb_free(struct ieee80211_txb *); + + +/* ieee80211_rx.c */ +extern int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats); +extern void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats); + +/* iee80211_wx.c */ +extern int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); + + +extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee) +{ + ieee->scans++; +} + +extern inline int ieee80211_get_scans(struct ieee80211_device *ieee) +{ + return ieee->scans; +} + +static inline const char *escape_essid(const char *essid, u8 essid_len) { + static char escaped[IW_ESSID_MAX_SIZE * 2 + 1]; + const char *s = essid; + char *d = escaped; + + if (ieee80211_is_empty_essid(essid, essid_len)) { + memcpy(escaped, "", sizeof("")); + return escaped; + } + + essid_len = min(essid_len, (u8)IW_ESSID_MAX_SIZE); + while (essid_len--) { + if (*s == '\0') { + *d++ = '\\'; + *d++ = '0'; + s++; + } else { + *d++ = *s++; + } + } + *d = '\0'; + return escaped; +} + +#ifndef offset_in_page +#define offset_in_page(p) ((unsigned long)(p) & ~PAGE_MASK) +#endif + +#endif /* IEEE80211_H */ --------------040601040104090008060909-- From chas@cmf.nrl.navy.mil Fri Feb 4 10:50:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:50:47 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IoeuZ001242 for ; Fri, 4 Feb 2005 10:50:40 -0800 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 j14IoFU0021526; Fri, 4 Feb 2005 13:50:16 -0500 (EST) Message-Id: <200502041850.j14IoFU0021526@ginger.cmf.nrl.navy.mil> To: matthieu castet cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-Reply-To: Message from matthieu castet of "Fri, 04 Feb 2005 19:27:07 +0100." <4203BE7B.2030503@free.fr> Date: Fri, 04 Feb 2005 13:50:16 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1281 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: 293 Lines: 6 In message <4203BE7B.2030503@free.fr>,matthieu castet writes: >Shouldn't adev->signal == ATM_PHY_SIG_FOUND ? 1 : 0); be better : in the >case of ATM_PHY_SIG_UNKNOWN, it return 1... its intentional. if the atm device cant track the state of the link its probably best to just assume its up. From rkagan@mail.ru Fri Feb 4 12:13:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 12:13:31 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14KDNV9003332 for ; Fri, 4 Feb 2005 12:13:26 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id E8F684E0C4E; Fri, 4 Feb 2005 23:13:21 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.20.224] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 395828339; Fri, 04 Feb 2005 23:13:21 +0300 Date: Fri, 4 Feb 2005 23:13:27 +0300 From: Roman Kagan To: chas williams - CONTRACTOR Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050204201327.GA2439@katya> Mail-Followup-To: Roman Kagan , chas williams - CONTRACTOR , netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org References: <20050121085123.GA2471@katya> <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 3679 Lines: 110 Hi Chas, On Fri, Feb 04, 2005 at 01:11:25PM -0500, chas williams - CONTRACTOR wrote: > In message <20050121085123.GA2471@katya>,Roman Kagan writes: > >The patch is against 2.6.10. Please comment. > > i guess i would prefer that entries be named typeN, like he0 > instead of just a number. I'm fine with it. > if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the > kfree. Right, I forgot that sysfs was still optional. Below is the patch on top of yours to add this conditional to a few other places. > i added some other fields that i think are interesting. As a matter of fact that's what I hoped for :) > +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); Maybe it should better be "esi", to match the name in struct atm_dev? Besides, I've encountered a problem with hotplug being called from atm_dev_register: the device actually becomes usable only when the driver sets .dev_data, which may happen after hotplug has been called. E.g. if I call br2684ctl in my hotplug script, and it happens to attempt to open a socket on the device before .dev_data is set, br2684ctl fails (rather disgracefully BTW, forgetting to cleanup nasX). I had to work around it by adding a sleep for a couple of seconds to the hotplug script, and hoping that was enough for the driver to complete initializing atm_dev. I suspect the only way to fix it is to split the atm_dev initialization into two stages, allocation and registration, as it is done for net_device. Cheers, Roman. diff -ruNp linux-2.6.10.atm/net/atm/common.h linux-2.6.10.atm.new/net/atm/common.h --- linux-2.6.10.atm/net/atm/common.h 2005-02-04 21:46:52.084591328 +0300 +++ linux-2.6.10.atm.new/net/atm/common.h 2005-02-04 22:19:41.962124424 +0300 @@ -28,8 +28,21 @@ int atmpvc_init(void); void atmpvc_exit(void); int atmsvc_init(void); void atmsvc_exit(void); + +#ifdef CONFIG_SYSFS int atm_sysfs_init(void); void atm_sysfs_exit(void); +#else +static inline int atm_sysfs_init(void) +{ + return 0; +} + +static inline void atm_sysfs_exit(void) +{ + /* nothing */ +} +#endif /* CONFIG_SYSFS */ #ifdef CONFIG_PROC_FS int atm_proc_init(void); diff -ruNp linux-2.6.10.atm/net/atm/Makefile linux-2.6.10.atm.new/net/atm/Makefile --- linux-2.6.10.atm/net/atm/Makefile 2005-02-04 21:46:51.966609264 +0300 +++ linux-2.6.10.atm.new/net/atm/Makefile 2005-02-04 22:19:07.025435608 +0300 @@ -2,7 +2,7 @@ # Makefile for the ATM Protocol Families. # -atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o atm_sysfs.o +atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o obj-$(CONFIG_ATM) += atm.o @@ -12,6 +12,7 @@ obj-$(CONFIG_ATM_BR2684) += br2684.o atm-$(subst m,y,$(CONFIG_ATM_BR2684)) += ipcommon.o atm-$(subst m,y,$(CONFIG_NET_SCH_ATM)) += ipcommon.o atm-$(CONFIG_PROC_FS) += proc.o +atm-$(CONFIG_SYSFS) += atm_sysfs.o obj-$(CONFIG_ATM_LANE) += lec.o obj-$(CONFIG_ATM_MPOA) += mpoa.o diff -ruNp linux-2.6.10.atm/net/atm/resources.h linux-2.6.10.atm.new/net/atm/resources.h --- linux-2.6.10.atm/net/atm/resources.h 2005-02-04 21:46:52.263564120 +0300 +++ linux-2.6.10.atm.new/net/atm/resources.h 2005-02-04 22:19:19.766498672 +0300 @@ -43,7 +43,21 @@ static inline void atm_proc_dev_deregist #endif /* CONFIG_PROC_FS */ +#ifdef CONFIG_SYSFS int atm_register_sysfs(struct atm_dev *adev); void atm_unregister_sysfs(struct atm_dev *adev); +#else + +static inline int atm_register_sysfs(struct atm_dev *dev) +{ + return 0; +} + +static inline void atm_deregister_sysfs(struct atm_dev *dev) +{ + /* nothing */ +} + +#endif /* CONFIG_SYSFS */ #endif From jgarzik@pobox.com Fri Feb 4 13:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:07:37 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14L7W5S008317 for ; Fri, 4 Feb 2005 13:07:33 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CxAfo-0002ny-Fh; Fri, 04 Feb 2005 21:07:28 +0000 Message-ID: <4203E3FE.2090806@pobox.com> Date: Fri, 04 Feb 2005 16:07:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maxer CC: linux-kernel@vger.kernel.org, Netdev Subject: Re: SysKonnect sk98lin Gigabit lan missing in action from 2.6.10 on References: <42038994.20401@xmission.com> In-Reply-To: <42038994.20401@xmission.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1283 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: 681 Lines: 22 maxer wrote: > What is the status of sk98lin? Do we have to wait until Syskonnect gets > their act together > and write a new driver for 2.6.10? > > Their latest is Oct 2004 and not at all compatible with 2.6.10 and beyond. I've been telling SysKonnect for _years_ that they need to split up their patches, but they still keep sending ever-larger jumbo driver update patches. Stephen Hemminger split up their patch into a bunch of patches, and I applied several of those. Apparently, Stephen also got sick of trying to patch and clean sk98lin, so he went and wrote his own "skge" driver. It's available in my netdev-2.6 queue, and should be in the latest -mm. Jeff From schwab@suse.de Fri Feb 4 13:30:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:30:50 -0800 (PST) Received: from lisa.goe.net (lisa.JS.Jura.Uni-Goettingen.de [134.76.166.209]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14LUgJX009121 for ; Fri, 4 Feb 2005 13:30:43 -0800 Received: from mutter.goe.net (mail@mutter-lisa0.a11.private [192.168.31.26]) by lisa.goe.net (8.13.1/8.13.1) with ESMTP id j14LTonY004736; Fri, 4 Feb 2005 22:29:51 +0100 Received: from igel.a11.private ([192.168.31.91] helo=igel.home) by mutter.goe.net with esmtp (Exim 4.42) id 1CxB1S-0008BZ-6U; Fri, 04 Feb 2005 22:29:50 +0100 Received: by igel.home (Postfix, from userid 500) id B6D2910C283; Fri, 4 Feb 2005 22:29:49 +0100 (CET) To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [XFRM] Probe selected algorithm only References: <20050121101938.GA1133@gondor.apana.org.au> From: Andreas Schwab X-Yow: --Hello, POLICE? I"ve got ABBOTT & COSTELLO here on suspicion of HIGHWAY ROBBERY!! Date: Fri, 04 Feb 2005 22:29:49 +0100 In-Reply-To: <20050121101938.GA1133@gondor.apana.org.au> (Herbert Xu's message of "Fri, 21 Jan 2005 21:19:38 +1100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j14LUgJX009121 X-archive-position: 1284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schwab@suse.de Precedence: bulk X-list: netdev Content-Length: 1944 Lines: 66 Herbert Xu writes: > ===== net/xfrm/xfrm_algo.c 1.15 vs edited ===== > --- 1.15/net/xfrm/xfrm_algo.c 2004-12-28 13:33:32 +11:00 > +++ edited/net/xfrm/xfrm_algo.c 2005-01-21 21:17:12 +11:00 > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) > #include > @@ -346,58 +347,48 @@ > return NULL; > } > > -struct xfrm_algo_desc *xfrm_aalg_get_byname(char *name) > +static struct xfrm_algo_desc *xfrm_get_byname(struct xfrm_algo_desc *list, > + int entries, char *name, > + int probe) > { > - int i; > + int i, status; > > if (!name) > return NULL; > > - for (i=0; i < aalg_entries(); i++) { > - if (strcmp(name, aalg_list[i].name) == 0) { > - if (aalg_list[i].available) > - return &aalg_list[i]; > - else > - break; > - } > + for (i = 0; i < entries; i++) { > + if (!strcmp(name, list[i].name)) > + continue; You probably didn't mean this. :-) Return the first matching entry in xfrm_get_byname instead of the first non-matching one. Signed-off-by: Andreas Schwab --- linux-2.6.11-rc3/net/xfrm/xfrm_algo.c.~1~ 2005-02-03 22:54:42.000000000 +0100 +++ linux-2.6.11-rc3/net/xfrm/xfrm_algo.c 2005-02-04 21:56:11.000000000 +0100 @@ -357,7 +357,7 @@ static struct xfrm_algo_desc *xfrm_get_b return NULL; for (i = 0; i < entries; i++) { - if (!strcmp(name, list[i].name)) + if (strcmp(name, list[i].name) != 0) continue; if (list[i].available) Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From herbert@gondor.apana.org.au Fri Feb 4 13:32:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:32:55 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14LWlEi009593 for ; Fri, 4 Feb 2005 13:32:48 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxB46-0006wi-00; Sat, 05 Feb 2005 08:32:34 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxB3j-0004N1-00; Sat, 05 Feb 2005 08:32:11 +1100 Date: Sat, 5 Feb 2005 08:32:11 +1100 To: Andreas Schwab Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [XFRM] Probe selected algorithm only Message-ID: <20050204213211.GA16788@gondor.apana.org.au> References: <20050121101938.GA1133@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 459 Lines: 14 On Fri, Feb 04, 2005 at 10:29:49PM +0100, Andreas Schwab wrote: > > Return the first matching entry in xfrm_get_byname instead of the first > non-matching one. Yes you're totally right. Dave has already added a fix for this to his tree. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From lawrence@the-penguin.otak.com Fri Feb 4 14:28:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 14:28:35 -0800 (PST) Received: from the-penguin.otak.com (Debian-exim@the-penguin.otak.com [65.37.126.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14MSTml011132 for ; Fri, 4 Feb 2005 14:28:30 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 4.44) id 1CxBwA-0002ET-1a; Fri, 04 Feb 2005 14:28:26 -0800 Date: Fri, 4 Feb 2005 14:28:26 -0800 From: Lawrence Walton To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, Netdev Subject: Re: SysKonnect sk98lin Gigabit lan missing in action from 2.6.10 on Message-ID: <20050204222825.GA8533@the-penguin.otak.com> References: <42038994.20401@xmission.com> <4203E3FE.2090806@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203E3FE.2090806@pobox.com> X-Operating-System: Linux 2.6.11-rc3-mm1 on an i686 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lawrence@the-penguin.otak.com Precedence: bulk X-list: netdev Content-Length: 1390 Lines: 44 Jeff Garzik [jgarzik@pobox.com] wrote: > maxer wrote: > >What is the status of sk98lin? Do we have to wait until Syskonnect gets > >their act together > >and write a new driver for 2.6.10? > > > >Their latest is Oct 2004 and not at all compatible with 2.6.10 and beyond. > > I've been telling SysKonnect for _years_ that they need to split up > their patches, but they still keep sending ever-larger jumbo driver > update patches. > > Stephen Hemminger split up their patch into a bunch of patches, and I > applied several of those. > > Apparently, Stephen also got sick of trying to patch and clean sk98lin, > so he went and wrote his own "skge" driver. It's available in my > netdev-2.6 queue, and should be in the latest -mm. > > Jeff > > > > - > 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/ I have a SysKonnect card, and tried the skge driver (it's in the mm tree), with nominal testing I'd have to say it works well, if not better then the sk98lin driver. -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://the-penguin.otak.com/~lawrence -------------------------------------- - - - - - - O t a k i n c . - - - - - From jgarzik@pobox.com Fri Feb 4 14:48:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 14:48:44 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14MmeKB012023 for ; Fri, 4 Feb 2005 14:48:40 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CxCFj-0004Ut-1B; Fri, 04 Feb 2005 22:48:39 +0000 Message-ID: <4203FBB8.7000507@pobox.com> Date: Fri, 04 Feb 2005 17:48:24 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1287 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: 1359 Lines: 35 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) All this sounds great. I (and others) will be reviewing, and hope to get this into netdev-2.6 very soon. Thanks much, Jeff From shemminger@osdl.org Fri Feb 4 15:31:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 15:31:17 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14NVDht013541 for ; Fri, 4 Feb 2005 15:31:13 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j14NUwl19801; Fri, 4 Feb 2005 15:30:58 -0800 Date: Fri, 4 Feb 2005 15:31:08 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: js si , netem@lists.osdl.org, netdev@oss.sgi.com Subject: [PATCH] netem: memory leak Message-ID: <20050204153108.703ea71b@dxpl.pdx.osdl.net> In-Reply-To: <20050204231103.33325.qmail@web41510.mail.yahoo.com> References: <20050204231103.33325.qmail@web41510.mail.yahoo.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1288 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: 474 Lines: 14 Good catch.. netem needs to free skb's that are dropped due to loss simulation. diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2005-02-04 15:30:13 -08:00 +++ b/net/sched/sch_netem.c 2005-02-04 15:30:13 -08:00 @@ -177,6 +177,7 @@ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { pr_debug("netem_enqueue: random loss\n"); sch->qstats.drops++; + kfree_skb(skb); return 0; /* lie about loss so TCP doesn't know */ } From davem@davemloft.net Fri Feb 4 15:56:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 15:56:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14NueW2014379 for ; Fri, 4 Feb 2005 15:56:45 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxDC3-00086I-00; Fri, 04 Feb 2005 15:48:55 -0800 Date: Fri, 4 Feb 2005 15:48:55 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050204154855.79340cdb.davem@davemloft.net> In-Reply-To: <20050204113305.GA12764@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1589 Lines: 73 On Fri, 4 Feb 2005 22:33:05 +1100 Herbert Xu wrote: > I think you should probably note that some sort of locking or RCU > scheme is required to make this safe. As it is the atomic_inc > and the list_add can be reordered such that the atomic_inc occurs > after the atomic_dec_and_test. > > Either that or you can modify the example to add an > smp_mb__after_atomic_inc(). That'd be a good way to > demonstrate its use. Yeah, this example is totally bogus. I'll make it match the neighbour cache case which started this discussion. Which is something like: static void obj_list_add(struct obj *obj) { obj->active = 1; list_add(&obj->list); } static void obj_list_del(struct obj *obj) { list_del(&obj->list); obj->active = 0; } static void obj_destroy(struct obj *obj) { BUG_ON(obj->active); kfree(obj); } struct obj *obj_list_peek(struct list_head *head) { if (!list_empty(head)) { struct obj *obj; obj = list_entry(head->next, struct obj, list); atomic_inc(&obj->refcnt); return obj; } return NULL; } void obj_poke(void) { struct obj *obj; spin_lock(&global_list_lock); obj = obj_list_peek(&global_list); spin_unlock(&global_list_lock); if (obj) { obj->ops->poke(obj); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } } void obj_timeout(struct obj *obj) { spin_lock(&global_list_lock); obj_list_del(obj); spin_unlock(&global_list_lock); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } Something like that. I'll update the atomic_ops.txt doc and post and updated version later tonight. From dcbw@redhat.com Fri Feb 4 18:47:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 18:48:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j152lvmL021424 for ; Fri, 4 Feb 2005 18:47:58 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j152jtbZ031902; Fri, 4 Feb 2005 21:45: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 j152jtO31038; Fri, 4 Feb 2005 21:45:55 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j152jtb9004775; Fri, 4 Feb 2005 21:45:55 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j152jteG004771; Fri, 4 Feb 2005 21:45:55 -0500 Date: Fri, 4 Feb 2005 21:45:55 -0500 (EST) From: Dan Williams To: jt@hpl.hp.com cc: netdev@oss.sgi.com Subject: WEXT quality specification Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279707962-1533241267-1107571555=:4701" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 10814 Lines: 186 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --279707962-1533241267-1107571555=:4701 Content-Type: TEXT/PLAIN; charset=US-ASCII Jean, I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an attempt to concretely specify what drivers need to do for quality. I do this so that all ambiguity about signal quality will hopefully be gone, and so that both driver writers and user-application writers know their responsibilities. Please look it over and comment (diff attached). Its a bit long, but I feel that it has to be to adequately explain the system. I also feel that if its separate from wireless.h, people won't be bothered to go find the documentation, though if you feel strongly that it shouldn't be there then its fine to move it elsewhere. Thanks! Dan --279707962-1533241267-1107571555=:4701 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="wireless-quality-exp.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="wireless-quality-exp.diff" LS0tIHdpcmVsZXNzLjE3LmguYmFrCTIwMDUtMDItMDQgMjA6Mjg6MDMuMDAw MDAwMDAwIC0wNTAwDQorKysgd2lyZWxlc3MuMTcuaAkyMDA1LTAyLTA0IDIx OjI5OjI2LjAwMDAwMDAwMCAtMDUwMA0KQEAgLTE4NCw2ICsxODQsMTA4IEBA DQogICoJLSBBZGQgc3VwcG9ydCBmb3IgcmVsYXRpdmUgVHhQb3dlciAoeWlj ayAhKQ0KICAqLw0KIA0KKy8qDQorICogRXhwbGFuYXRpb24gb2YgV0lSRUxF U1MgUVVBTElUWQ0KKyAqIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCisgKg0KKyAqIFdpcmVsZXNzIHF1YWxpdHkgaXMgbWF5IGJlIG1lYXN1 cmVkIGluIHR3byBtZXRob2RzLCBkcml2ZXJzIG11c3QgUElDSyBPTkUNCisg KiBhbmQgdXNlIGl0IGNvbnNpc3RlbnRseSB0aHJvdWdob3V0IHRoZSBkcml2 ZXItPnVzZXJzcGFjZSBBUEk6DQorICoNCisgKiAxKSBUaGUgZmlyc3QsIHJl cXVpcmVkIGJ5IHRoZSA4MDIuMTFiIHNwZWNpZmljYXRpb24sIGlzIFJlbGF0 aXZlIFNpZ25hbA0KKyAqIFN0cmVuZ3RoIEluZGljYXRvciAoUlNTSSksIHdo aWNoIGlzIG51bWJlciBiZXR3ZWVuIDAgYW5kIE1BWF9SU1NJDQorICogaW5j bHVzaXZlLiBNYW51ZmFjdHVyZXJzIHVzZSBkaWZmZXJlbnQgbnVtYmVycyBm b3IgTUFYX1JTU0ksIHRob3VnaCBNQVhfUlNTSQ0KKyAqIGNhbm5vdCBiZSBs YXJnZXIgdGhhbiAyNTUuICBGb3IgcXVhbGl0aWVzIG1lYXN1cmVkIGluIFJT U0ksIHRoZSBsb3dlciBib3VuZA0KKyAqIGlzIF9hbHdheXNfIDAsIGFuZCB0 aGUgdXBwZXIgYm91bmQgaXMgX2Fsd2F5c18gTUFYX1JTU0kuDQorICoNCisg KiAyKSBUaGUgc2Vjb25kIG1lYXN1cmUgaXMgZGVjaWJlbCBtaWxsaXZvbHRz LCBvciBkQm0uICBUaGlzIGlzIGNhbGN1bGF0ZWQgZnJvbQ0KKyAqIHRoZSBS U1NJIG9mIGVhY2ggcGFja2V0IGJhc2VkIG9uIGxvb2t1cCB0YWJsZXMgb3Ig Y29udmVyc2lvbiBjb25zdGFudHMNCisgKiBzcGVjaWZpZWQgYnkgZWFjaCBt YW51ZmFjdHVyZXIuICBkQm0gaXMgYW4gYWJzb2x1dGUgbWVhc3VyZW1lbnQg b2YgZWxlY3RyaWNhbA0KKyAqIHBvd2VyIGdlbmVyYXRlZCBieSB0aGUgcmFk aW8gc2lnbmFscyBpbiB0aGUgcmVjZWl2ZSBjaXJjdWl0cnkgb2YgdGhlIGNh cmQuDQorICogSXQgaXMgZXhwcmVzc2VkIGluIF9uZWdhdGl2ZV8gbnVtYmVy cywgd2hlcmUgMGRCbSA9IDFtVi4gIFRoZSB1cHBlciBib3VuZA0KKyAqIGlz IF9hbHdheXNfIDAsIGFuZCB0aGUgbG93ZXIgYm91bmQgaXMgZGV0ZXJtaW5l ZCBieSB0aGUgcmVjZWl2ZXIgc2Vuc2l0aXZpdHkNCisgKiBvZiB0aGUgZWxl Y3RyaWNhbCBlcXVpcG1lbnQgb24gdGhlIGNhcmQuDQorICoNCisgKiBJZiB0 aGUgZHJpdmVyIGRvZXMgbm90IGtub3cgd2hhdCB2YWx1ZSB0byBwdXQgaW4g YSBmaWVsZCwgaXQgTVVTVCBpbmRpY2F0ZQ0KKyAqIHRoYXQgdGhlIGZpZWxk IGlzIGludmFsaWQgYnkgYml0d2lzZS1PUi1pbmcgdGhlIC51cGRhdGVkIGZp ZWxkIHdpdGggdGhlDQorICogYXBwcm9wcmlhdGUgSVdfUVVBTF8qX0lOVkFM SUQgY29uc3RhbnQgc3BlY2lmaWVkIGJlbG93LiAgU2ltcGx5IHNldHRpbmcg dGhlDQorICogZmllbGQgdG8gMCBpcyBub3Qgc3VmZmljaWVudCB0byBzcGVj aWZ5IHRoYXQgdGhlIHZhbHVlIGlzIHVua25vd24uDQorICoNCisgKiANCisg KiBUaGUgJ3F1YWwnIGZpZWxkcyBhcmUgbWV0aG9kIGluZGVwZW5kZW50LCBh bmQgYXJlIHNwZWNpZmllZCBhcyBmb2xsb3dzOg0KKyAqDQorICogbWF4X3F1 YWwucXVhbDogICAocmFuZ2UgaXMgMCAtPiAyNTUpIHVwcGVyIGJvdW5kIG9m IHN1YmplY3RpdmUgcXVhbGl0eQ0KKyAqICAgICAgICAgICAgICAgICAgbGV2 ZWxzLiAgT3RoZXIgLnF1YWwgZmllbGRzIE1VU1QgYmUgbGVzcyB0aGFuIHRo aXMgbnVtYmVyLg0KKyAqDQorICogcXVhbC5xdWFsOiAgICAgICAocmFuZ2Ug aXMgMCAtPiBtYXhfcXVhbC5xdWFsKSBRdWFsaXR5IG9mIHRoZSByZWNlaXZl ZCBwYWNrZXQNCisgKiAgICAgICAgICAgICAgICAgIGFzIGRldGVybWluZWQg YnkgdGhlIGRyaXZlci4gIFRoZSBvbmx5IHJlc3RyaWN0aW9uIGlzIHRoYXQN CisgKiAgICAgICAgICAgICAgICAgIHVzZXIgYXBwbGljYXRpb25zIE1VU1Qg YmUgYWJsZSB0byBkZXJpdmUgYSBwZXJjZW50YWdlIHZhbHVlDQorICogICAg ICAgICAgICAgICAgICBieSBkb2luZyB0aGUgZm9sbG93aW5nIGNhbGN1bGF0 aW9uOg0KKyAqICAgICAgICAgICAgICAgICAgICAgICAgICBwZXJjZW50ID0g IDEwMCAqIChxdWFsLnF1YWwgLyBtYXhfcXVhbC5xdWFsKQ0KKyAqICAgICAg ICAgICAgICAgICAgRHJpdmVycyBtYXkgZmFjdG9yIG90aGVyIHN0YXRpc3Rp Y3MsIHN1Y2ggYXMgcmVjZWl2ZSBwYWNrZXQNCisgKiAgICAgICAgICAgICAg ICAgIGVycm9ycywgIyBjb2xsaXNpb25zLCBub2lzZSBsZXZlbHMsIGV0Yywg aW50byB0aGUgdmFsdWUuDQorICoNCisgKiBPbmNlIGEgZHJpdmVyIGhhcyBQ SUNLRUQgT05FIG1ldGhvZCBvZiBtZWFzdXJlbWVudCwgdGhlIHF1YWxpdHkg ZmllbGRzIG11c3QNCisgKiBiZSBmaWxsZWQgYXMgZm9sbG93cy4gIFJlbWVt YmVyLCBhbGwgZmllbGRzIGFyZSA4LWJpdHMgd2lkZSBhbmQgYXJlIHRyZWF0 ZWQNCisgKiBhcyBzaWduZWQgb3IgdW5zaWduZWQgYmFzZWQgb24gdGhlIG1l dGhvZCBvZiBxdWFsaXR5IG1lYXN1cmVtZW50IGFib3ZlLg0KKyAqDQorICoN CisgKiBSU1NJIE1FVEhPRCAoc2V0IG1heF9xdWFsLmxldmVsID4gMCBhcyBl eHBsYWluZWQgYmVsb3cpDQorICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKyAqIG1heF9xdWFs LmxldmVsOiAgKHJhbmdlIGlzIDEgLT4gMjU1KSB1cHBlciBib3VuZCBvZiB0 aGUgUlNTSSBvZiBhbnkgcmVjZWl2ZWQNCisgKiAgICAgICAgICAgICAgICAg IHBhY2tldCwgZGV0ZXJtaW5lZCBieSB0aGUgY2FyZCdzIGhhcmR3YXJlLiAg VXN1YWxseQ0KKyAqICAgICAgICAgICAgICAgICAgc3BlY2lmaWVkIGluIHRl Y2huaWNhbCBsaXRlcmF0dXJlIGZyb20gbWFudWZhY3R1cmVyLCBvcg0KKyAq ICAgICAgICAgICAgICAgICAgcHJvdmlkZWQgYnkgcmVnaXN0ZXJzIG9uIHRo ZSBjYXJkLg0KKyAqICAgICAgICAgICAgICAgICAgICBOT1RFOiB0byBzcGVj aWZ5IHRoYXQgdmFsdWVzIGFyZSBpbiBSU1NJLCBtYXhfcXVhbC5sZXZlbA0K KyAqICAgICAgICAgICAgICAgICAgICAgICAgICBNVVNUIGJlIGxhcmdlciB0 aGFuIDAuDQorICoNCisgKiBtYXhfcXVhbC5ub2lzZTogIChyYW5nZSBpcyAw IC0+IDI1NSkgbG93ZXIgYm91bmQgb2Ygbm9pc2UsIGllIHRoZSByZWNlaXZl ZA0KKyAqICAgICAgICAgICAgICAgICAgc2lnbmFsIG11c3Qgbm90IGRyb3Ag YmVsb3cgdGhpcyBsZXZlbCBvciBpdCBjYW5ub3QgYmUNCisgKiAgICAgICAg ICAgICAgICAgIGRpc3Rpbmd1aXNoZWQuICBVc3VhbGx5IHNwZWNpZmllZCBi eSB0aGUgbWFudWZhY3R1cmVyLiAgSWYNCisgKiAgICAgICAgICAgICAgICAg IGhhcmR3YXJlIGRvZXMgbm90IHByb3ZpZGUgcGVyLXBhY2tldCBub2lzZSBp bmZvcm1hdGlvbiwgdGhlbg0KKyAqICAgICAgICAgICAgICAgICAgdGhlcmUg TVVTVCBiZSBhIHZhbHVlIGluIHRoaXMgZmllbGQuDQorICoNCisgKiBxdWFs LmxldmVsOiAgICAgIChyYW5nZSBpcyAwIC0+IG1heF9xdWFsLmxldmVsKSBh Y3R1YWwgUlNTSSB0YWtlbiBmcm9tDQorICogICAgICAgICAgICAgICAgICB0 aGUgcmVjZWl2ZXIgaGFyZHdhcmUgZm9yIGVhY2ggcGFja2V0Lg0KKyAqDQor ICogcXVhbC5ub2lzZTogICAgICAocmFuZ2UgaXMgMCAtPiBtYXhfcXVhbC5s ZXZlbCkgbm9pc2UgUlNTSSB2YWx1ZSB0YWtlbiBmcm9tDQorICogICAgICAg ICAgICAgICAgICB0aGUgcmVjZWl2ZSBoYXJkd2FyZSBpbiBSU1NJIGZvciBl YWNoIHBhY2tldC4gIElmIGhhcmR3YXJlDQorICogICAgICAgICAgICAgICAg ICBkb2VzIG5vdCBwcm92aWRlIHRoaXMgdmFsdWUgZm9yIGVhY2ggcGFja2V0 LCBzZXQgdG8gMCBhbmQNCisgKiAgICAgICAgICAgICAgICAgIHNldCAncXVh bC51cGRhdGVkIHw9IElXX1FVQUxfTk9JU0VfSU5WQUxJRCcuICBZb3UgbXVz dCB0aGVuDQorICogICAgICAgICAgICAgICAgICBwcm92aWRlIGEgdmFsdWUg aW4gbWF4X3F1YWwubm9pc2UgaW5zdGVhZC4NCisgKg0KKyAqIEluIHRoZSBS U1NJIG1ldGhvZCwgdmFsdWVzIGFyZSBfYWx3YXlzXyBwb3NpdGl2ZSBudW1i ZXJzLg0KKyAqDQorICoNCisgKiBkQm0gTUVUSE9EIChzZXQgbWF4X3F1YWwu bGV2ZWwgPSAwKQ0KKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQorICogbWF4X3F1YWwubGV2ZWwgICBNVVNUIGJlIHNldCB0byAw IHRvIHNwZWNpZnkgZEJtIG1ldGhvZA0KKyAqDQorICogbWF4X3F1YWwubm9p c2UgICAocmFuZ2UgaXMgLTI1NSAtPiAwKSBsb3dlciBib3VuZCBvZiBub2lz ZSBpbiBkQm0sIHNpZ25hbCBkQm0NCisgKiAgICAgICAgICAgICAgICAgIG1h eSBub3QgZHJvcCBiZWxvdyB0aGlzIGxldmVsIG9yIHRoZSBzaWduYWwgY2Fu bm90IGJlDQorICogICAgICAgICAgICAgICAgICBkaXN0aW5ndWlzaGVkIGZy b20gYmFja2dyb3VuZCBub2lzZSBieSB0aGUgcmVjZWl2ZXIuDQorICogICAg ICAgICAgICAgICAgICBVc3VhbGx5IHNwZWNpZmllZCBieSB0aGUgbWFudWZh Y3R1cmVyLiAgSWYgaGFyZHdhcmUgZG9lcyBub3QNCisgKiAgICAgICAgICAg ICAgICAgIHByb3ZpZGUgcGVyLXBhY2tldCBub2lzZSBpbmZvcm1hdGlvbiwg dGhlbiB0aGVyZSBNVVNUIGJlIGENCisgKiAgICAgICAgICAgICAgICAgIHZh bHVlIGluIHRoaXMgZmllbGQuDQorICoNCisgKiBxdWFsLmxldmVsICAgICAg IChyYW5nZSBpcyBtYXhfcXVhbC5ub2lzZSAtPiAwKSBzaWduYWwgbGV2ZWwg aW4gZEJtIHRha2VuDQorICogICAgICAgICAgICAgICAgICBmcm9tIHRoZSBy ZWNlaXZlciBoYXJkd2FyZSBmb3IgZWFjaCBwYWNrZXQuDQorICoNCisgKiBx dWFsLm5vaXNlICAgICAgIChyYW5nZSBpcyBtYXhfcXVhbC5ub2lzZSAtPiAw KSBub2lzZSBsZXZlbCBpbiBkQm0gdGFrZW4gZnJvbQ0KKyAqICAgICAgICAg ICAgICAgICAgdGhlIHJlY2VpdmVyIGhhcmR3YXJlIGZvciBlYWNoIHBhY2tl dC4gIElmIGhhcmR3YXJlDQorICogICAgICAgICAgICAgICAgICBkb2VzIG5v dCBwcm92aWRlIHRoaXMgdmFsdWUgZm9yIGVhY2ggcGFja2V0LCBzZXQgdG8g MCBhbmQNCisgKiAgICAgICAgICAgICAgICAgIHNldCAncXVhbC51cGRhdGVk IHw9IElXX1FVQUxfTk9JU0VfSU5WQUxJRCcuICBZb3UgbXVzdCB0aGVuDQor ICogICAgICAgICAgICAgICAgICBwcm92aWRlIGEgdmFsdWUgaW4gbWF4X3F1 YWwubm9pc2UgaW5zdGVhZC4NCisgKg0KKyAqIEluIHRoZSBkQm0gTUVUSE9E LCB2YWx1ZXMgYXJlIF9hbHdheXNfIG5lZ2F0aXZlIG51bWJlcnMgKG9yIDAp LiAgRXZlbiB0aG91Z2gNCisgKiB0aGUgYWN0dWFsIGZpZWxkcyB0aGVtc2Vs dmVzIGFyZSA4LWJpdCB1bnNpZ25lZCwgdGhlIG51bWJlcnMgYXJlIHRyZWF0 ZWQgYXMNCisgKiBuZWdhdGl2ZSwgd2hlcmUgMHgxMDAgPT0gMjU2ID09IDAu ICBWYWx1ZXMgYXJlIHBhc3NlZCB0byB1c2VyIGFwcGxpY2F0aW9ucw0KKyAq IGFmdGVyIGJlaW5nIGFkZGVkIHRvIDI1NiBpbiB0aGUgX2RyaXZlcl8uICBG b3IgZXhhbXBsZToNCisgKg0KKyAqICAgIC01NCBkQm0gPSAyMDIgICAoLTU0 IGRCbSArIDI1NiA9IDIwMikNCisgKiAgICAtMTA0IGRCbSA9IDE1MiAgKC0x MDQgZEJtICsgMjU2ID0gMTUyKQ0KKyAqDQorICovIA0KKw0KIC8qKioqKioq KioqKioqKioqKioqKioqKioqKioqIENPTlNUQU5UUyAqKioqKioqKioqKioq KioqKioqKioqKioqKioqLw0KIA0KIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIElPQ1RMIExJU1QgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g Ki8NCkBAIC0zNjAsNiArNDYyLDcgQEANCiAjZGVmaW5lIElXX01PREVfTU9O SVRPUgk2CS8qIFBhc3NpdmUgbW9uaXRvciAobGlzdGVuIG9ubHkpICovDQog DQogLyogU3RhdGlzdGljcyBmbGFncyAoYml0bWFzayBpbiB1cGRhdGVkKSAq Lw0KKy8qIFNlZSBhbHNvIFdJUkVMRVNTIFFVQUxJVFkgYWJvdmUgKi8NCiAj ZGVmaW5lIElXX1FVQUxfUVVBTF9VUERBVEVECTB4MQkvKiBWYWx1ZSB3YXMg dXBkYXRlZCBzaW5jZSBsYXN0IHJlYWQgKi8NCiAjZGVmaW5lIElXX1FVQUxf TEVWRUxfVVBEQVRFRAkweDINCiAjZGVmaW5lIElXX1FVQUxfTk9JU0VfVVBE QVRFRAkweDQNCkBAIC01MDAsNiArNjAzLDggQEANCiANCiAvKg0KICAqCVF1 YWxpdHkgb2YgdGhlIGxpbmsNCisgKg0KKyAqIFNlZSBXSVJFTEVTUyBRVUFM SVRZIGFib3ZlLg0KICAqLw0KIHN0cnVjdAlpd19xdWFsaXR5DQogew0KQEAg LTY1OCwxMCArNzYzLDEwIEBADQogDQogCS8qIFF1YWxpdHkgb2YgbGluayAm IFNOUiBzdHVmZiAqLw0KIAkvKiBRdWFsaXR5IHJhbmdlIChsaW5rLCBsZXZl bCwgbm9pc2UpDQotCSAqIElmIHRoZSBxdWFsaXR5IGlzIGFic29sdXRlLCBp dCB3aWxsIGJlIGluIHRoZSByYW5nZSBbMCA7IG1heF9xdWFsXSwNCi0JICog aWYgdGhlIHF1YWxpdHkgaXMgZEJtLCBpdCB3aWxsIGJlIGluIHRoZSByYW5n ZSBbbWF4X3F1YWwgOyAwXS4NCi0JICogRG9uJ3QgZm9yZ2V0IHRoYXQgd2Ug dXNlIDggYml0IGFyaXRobWV0aWNzLi4uICovDQorCSAqDQorCSAqIFNlZSBX SVJFTEVTUyBRVUFMSVRZIGFib3ZlLiAqLw0KIAlzdHJ1Y3QgaXdfcXVhbGl0 eQltYXhfcXVhbDsJLyogUXVhbGl0eSBvZiB0aGUgbGluayAqLw0KKw0KIAkv KiBUaGlzIHNob3VsZCBjb250YWluIHRoZSBhdmVyYWdlL3R5cGljYWwgdmFs dWVzIG9mIHRoZSBxdWFsaXR5DQogCSAqIGluZGljYXRvci4gVGhpcyBzaG91 bGQgYmUgdGhlIHRocmVzaG9sZCBiZXR3ZWVuIGEgImdvb2QiIGFuZA0KIAkg KiBhICJiYWQiIGxpbmsgKGV4YW1wbGUgOiBtb25pdG9yIGdvaW5nIGZyb20g Z3JlZW4gdG8gb3JhbmdlKS4NCg== --279707962-1533241267-1107571555=:4701-- From herbert@gondor.apana.org.au Fri Feb 4 21:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:25:30 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155PL1L028731 for ; Fri, 4 Feb 2005 21:25:22 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxIRC-0001Mj-00; Sat, 05 Feb 2005 16:24:54 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIQR-0004W4-00; Sat, 05 Feb 2005 16:24:07 +1100 Date: Sat, 5 Feb 2005 16:24:07 +1100 To: Mirko Parthey Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , YOSHIFUJI Hideaki , Stephen Hemminger Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205052407.GA17266@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3218 Lines: 92 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 31, 2005 at 04:22:02PM +0000, Mirko Parthey wrote: > > How to reproduce the problem (I tried this on a Pentium 4 machine): > > boot: linux init=/bin/bash > [...booting...] > # mount proc -t proc /proc > # ifconfig lo 127.0.0.1 > # brctl addbr br0 > # modprobe e100 # also reproducible with 3c5x9 > # brctl addif br0 eth0 > # ifconfig br0 192.168.1.1 > # ifconfig eth0 up > # ifconfig lo down This is the key to the problem. It took me a while to find the cause of this. Along the way I found a few other ref counting bugs in this area as well. All of these bugs stem from the idev reference held in rtable/rt6_info. Looking back in my mailbox, it's amazing how many problems this piece of infrastructure has caused since it was installed last June. AFAIK to this day there is still no code in the kernel that actually uses this infrastructure. Anyway, this particular problem is due to IPv6 adding local addresses with split devices. That is, routes to local addresses are added with rt6i_dev set to &loopback_dev and rt6i_idev set to the idev of the device where the address is added. This is just not going to work unless IPv6 creates its own dst garbage collection routine since the generic GC in net/core/dst.c has no way of finding all the rt6_info's referring to a specific net_device through rt6i_idev. It is also different from the IPv4 behaviour where we set both dev and idev to loopback_dev. Now this stuff is apparently going to be used for IP statistics. As it is packets sent to/received from local addresses are counted against the loopback device. Linux has behaved this way for a long time. So when these statistics actually get implemented it will be very strange if they were accounted to the device owning the local addresses instead of loopback. It also goes against the Linux philosophy where the addresses are owned by the host, not the interface. Therefore I propose the simple solution of not doing the split device accounting in rt6_info. Signed-off-by: Herbert Xu I will send the patches for the other bugs separately. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=q ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00 +++ edited/net/ipv6/route.c 2005-02-05 16:10:19 +11:00 @@ -1395,13 +1395,12 @@ return ERR_PTR(-ENOMEM); dev_hold(&loopback_dev); - in6_dev_hold(idev); rt->u.dst.flags = DST_HOST; rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = idev; + rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --dDRMvlgZJXvWKvBx-- From jm@jm.kir.nu Fri Feb 4 21:29:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:30:01 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155Trdu029244 for ; Fri, 4 Feb 2005 21:29:55 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CxITw-0003sZ-Vl; Fri, 04 Feb 2005 21:27:44 -0800 Date: Fri, 4 Feb 2005 21:27:44 -0800 From: Jouni Malinen To: Dan Williams Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification Message-ID: <20050205052744.GD9685@jm.kir.nu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1292 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: 4794 Lines: 94 On Fri, Feb 04, 2005 at 09:45:55PM -0500, Dan Williams wrote: > I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an > attempt to concretely specify what drivers need to do for quality. Nice to see more documentation on this area. I would consider moving this to somewhere else or adding a separate document (Documentation/networking/wireless/... ?) though, since I would hope to eventually see detailed (and in practice, quite long) explanation for all areas of the wireless extensions, not just signal quality. Comments in C header files may not be the nicest format for editing such specification.. > + * Explanation of WIRELESS QUALITY Maybe change that to wireless signal quality? > + * Wireless quality is may be measured in two methods, drivers must PICK ONE > + * and use it consistently throughout the driver->userspace API: Unfortunately, this may not be possible with some (well, maybe even most) hardware models. It is quite common to configure TX power in dBm and report signal strength for received frames in RSSI. Even if this part is left out and this is only about signal strength/quality of received frames, some cards have different mechanism for reporting quality for 1) received packets, 2) current BSS (average), 3) scan results. Another common example is in reporting received signal strength in RSSI and noise level in dBm. > + * 2) The second measure is decibel millivolts, or dBm. This is calculated from milliwatts (i.e., power, not potential) > + * the RSSI of each packet based on lookup tables or conversion constants > + * specified by each manufacturer. dBm is an absolute measurement of electrical > + * power generated by the radio signals in the receive circuitry of the card. > + * It is expressed in _negative_ numbers, where 0dBm = 1mV. The upper bound 1 mW > + * is _always_ 0, and the lower bound is determined by the receiver sensitivity When setting TX power, these numbers are (in most cases) positive, e.g., 16 dBm. Again, this could be considered to be outside the scope of this description, but should be kept in mind for other parts of wireless extensions. Another example would be non-802.11 wireless device that could potentially receive signals with higher power than 0 dBm.. > + * The 'qual' fields are method independent, and are specified as follows: > + * > + * max_qual.qual: (range is 0 -> 255) upper bound of subjective quality > + * levels. Other .qual fields MUST be less than this number. > + * > + * qual.qual: (range is 0 -> max_qual.qual) Quality of the received packet > + * as determined by the driver. The only restriction is that > + * user applications MUST be able to derive a percentage value > + * by doing the following calculation: > + * percent = 100 * (qual.qual / max_qual.qual) > + * Drivers may factor other statistics, such as receive packet > + * errors, # collisions, noise levels, etc, into the value. Is this restriction to linear value ok? Many other values are in logarithmic scale. What does this "percentage" really mean and what is it used for? The current wireless.h defines quality as percentage of retries or missed beacons, or SNR.. > + * Once a driver has PICKED ONE method of measurement, the quality fields must > + * be filled as follows. Remember, all fields are 8-bits wide and are treated > + * as signed or unsigned based on the method of quality measurement above. > + * > + * > + * RSSI METHOD (set max_qual.level > 0 as explained below) > + *-------------------------------------------------------- > + * max_qual.level: (range is 1 -> 255) upper bound of the RSSI of any received > + * packet, determined by the card's hardware. Usually > + * specified in technical literature from manufacturer, or > + * provided by registers on the card. > + * NOTE: to specify that values are in RSSI, max_qual.level > + * MUST be larger than 0. So, if the hardware reports RSSI in 0..70, both values 0 and 1 should be stored as 1? Actually, I've seen one hardware where reported RSSI values are dropping below zero every now and then.. > + * max_qual.noise: (range is 0 -> 255) lower bound of noise, ie the received Why is there a different range for noise? Is only max_qual.level used to select the RSSI/dBm method and this max_qual.noise would be, e.g., the current noise floor (which, btw, is often presented in dBm, not RSSI). Is this a new mechanism for reporting noise floor? I don't remember seeing this kind of definition before. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Fri Feb 4 21:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:31:19 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155VAl2029742 for ; Fri, 4 Feb 2005 21:31:11 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxIWx-0001Nu-00; Sat, 05 Feb 2005 16:30:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIWc-0004XY-00; Sat, 05 Feb 2005 16:30:30 +1100 Date: Sat, 5 Feb 2005 16:30:30 +1100 To: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [IPV4] Make loopback idev stick around Message-ID: <20050205053030.GA17412@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2307 Lines: 89 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: As it is when loopback_dev loses all of its IPv4 addresses its corresponding idev will be destroyed. Unfortunately as of last August route.c relies on the loopback idev to kill references to other idev objects. The end result is that when you do ip a f dev lo, unregistering other devices will hang until those dst objects referring to their idev objects die of natural causes. Of course this may never happen if the processes holding those references get dead-locked by invoking an operation that takes the RTNL. A simple solution is to make sure that loopback's idev sticks around all the time. Incidentally this also fixes the setting of some flags on the loopback idev object as currently the code that does it won't be called if you add the addresses to lo after bring it up. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=idev-1 ===== net/ipv4/devinet.c 1.42 vs edited ===== --- 1.42/net/ipv4/devinet.c 2005-01-11 08:43:25 +11:00 +++ edited/net/ipv4/devinet.c 2005-02-05 14:25:56 +11:00 @@ -187,6 +187,10 @@ ASSERT_RTNL(); + dev = in_dev->dev; + if (dev == &loopback_dev) + return; + in_dev->dead = 1; ip_mc_destroy_dev(in_dev); @@ -200,7 +204,6 @@ devinet_sysctl_unregister(&in_dev->cnf); #endif - dev = in_dev->dev; dev->ip_ptr = NULL; #ifdef CONFIG_SYSCTL @@ -943,8 +946,16 @@ ASSERT_RTNL(); - if (!in_dev) + if (!in_dev) { + if (event == NETDEV_REGISTER && dev == &loopback_dev) { + in_dev = inetdev_init(dev); + if (!in_dev) + panic("devinet: Failed to create loopback\n"); + in_dev->cnf.no_xfrm = 1; + in_dev->cnf.no_policy = 1; + } goto out; + } switch (event) { case NETDEV_REGISTER: @@ -967,8 +978,6 @@ memcpy(ifa->ifa_label, dev->name, IFNAMSIZ); inet_insert_ifa(ifa); } - in_dev->cnf.no_xfrm = 1; - in_dev->cnf.no_policy = 1; } ip_mc_up(in_dev); break; --AhhlLboLdkugWU4S-- From herbert@gondor.apana.org.au Fri Feb 4 21:35:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:35:53 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155ZkQa030273 for ; Fri, 4 Feb 2005 21:35:47 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxIba-0001PQ-00; Sat, 05 Feb 2005 16:35:38 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIbU-0004f5-00; Sat, 05 Feb 2005 16:35:32 +1100 Date: Sat, 5 Feb 2005 16:35:32 +1100 To: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [IPV4] Make loopback idev stick around Message-ID: <20050205053532.GA17474@gondor.apana.org.au> References: <20050205053030.GA17412@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20050205053030.GA17412@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1683 Lines: 63 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Feb 05, 2005 at 04:30:30PM +1100, herbert wrote: > > As it is when loopback_dev loses all of its IPv4 addresses its > corresponding idev will be destroyed. Unfortunately as of last > August route.c relies on the loopback idev to kill references > to other idev objects. The same problem exists for IPv6. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=idev-2 ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 08:13:31 +11:00 +++ edited/net/ipv6/addrconf.c 2005-02-05 16:32:34 +11:00 @@ -1914,6 +1914,11 @@ struct inet6_dev *idev = __in6_dev_get(dev); switch(event) { + case NETDEV_REGISTER: + if (dev == &loopback_dev && !ipv6_find_idev(dev)) + panic("addrconf: Failed to create loopback\n"); + break; + case NETDEV_UP: switch(dev->type) { case ARPHRD_SIT: @@ -1998,6 +2003,9 @@ ASSERT_RTNL(); + if (dev == &loopback_dev) + how = 0; + rt6_ifdown(dev); neigh_ifdown(&nd_tbl, dev); @@ -3445,8 +3453,6 @@ */ rtnl_lock(); addrconf_notify(&ipv6_dev_notf, NETDEV_REGISTER, &loopback_dev); - if (loopback_dev.flags & IFF_UP) - addrconf_notify(&ipv6_dev_notf, NETDEV_UP, &loopback_dev); rtnl_unlock(); register_netdevice_notifier(&ipv6_dev_notf); --wRRV7LY7NUeQGEoC-- From davem@davemloft.net Fri Feb 4 21:45:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:46:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155jwHF031038 for ; Fri, 4 Feb 2005 21:45:58 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxIe5-00013M-00; Fri, 04 Feb 2005 21:38:13 -0800 Date: Fri, 4 Feb 2005 21:38:13 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050204213813.4bd642ad.davem@davemloft.net> In-Reply-To: <20050205052407.GA17266@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 37 On Sat, 5 Feb 2005 16:24:07 +1100 Herbert Xu wrote: > This is the key to the problem. ... > All of these bugs stem from the idev reference held in rtable/rt6_info. ... > Anyway, this particular problem is due to IPv6 adding local addresses > with split devices. That is, routes to local addresses are added with > rt6i_dev set to &loopback_dev and rt6i_idev set to the idev of the > device where the address is added. ... > It also goes against the Linux philosophy where the addresses are owned > by the host, not the interface. > > Therefore I propose the simple solution of not doing the split device > accounting in rt6_info. I agree with your analysis, however... this change is not sufficient. You have to then walk over all the uses of rt6i_dev and sanitize the cases that still expect the split semantics. For example, things like this piece of coe in rt6_device_match(): if (dev->flags & IFF_LOOPBACK) { if (sprt->rt6i_idev == NULL || sprt->rt6i_idev->dev->ifindex != oif) { if (strict && oif) continue; if (local && (!oif || local->rt6i_idev->dev->ifindex == oif)) continue; } local = sprt; } It is just the first such thing I found, scanning rt6i_idev uses will easily find several others. From dcbw@redhat.com Fri Feb 4 22:06:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:06:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1566km6031887 for ; Fri, 4 Feb 2005 22:06:47 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1564gg6008742; Sat, 5 Feb 2005 01:04:42 -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 j1564gO05847; Sat, 5 Feb 2005 01:04:42 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j1564gxr012922; Sat, 5 Feb 2005 01:04:42 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j1564gwh012918; Sat, 5 Feb 2005 01:04:42 -0500 Date: Sat, 5 Feb 2005 01:04:42 -0500 (EST) From: Dan Williams To: Jouni Malinen cc: Dan Williams , jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification In-Reply-To: <20050205052744.GD9685@jm.kir.nu> Message-ID: References: <20050205052744.GD9685@jm.kir.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 8584 Lines: 155 On Fri, 4 Feb 2005, Jouni Malinen wrote: > On Fri, Feb 04, 2005 at 09:45:55PM -0500, Dan Williams wrote: > > > I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an > > attempt to concretely specify what drivers need to do for quality. > > Nice to see more documentation on this area. I would consider moving > this to somewhere else or adding a separate document > (Documentation/networking/wireless/... ?) though, since I would hope to > eventually see detailed (and in practice, quite long) explanation for > all areas of the wireless extensions, not just signal quality. Comments > in C header files may not be the nicest format for editing such > specification.. > > > + * Explanation of WIRELESS QUALITY > > Maybe change that to wireless signal quality? > > > + * Wireless quality is may be measured in two methods, drivers must PICK ONE > > + * and use it consistently throughout the driver->userspace API: > > Unfortunately, this may not be possible with some (well, maybe even > most) hardware models. It is quite common to configure TX power in dBm > and report signal strength for received frames in RSSI. Even if this > part is left out and this is only about signal strength/quality of > received frames, some cards have different mechanism for reporting > quality for 1) received packets, 2) current BSS (average), 3) scan > results. Another common example is in reporting received signal strength > in RSSI and noise level in dBm. Note that I understand that determining a % value for "signal quality" is quite subjective, but the idea here is be able to give users a "your connection is x%" value (qual.qual), _in addition_ to being able to give them raw signal strength values (qual.level/qual.noise). At this point we're just talking about received signal quality/level. The point here is that there are two different "types" of quality that the driver must report, (1) subjective signal quality (qual.qual), and (2) electrical signal levels (qual.level). WRT the different mechanisms, there _needs_ to be consistency among drivers. Otherwise, user-space applications are left to guess what the heck each and every driver is using for units. Which just doesn't work. For your signal mechanisms, there is a place for all of them. But there needs to be consistency between 2 & 3. In the current WEXT API, there is no ability to set separate max quality & signal levels for each, there is only one max signal & quality level structure. Reporting received signal strength in RSSI and noise level in dBm won't really work well. Manufacturers usually provide an RSSI->dBm conversion, but where they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, there is no way for user applications to know the bounds of these values and determine a signal quality % from them. Again, this is all about consistency, and we need a stable, well-defined API that doesn't depend on user-applications special-casing drivers just to get usable information out of them. If the driver cannot provide usable information of some sort, it shouldn't even be trying to provide that information at all really. > > + * 2) The second measure is decibel millivolts, or dBm. This is calculated from > > milliwatts (i.e., power, not potential) Correct, it was late :) My mistake. > > + * is _always_ 0, and the lower bound is determined by the receiver sensitivity > > When setting TX power, these numbers are (in most cases) positive, e.g., > 16 dBm. Again, this could be considered to be outside the scope of this > description, but should be kept in mind for other parts of wireless > extensions. Another example would be non-802.11 wireless device that > could potentially receive signals with higher power than 0 dBm.. Again, we're not talking about TX power yet... The non-802.11 point is valid, but at this time WEXT is so geared toward 802.11 devices that more significant changes would need to take place to apply WEXT to them. I'm not sure that time has come yet. > > > + * The 'qual' fields are method independent, and are specified as follows: > > + * > > + * max_qual.qual: (range is 0 -> 255) upper bound of subjective quality > > + * levels. Other .qual fields MUST be less than this number. > > + * > > + * qual.qual: (range is 0 -> max_qual.qual) Quality of the received packet > > + * as determined by the driver. The only restriction is that > > + * user applications MUST be able to derive a percentage value > > + * by doing the following calculation: > > + * percent = 100 * (qual.qual / max_qual.qual) > > + * Drivers may factor other statistics, such as receive packet > > + * errors, # collisions, noise levels, etc, into the value. > > Is this restriction to linear value ok? Many other values are in > logarithmic scale. What does this "percentage" really mean and what is > it used for? The current wireless.h defines quality as percentage of > retries or missed beacons, or SNR.. qual.qual must be linear (because it should be able to be converted to a percentage value, its a _subjective_ measure of quality composed of a number of different quality statistics). qual.level & qual.noise may not necessarily be linear since they are measures of electrical power (either RSSI or dBm). > > > + * Once a driver has PICKED ONE method of measurement, the quality fields must > > + * be filled as follows. Remember, all fields are 8-bits wide and are treated > > + * as signed or unsigned based on the method of quality measurement above. > > + * > > + * > > + * RSSI METHOD (set max_qual.level > 0 as explained below) > > + *-------------------------------------------------------- > > + * max_qual.level: (range is 1 -> 255) upper bound of the RSSI of any received > > + * packet, determined by the card's hardware. Usually > > + * specified in technical literature from manufacturer, or > > + * provided by registers on the card. > > + * NOTE: to specify that values are in RSSI, max_qual.level > > + * MUST be larger than 0. > > So, if the hardware reports RSSI in 0..70, both values 0 and 1 should be > stored as 1? Actually, I've seen one hardware where reported RSSI values > are dropping below zero every now and then.. The current WEXT API provides _no_ way to specify whether the returned values are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've brought that up with Jean and he's agreed that it may need some clarification. There isn't really a "qual.type = dBm" bit anywhere in the quality structures, though that would be quite helpful (and was my suggestion). But here we're talking about max_qual.level, remember its the upper bound and will never have a value of 0. If the card's MAX_RSSI is 0, something is horribly wrong with the card since that indicates that it cannot receieve any signal at all. If the card actually has an interesting max_qual.level in dBm (say, -10 dBm), we cannot encode that value using WEXT at this time. > > > + * max_qual.noise: (range is 0 -> 255) lower bound of noise, ie the received > > Why is there a different range for noise? Is only max_qual.level used to > select the RSSI/dBm method and this max_qual.noise would be, e.g., the > current noise floor (which, btw, is often presented in dBm, not RSSI). > Is this a new mechanism for reporting noise floor? I don't remember > seeing this kind of definition before. See above, technically you could have a noise floor of 0 I guess, and the current WEXT API has no way of specifying different units for use in noise and level at this time. Hence, the noise value can actually mean something when using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). This is really an attempt to clarify the rules as I understand them (and after a couple discussions with Jean about the quality stuff). I've looked over almost every wireless/802.11 driver that exists for Linux, and none of them implement the standard correctly, probably becuase its a bit ambiguous and nobody could quite understand what they were supposed to do in the quality space. We need to bring some coherency to drivers in this regard, if only so that people can get their pretty little signal bars in the UI. Dan From herbert@gondor.apana.org.au Fri Feb 4 22:11:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:12:03 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156BrnQ032592 for ; Fri, 4 Feb 2005 22:11:54 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxJAL-0001YM-00; Sat, 05 Feb 2005 17:11:33 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJ9y-0004qB-00; Sat, 05 Feb 2005 17:11:10 +1100 Date: Sat, 5 Feb 2005 17:11:10 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205061110.GA18275@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20050204213813.4bd642ad.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4003 Lines: 129 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > > It is just the first such thing I found, scanning rt6i_idev uses > will easily find several others. You're right of course. I thought they were all harmless but I was obviously wrong about this one. So here is a patch that essentially reverts the split devices semantics introduced by these two changesets: [IPV6] addrconf_dst_alloc() to allocate new route for local address. [IPV6] take rt6i_idev into account when looking up routes. Signed-off-by: Herbert Xu ~{PmV>HI~} Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/ip6_route.h 1.21 vs edited ===== --- 1.21/include/net/ip6_route.h 2004-10-26 14:27:49 +10:00 +++ edited/include/net/ip6_route.h 2005-02-05 17:02:36 +11:00 @@ -74,8 +74,7 @@ extern int ndisc_dst_gc(int *more); extern void fib6_force_start_gc(void); -extern struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev, - const struct in6_addr *addr, +extern struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr, int anycast); /* ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 08:13:31 +11:00 +++ edited/net/ipv6/addrconf.c 2005-02-05 17:02:00 +11:00 @@ -509,7 +509,7 @@ goto out; } - rt = addrconf_dst_alloc(idev, addr, 0); + rt = addrconf_dst_alloc(addr, 0); if (IS_ERR(rt)) { err = PTR_ERR(rt); goto out; ===== net/ipv6/anycast.c 1.19 vs edited ===== --- 1.19/net/ipv6/anycast.c 2005-01-15 08:30:07 +11:00 +++ edited/net/ipv6/anycast.c 2005-02-05 17:01:47 +11:00 @@ -340,7 +340,7 @@ goto out; } - rt = addrconf_dst_alloc(idev, addr, 1); + rt = addrconf_dst_alloc(addr, 1); if (IS_ERR(rt)) { kfree(aca); err = PTR_ERR(rt); ===== net/ipv6/ip6_fib.c 1.34 vs edited ===== --- 1.34/net/ipv6/ip6_fib.c 2005-01-14 15:41:06 +11:00 +++ edited/net/ipv6/ip6_fib.c 2005-02-05 17:04:02 +11:00 @@ -450,7 +450,6 @@ */ if (iter->rt6i_dev == rt->rt6i_dev && - iter->rt6i_idev == rt->rt6i_idev && ipv6_addr_equal(&iter->rt6i_gateway, &rt->rt6i_gateway)) { if (!(iter->rt6i_flags&RTF_EXPIRES)) ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00 +++ edited/net/ipv6/route.c 2005-02-05 17:01:23 +11:00 @@ -189,17 +189,8 @@ struct net_device *dev = sprt->rt6i_dev; if (dev->ifindex == oif) return sprt; - if (dev->flags & IFF_LOOPBACK) { - if (sprt->rt6i_idev == NULL || - sprt->rt6i_idev->dev->ifindex != oif) { - if (strict && oif) - continue; - if (local && (!oif || - local->rt6i_idev->dev->ifindex == oif)) - continue; - } + if (dev->flags & IFF_LOOPBACK) local = sprt; - } } if (local) @@ -1385,8 +1376,7 @@ * Allocate a dst for local (unicast / anycast) address. */ -struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev, - const struct in6_addr *addr, +struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr, int anycast) { struct rt6_info *rt = ip6_dst_alloc(); @@ -1395,13 +1385,12 @@ return ERR_PTR(-ENOMEM); dev_hold(&loopback_dev); - in6_dev_hold(idev); rt->u.dst.flags = DST_HOST; rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = idev; + rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --5vNYLRcllDrimb99-- From rddunlap@osdl.org Fri Feb 4 22:17:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:17:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156HAkJ000652 for ; Fri, 4 Feb 2005 22:17:11 -0800 Received: from [192.168.1.103] (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j156H1uM020874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Feb 2005 22:17:03 -0800 Message-ID: <420462BC.6010903@osdl.org> Date: Fri, 04 Feb 2005 22:07:56 -0800 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1298 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: 3956 Lines: 126 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) > > Support for HW/FW crypto and fragmentation offload, in a HW independent > fashion, is also on the short-term list. > > When you look through the patch you'll likely notice the #ifdef > NOTYET/#endif sequences surrounding portions of code from the hostap > project. Portions of this subsystem were based on an earlier version of > the hostap project. Those areas that weren't directly supported by the > ipw* projects weren't ported to be completely hardware independent > (since I don't have the hardware to test it), and so are still wrapped > in the ifdefs. These sections mainly cover support for MASTER and WDS > modes. > > Anyway, please let me know what you think. Hopefully I built the patch > right... It applies fine. A few comments: 1. config IEEE80211_DEBUG bool "Enable full debugging output" depends on IEEE80211 + /proc/net/ieee80211/debug_level + + For example: + + % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level I get the impression that one of these file names is incorrect: /proc vs. /sys..... + % . idvals + + From within drivers/net/wireless/ipw2200 Is there some good place for this other than in drivers/net/wireless? I don't know. + If you are not trying to debug or develop the IPW2200 driver, + you + most likely want to say N here. Combine those last 2 lines. 2. This can be compiled as a modules and it will be called + "ieee80211_crypt.ko". Don't use the ".ko" suffix at all (anywhere). 3. +static int __init ieee80211_crypto_init(void) + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); That register call can fail, so I'd rather see it checked, as in all of the other similar register calls. 4. +static void * ieee80211_ccmp_init(int key_idx) + if (priv == NULL) { + goto fail; + } Lose the braces. Same for: ieee80211_ccmp_init() 5. +static void ccmp_init_blocks() + /* CCM Initial Block: + * Flag (Include authentication header, M=3 (8-octet MIC), + * L=1 (2-octet Dlen)) + * Nonce: 0x00 | A2 | PN + * Dlen */ Kernel long comment style begins with "/*" by itself and ends with "*/" by itself. 6. +struct ieee80211_ccmp_data { + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; Are these MIB-mandated names? otherwise the studlyCaps should go. 7. +static int ieee80211_ccmp_decrypt() Does anything care about the various negative/error case return values? 8. What calls the .print_stats functions? static char * ieee80211_ccmp_print_stats() Is it possible to use seq_file there instead of sprintf(), or is this in /sysfs (so seq_file is not possible)? Are there any overflow possibilities? Enough for tonight... -- ~Randy From davem@davemloft.net Fri Feb 4 22:21:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:21:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156LFLe001310 for ; Fri, 4 Feb 2005 22:21:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxJCS-0001E6-00; Fri, 04 Feb 2005 22:13:44 -0800 Date: Fri, 4 Feb 2005 22:13:44 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050204221344.247548cb.davem@davemloft.net> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1254 Lines: 34 On Sat, 5 Feb 2005 17:11:10 +1100 Herbert Xu wrote: > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: > > [IPV6] addrconf_dst_alloc() to allocate new route for local address. > [IPV6] take rt6i_idev into account when looking up routes. > > Signed-off-by: Herbert Xu ~{PmV>HI~} Ok. But Herbert, let's take a step back real quick because I want to point something out. IPv6 does try to handle the dangling mismatched idev's, in route.c:ip6_dst_ifdown(), this is called via net/core/dst.c:dst_ifdown(), and this releases the ipv6 idev correctly in the split device case. Did your analysis of this bridging release bug take this into account? That's why we added this dst->ops method, specifically to handle this problem. This was added by Yoshifuji-san in ChangeSet 1.1722.137.17 which has the checking comment: [NET]: Add dst->ifdown callback. Use it to release protocol specific objects that may be tied to a dst cache object, at ifdown time. Currently this is used to release ipv4/ipv6 specific device state. From davem@davemloft.net Fri Feb 4 22:32:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:32:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156W6gc001905 for ; Fri, 4 Feb 2005 22:32:07 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxJMq-0001FW-00; Fri, 04 Feb 2005 22:24:28 -0800 Date: Fri, 4 Feb 2005 22:24:28 -0800 From: "David S. Miller" To: "David S. Miller" Cc: herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050204222428.1a13a482.davem@davemloft.net> In-Reply-To: <20050204154855.79340cdb.davem@davemloft.net> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 11885 Lines: 350 On Fri, 4 Feb 2005 15:48:55 -0800 "David S. Miller" wrote: > Something like that. I'll update the atomic_ops.txt > doc and post and updated version later tonight. Ok, as promised, here is the updated doc. Who should I author this as? Perhaps "Anton's evil twin" :-) --- atomic_ops.txt --- This document is intended to serve as a guide to Linux port maintainers on how to implement atomic counter and bitops operations properly. The atomic_t type should be defined as a signed integer. Also, it should be made opaque such that any kind of cast to a normal C integer type will fail. Something like the following should suffice: typedef struct { volatile int counter; } atomic_t; The first operations to implement for atomic_t's are the initializers and plain reads. #define ATOMIC_INIT(i) { (i) } #define atomic_set(v, i) ((v)->counter = (i)) The first macro is used in definitions, such as: static atomic_t my_counter = ATOMIC_INIT(1); The second interface can be used at runtime, as in: k = kmalloc(sizeof(*k), GFP_KERNEL); if (!k) return -ENOMEM; atomic_set(&k->counter, 0); Next, we have: #define atomic_read(v) ((v)->counter) which simply reads the current value of the counter. Now, we move onto the actual atomic operation interfaces. void atomic_add(int i, atomic_t *v); void atomic_sub(int i, atomic_t *v); void atomic_inc(atomic_t *v); void atomic_dec(atomic_t *v); These four routines add and subtract integral values to/from the given atomic_t value. The first two routines pass explicit integers by which to make the adjustment, whereas the latter two use an implicit adjustment value of "1". One very important aspect of these two routines is that they DO NOT require any explicit memory barriers. They need only perform the atomic_t counter update in an SMP safe manner. Next, we have: int atomic_inc_return(atomic_t *v); int atomic_dec_return(atomic_t *v); These routines add 1 and subtract 1, respectively, from the given atomic_t and return the new counter value after the operation is performed. Unlike the above routines, it is required that explicit memory barriers are performed before and after the operation. It must be done such that all memory operations before and after the atomic operation calls are strongly ordered with respect to the atomic operation itself. For example, it should behave as if a smp_mb() call existed both before and after the atomic operation. If the atomic instructions used in an implementation provide explicit memory barrier semantics which satisfy the above requirements, that is fine as well. Let's move on: int atomic_add_return(int i, atomic_t *v); int atomic_sub_return(int i, atomic_t *v); These behave just like atomic_{inc,dec}_return() except that an explicit counter adjustment is given instead of the implicit "1". This means that like atomic_{inc,dec}_return(), the memory barrier semantics are required. Next: int atomic_inc_and_test(atomic_t *v); int atomic_dec_and_test(atomic_t *v); These two routines increment and decrement by 1, respectively, the given atomic counter. They return a boolean indicating whether the resulting counter value was zero or not. It requires explicit memory barrier semantics around the operation as above. int atomic_sub_and_test(int i, atomic_t *v); This is identical to atomic_dec_and_test() except that an explicit decrement is given instead of the implicit "1". It requires explicit memory barrier semantics around the operation. int atomic_add_negative(int i, atomic_t *v); The given increment is added to the given atomic counter value. A boolean is return which indicates whether the resulting counter value is negative. It requires explicit memory barrier semantics around the operation. If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: void smb_mb__before_atomic_dec(void); void smb_mb__after_atomic_dec(void); void smb_mb__before_atomic_inc(void); void smb_mb__after_atomic_dec(void); For example, smb_mb__before_atomic_dec() can be used like so: obj->dead = 1; smb_mb__before_atomic_dec(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceeding the atomic_dec() call are strongly ordered with respect to the atomic counter operation. In the above example, it guarentees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. Without the explicitl smb_mb__before_atomic_dec() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. The other three interfaces listed are used to provide explicit ordering with respect to memory operations after an atomic_dec() call (smb_mb__after_atomic_dec()) and around atomic_inc() calls (smb_mb__{before,after}_atomic_inc()). A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disasterous results. Here is an example, which follows a pattern occuring frequently in the Linux kernel. It is the use of atomic counters to implement reference counting, and it works such that once the counter falls to zero it can be guarenteed that no other entity can be accessing the object: static void obj_list_add(struct obj *obj) { obj->active = 1; list_add(&obj->list); } static void obj_list_del(struct obj *obj) { list_del(&obj->list); obj->active = 0; } static void obj_destroy(struct obj *obj) { BUG_ON(obj->active); kfree(obj); } struct obj *obj_list_peek(struct list_head *head) { if (!list_empty(head)) { struct obj *obj; obj = list_entry(head->next, struct obj, list); atomic_inc(&obj->refcnt); return obj; } return NULL; } void obj_poke(void) { struct obj *obj; spin_lock(&global_list_lock); obj = obj_list_peek(&global_list); spin_unlock(&global_list_lock); if (obj) { obj->ops->poke(obj); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } } void obj_timeout(struct obj *obj) { spin_lock(&global_list_lock); obj_list_del(obj); spin_unlock(&global_list_lock); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } (This is a simplification of the ARP queue management in the generic neighbour discover code of the networking. Olaf Kirch found a bug wrt. memory barriers in kfree_skb() that exposed the atomic_t memory barrier requirements quite clearly.) Given the above scheme, it must be the case that the obj->active update done by the obj list deletion be visible to other processors before the atomic counter decrement is performed. Otherwise, the counter could fall to zero, yet obj->active would still be set, thus triggering the assertion in obj_destroy(). The error sequence looks like this: cpu 0 cpu 1 obj_poke() obj_timeout() obj = obj_list_peek(); ... gains ref to obj, refcnt=2 obj_list_del(obj); obj->active = 0 ... ... visibility delayed ... atomic_dec_and_test() ... refcnt drops to 1 ... atomic_dec_and_test() ... refcount drops to 0 ... obj_destroy() BUG() triggers since obj->active still seen as one obj->active update visibility occurs With the memory barrier semantics required of the atomic_t operations which return values, the above sequence of memory visibility can never happen. Specifically, in the above case the atomic_dec_and_test() counter decrement would not become globally visible until the obj->active update does. We will now cover the atomic bitmask operations. You will find that their SMP and memory barrier semantics are similar in shape and scope to the atomic_t ops above. Native atomic bit operations are defined to operate on objects aligned to the size of an "unsigned long" C data type, and are least of that size. The endianness of the bits within each "unsigned long" are the native endianness of the cpu. void set_bit(unsigned long nr, volatils unsigned long *addr); void clear_bit(unsigned long nr, volatils unsigned long *addr); void change_bit(unsigned long nr, volatils unsigned long *addr); These routines set, clear, and change, respectively, the bit number indicated by "nr" on the bit mask pointed to by "ADDR". They must execute atomically, yet there are no implicit memory barrier semantics required of these interfaces. long test_and_set_bit(unsigned long nr, volatils unsigned long *addr); long test_and_clear_bit(unsigned long nr, volatils unsigned long *addr); long test_and_change_bit(unsigned long nr, volatils unsigned long *addr); Like the above, except that these routines return a boolean which indicates whether the changed bit was set _BEFORE_ the atomic bit operation. WARNING! It is incredibly important that the value be a boolean, ie. "0" or "1". Do not try to be fancy and save a few instructions by just returning something like "old_val & mask" because that will not work. For one thing, this return value gets truncated to int in many code paths, so on 64-bit if the bit is set in the upper 32-bits then testers will never see that. One great example of where this problem crops up are the thread_info flag operations. Routines such as test_and_set_ti_thread_flag() chop the return value into an int. There are other places where things like this occur as well. These routines, like the atomic_t counter operations returning values, require explicit memory barrier semantics around their execution. All memory operations before the atomic bit operation call must be made visible globally before the atomic bit operation is made visible. Likewise, the atomic bit operation must be visible globally before any subsequent memory operation is made visible. For example: obj->dead = 1; if (test_and_set_bit(0, &obj->flags)) /* ... */; obj->killed = 1; The implementation of test_and_set_bit() must guarentee that "obj->dead = 1;" is visible to cpus before the atomic memory operation done by test_and_set_bit() becomes visible. Likewise, the atomic memory operation done by test_and_set_bit() must become visible before "obj->killed = 1;" is visible. Finally there is the basic operation: long test_bit(unsigned long nr, __const__ volatile unsigned long *addr); Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". If explicit memory barriers are required around clear_bit() (which does not return a value, and thus does not need to provide memory barrier semantics), two interfaces are provided: void smp_mb__before_clear_bit(void); void smp_mb__after_clear_bit(void); They are used as follows, and are akin to their atomic_t operation brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ smp_mb__before_clear_bit(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ smp_mb__after_clear_bit(); Finally, there are non-atomic versions of the bitmask operations provided. They are used in contexts where some other higher-level SMP locking scheme is being used to protect the bitmask, and thus less expensive non-atomic operations may be used in the implementation. They have names similar to the above bitmask operation interfaces, except that two underscores are prefixed to the interface name. void __set_bit(unsigned long nr, volatile unsigned long *addr); void __clear_bit(unsigned long nr, volatile unsigned long *addr); void __change_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_set_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_change_bit(unsigned long nr, volatile unsigned long *addr); These non-atomic variants also do not require any special memory barrier semantics. From jm@jm.kir.nu Fri Feb 4 22:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:41:03 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156ewRA002527 for ; Fri, 4 Feb 2005 22:40:59 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CxJao-0003ym-OY; Fri, 04 Feb 2005 22:38:54 -0800 Date: Fri, 4 Feb 2005 22:38:54 -0800 From: Jouni Malinen To: Dan Williams Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification Message-ID: <20050205063854.GE9685@jm.kir.nu> References: <20050205052744.GD9685@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1301 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: 3358 Lines: 57 On Sat, Feb 05, 2005 at 01:04:42AM -0500, Dan Williams wrote: > Reporting received signal strength in RSSI and noise level in dBm won't really > work well. Manufacturers usually provide an RSSI->dBm conversion, but where > they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, > there is no way for user applications to know the bounds of these values and > determine a signal quality % from them. Again, this is all about consistency, > and we need a stable, well-defined API that doesn't depend on user-applications > special-casing drivers just to get usable information out of them. If the > driver cannot provide usable information of some sort, it shouldn't even be > trying to provide that information at all really. Agreed, there should be no special cases based on driver in user space. However, the API definition should not make it too difficult for the drivers to implement the interface. If many cards use dBm for noise and RSSI for received frames, it would sound like the API definition should take this into account and not require the drivers either not to report values or do some conversion which may not always be that clear. > qual.qual must be linear (because it should be able to be converted to a > percentage value, its a _subjective_ measure of quality composed of a number of > different quality statistics). qual.level & qual.noise may not necessarily be > linear since they are measures of electrical power (either RSSI or dBm). How would this value be determined for cards that have RSSI for received packets and noise floor in dBm? Using a table of values? > The current WEXT API provides _no_ way to specify whether the returned values > are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and > max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've > brought that up with Jean and he's agreed that it may need some clarification. > There isn't really a "qual.type = dBm" bit anywhere in the quality structures, > though that would be quite helpful (and was my suggestion). > See above, technically you could have a noise floor of 0 I guess, and the > current WEXT API has no way of specifying different units for use in noise and > level at this time. Hence, the noise value can actually mean something when > using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). Isn't the 'max_qual.level == 0 means dBm' similar to saying 'max_qual.noise == 0 means dBm' for noise. In other words, max_qual.level == 70 and max_qual.noise == 0 could mean RSSI for signal strength and dBm for noise. Using max_qual.noise to report global noise value (noise floor?) sound somewhat confusing. > This is really an attempt to clarify the rules as I understand them (and after a > couple discussions with Jean about the quality stuff). I've looked over almost > every wireless/802.11 driver that exists for Linux, and none of them > implement the standard correctly, probably becuase its a bit ambiguous and > nobody could quite understand what they were supposed to do in the quality > space. We need to bring some coherency to drivers in this regard, if only so > that people can get their pretty little signal bars in the UI. Agreed. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Fri Feb 4 22:47:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:47:32 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156lN6W003075 for ; Fri, 4 Feb 2005 22:47:24 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxJij-0001ry-00; Sat, 05 Feb 2005 17:47:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJiN-0007kl-00; Sat, 05 Feb 2005 17:46:43 +1100 Date: Sat, 5 Feb 2005 17:46:43 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205064643.GA29758@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204221344.247548cb.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1550 Lines: 36 On Fri, Feb 04, 2005 at 10:13:44PM -0800, David S. Miller wrote: > > But Herbert, let's take a step back real quick because I want > to point something out. IPv6 does try to handle the dangling > mismatched idev's, in route.c:ip6_dst_ifdown(), this is called > via net/core/dst.c:dst_ifdown(), and this releases the ipv6 > idev correctly in the split device case. > > Did your analysis of this bridging release bug take this into > account? That's why we added this dst->ops method, specifically > to handle this problem. This doesn't work because net/core/dst.c can only search based on dst->dev. For the split device case, dst->dev is set to loopback_dev while rt6i_idev is set to the real device. Therefore net/core/dst.c stands no chance of finding the correct local address routes that it needs to process. If we wanted to preserve the split device semantics, then we can create a local GC list in IPv6 so that it can search based on rt6i_idev as well as the other keys. Alternatively we can remove the dst->dev == dev check in dst_dev_event and dst_ifdown and move that test down to the individual ifdown functions. However, IMHO the split device semantics is inconsistent with the philosphy that addresses belong to the host and not the interface. So it doesn't really make sense in the current networking stack. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Feb 4 22:51:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:51:46 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156peIw003615 for ; Fri, 4 Feb 2005 22:51:41 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxJmp-0001ta-00; Sat, 05 Feb 2005 17:51:19 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJmL-0007lO-00; Sat, 05 Feb 2005 17:50:49 +1100 Date: Sat, 5 Feb 2005 17:50:49 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050205065049.GB29758@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204222428.1a13a482.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 353 Lines: 10 On Fri, Feb 04, 2005 at 10:24:28PM -0800, David S. Miller wrote: > > Ok, as promised, here is the updated doc. Who should Looks good David. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From SRS0+e0c8477f4186490ff880+531+infradead.org+hch@pentafluge.srs.infradead.org Sat Feb 5 00:13:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 00:13:31 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j158DLiN005492 for ; Sat, 5 Feb 2005 00:13:24 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1CxL4C-0008SW-JH; Sat, 05 Feb 2005 08:13:20 +0000 Date: Sat, 5 Feb 2005 08:13:20 +0000 From: Christoph Hellwig To: James Ketrenos Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050205081320.GA32490@infradead.org> References: <4203C32A.70402@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203C32A.70402@linux.intel.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 97 Lines: 3 haven't looked ar the code much yet, but I think this should go under net/ and not drivers/net/ From herbert@gondor.apana.org.au Sat Feb 5 02:47:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 02:47:16 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15Al5Ou014693 for ; Sat, 5 Feb 2005 02:47:06 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxNSS-0002rT-00; Sat, 05 Feb 2005 21:46:32 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxNRv-000840-00; Sat, 05 Feb 2005 21:45:59 +1100 Date: Sat, 5 Feb 2005 21:45:59 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205104559.GA30981@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 679 Lines: 16 On Sat, Feb 05, 2005 at 05:46:43PM +1100, herbert wrote: > > This doesn't work because net/core/dst.c can only search based > on dst->dev. For the split device case, dst->dev is set to > loopback_dev while rt6i_idev is set to the real device. Although I still think this is a bug, I'm now starting to suspect that there is another bug around as well. There is probably an ifp leak which in turn leads to a split dst leak that allows the first bug to make its mark. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Sat Feb 5 02:49:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 02:49:46 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15AngdL015059 for ; Sat, 5 Feb 2005 02:49:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 47E1633CC2; Sat, 5 Feb 2005 19:50:41 +0900 (JST) Date: Sat, 05 Feb 2005 19:50:39 +0900 (JST) Message-Id: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1306 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: 607 Lines: 15 In article <20050205064643.GA29758@gondor.apana.org.au> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu says: > If we wanted to preserve the split device semantics, then we > can create a local GC list in IPv6 so that it can search based > on rt6i_idev as well as the other keys. Alternatively we can > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > and move that test down to the individual ifdown functions. Yes, IPv6 needs "split device" semantics (for per-device statistics such as Ip6InDelivers etc), and I like later solution. Thanks. --yoshfuji From andre@tomt.net Sat Feb 5 03:14:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:14:14 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15BE8dn016320 for ; Sat, 5 Feb 2005 03:14:08 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id B05AB884FC; Sat, 5 Feb 2005 12:14:06 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id B8673884ED; Sat, 5 Feb 2005 12:14:04 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 27A4422895; Sat, 5 Feb 2005 12:14:04 +0100 (CET) Message-ID: <4204AA7C.9010509@tomt.net> Date: Sat, 05 Feb 2005 12:14:04 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 620 Lines: 19 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > >>It is just the first such thing I found, scanning rt6i_idev uses >>will easily find several others. > > > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: <..> This patch fixes my problems with hangs when dot1q VLAN interfaces gets removed when loopback is down, as reported in the thread "2.6.10 ipv6/8021q lockup on vconfig on interface removal". Yay :) From yoshfuji@linux-ipv6.org Sat Feb 5 03:38:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:38:08 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15Bc2ho017244 for ; Sat, 5 Feb 2005 03:38:02 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 54BEB33CC2; Sat, 5 Feb 2005 20:39:01 +0900 (JST) Date: Sat, 05 Feb 2005 20:39:00 +0900 (JST) Message-Id: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4204AA7C.9010509@tomt.net> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1308 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: 525 Lines: 15 In article <4204AA7C.9010509@tomt.net> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt says: > This patch fixes my problems with hangs when dot1q VLAN interfaces gets > removed when loopback is down, as reported in the thread "2.6.10 > ipv6/8021q lockup on vconfig on interface removal". Please tell me, why your lo is down... Anyway, if we really want to "fix" this, we should do in other way. I think "Make loopback idev stick around" patches (for IPv4 and IPv6) could be start of that. --yoshfuji From andre@tomt.net Sat Feb 5 03:48:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:48:25 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15BmIfs017888 for ; Sat, 5 Feb 2005 03:48:18 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 1966D884FC; Sat, 5 Feb 2005 12:48:17 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 134E5884F6; Sat, 5 Feb 2005 12:48:15 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id CC1AE22895; Sat, 5 Feb 2005 12:48:14 +0100 (CET) Message-ID: <4204B27F.5040202@tomt.net> Date: Sat, 05 Feb 2005 12:48:15 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org Cc: andre@tomt.net, herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> In-Reply-To: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 705 Lines: 19 YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <4204AA7C.9010509@tomt.net> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt says: > > >>This patch fixes my problems with hangs when dot1q VLAN interfaces gets >>removed when loopback is down, as reported in the thread "2.6.10 >>ipv6/8021q lockup on vconfig on interface removal". > > > Please tell me, why your lo is down... > > Anyway, if we really want to "fix" this, > we should do in other way. > > I think "Make loopback idev stick around" patches > (for IPv4 and IPv6) could be start of that. "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in Debian brings down loopback before any other interfaces. From yoshfuji@linux-ipv6.org Sat Feb 5 03:54:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:54:18 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15BsAVq018538 for ; Sat, 5 Feb 2005 03:54:10 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C933133CE2; Sat, 5 Feb 2005 20:55:09 +0900 (JST) Date: Sat, 05 Feb 2005 20:55:07 +0900 (JST) Message-Id: <20050205.205507.75127320.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4204B27F.5040202@tomt.net> References: <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> <4204B27F.5040202@tomt.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1310 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: 366 Lines: 10 In article <4204B27F.5040202@tomt.net> (at Sat, 05 Feb 2005 12:48:15 +0100), Andre Tomt says: > > Please tell me, why your lo is down... : > "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in > Debian brings down loopback before any other interfaces. Okay, thanks. (I now remember someone told me this before.) hmm... --yoshfuji From rich@phekda.gotadsl.co.uk Sat Feb 5 05:24:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 05:24:51 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15DOifB024889 for ; Sat, 5 Feb 2005 05:24:45 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-66-42.dyn.gotadsl.co.uk [82.133.66.42]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1F83F2BB5DA; Sat, 5 Feb 2005 13:24:41 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 922B5360; Sat, 5 Feb 2005 13:26:25 +0000 (GMT) Message-ID: <4204C981.6050102@phekda.gotadsl.co.uk> Date: Sat, 05 Feb 2005 13:26:25 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A0F0D5.9050702@phekda.gotadsl.co.uk> <20041121205814.GA22460@electric-eye.fr.zoreil.com> <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> In-Reply-To: <20050125214725.GA6093@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1668 Lines: 47 Hello. Francois Romieu wrote: > Hi, > > could you give the patch below some testing ? > > Any post-LLTX-revert 2.6.11-rc2-bk should do. > > Merge of Realtek's code > - code dedicated to a new phy (spotted by Richard Dawe); > - C+ register fiddling seems required for both RTL_GIGA_MAC_VER_{D/E}; > - apart from being reserved, register at address 0xe2 is named 'IntrMitigate'; > - bump version number. > A bunch of people do not use the vanilla kernel module simply because > Realtek's driver has a higher revision number. This is not an issue per > se but their driver is buggy due to some partial merge of in-kernel code. [snip] Applied to 2.6.11-rc3. It seems to work fine. I've passed ~20GB of data at 100Mbps full-duplex with no errors (compared MD5 sums on files). My data rate test (sftp of Linux kernel source tarball) gave about the same data rate as 1.6LK + PHY patch - ~7.1MB/sec. It works fine setting the speed & duplex using "ethtool -s eth0 autoneg off speed duplex ". I haven't tested the VLAN or jumbo(ish) frames. Let me know if you'd like me to test those too. Although I'm not sure if I can test jumbo frames with the equipment I have. One more thing: With 1.6LK + my PHY patch, I see the message "eth0: PHY reset until link up" every 5 seconds or so, when there is no Ethernet cable plugged in. This is annoying. I think it should only log it once. I'll repeat my cable removal/insertion tests with 2.2LK later and let you know what I find. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From dcbw@redhat.com Sat Feb 5 06:40:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 06:40:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15EeGhm026882 for ; Sat, 5 Feb 2005 06:40:16 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j15Eb8f1016246; Sat, 5 Feb 2005 09:37:08 -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 j15Eb8O11027; Sat, 5 Feb 2005 09:37:08 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j15Eb8vj017115; Sat, 5 Feb 2005 09:37:08 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j15Eb7Ol017111; Sat, 5 Feb 2005 09:37:07 -0500 Date: Sat, 5 Feb 2005 09:37:07 -0500 (EST) From: Dan Williams To: Jouni Malinen cc: Dan Williams , jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification In-Reply-To: <20050205063854.GE9685@jm.kir.nu> Message-ID: References: <20050205052744.GD9685@jm.kir.nu> <20050205063854.GE9685@jm.kir.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 3671 Lines: 62 On Fri, 4 Feb 2005, Jouni Malinen wrote: > On Sat, Feb 05, 2005 at 01:04:42AM -0500, Dan Williams wrote: > > > Reporting received signal strength in RSSI and noise level in dBm won't really > > work well. Manufacturers usually provide an RSSI->dBm conversion, but where > > they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, > > there is no way for user applications to know the bounds of these values and > > determine a signal quality % from them. Again, this is all about consistency, > > and we need a stable, well-defined API that doesn't depend on user-applications > > special-casing drivers just to get usable information out of them. If the > > driver cannot provide usable information of some sort, it shouldn't even be > > trying to provide that information at all really. > > Agreed, there should be no special cases based on driver in user space. > However, the API definition should not make it too difficult for the > drivers to implement the interface. If many cards use dBm for noise and > RSSI for received frames, it would sound like the API definition should > take this into account and not require the drivers either not to report > values or do some conversion which may not always be that clear. > > > qual.qual must be linear (because it should be able to be converted to a > > percentage value, its a _subjective_ measure of quality composed of a number of > > different quality statistics). qual.level & qual.noise may not necessarily be > > linear since they are measures of electrical power (either RSSI or dBm). > > How would this value be determined for cards that have RSSI for received > packets and noise floor in dBm? Using a table of values? AFAIK, most manufacturers provide either a conversion constant (Airo & Madwifi/Atheros) or a lookup table (airo) of some sort for their cards. People on Windows want to get dBm too. Unfortunately, given that Linux driver writers can't always get that information, you're probably right. > > The current WEXT API provides _no_ way to specify whether the returned values > > are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and > > max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've > > brought that up with Jean and he's agreed that it may need some clarification. > > There isn't really a "qual.type = dBm" bit anywhere in the quality structures, > > though that would be quite helpful (and was my suggestion). > > > See above, technically you could have a noise floor of 0 I guess, and the > > current WEXT API has no way of specifying different units for use in noise and > > level at this time. Hence, the noise value can actually mean something when > > using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). > > Isn't the 'max_qual.level == 0 means dBm' similar to saying > 'max_qual.noise == 0 means dBm' for noise. In other words, > max_qual.level == 70 and max_qual.noise == 0 could mean RSSI for signal > strength and dBm for noise. Using max_qual.noise to report global noise > value (noise floor?) sound somewhat confusing. Yes, that's true, and would probably be more consistent. If the suggestion is to go this far in changing the spec, then I'd suggest to actually make explicit fields in the iw_quality structure that specify what units are being used. There are two unused bitfields in the .updated structure of the iw_quality structure, and if you want to keep API/ABI compatibility then those could be used to specify RSSI/dBm. I've suggested some method of explicitly specifying this in the API, which Jean is considering. Dan From herbert@gondor.apana.org.au Sat Feb 5 10:34:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 10:34:38 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15IYWdn003677 for ; Sat, 5 Feb 2005 10:34:33 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxUkz-0005ih-00; Sun, 06 Feb 2005 05:34:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxUkc-00033y-00; Sun, 06 Feb 2005 05:33:46 +1100 Date: Sun, 6 Feb 2005 05:33:46 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: andre@tomt.net, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205183346.GB11716@gondor.apana.org.au> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 647 Lines: 17 On Sat, Feb 05, 2005 at 08:39:00PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > I think "Make loopback idev stick around" patches > (for IPv4 and IPv6) could be start of that. Unfortunately that patch can't fix this particular problem. This problem will show up whenever there is a dst on the GC list that has split devices and a non-zero refcnt. So if you had a process holding that dst you can still get a dead-lock. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 5 10:33:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 10:33:42 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15IXXpf003491 for ; Sat, 5 Feb 2005 10:33:34 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxUjp-0005hn-00; Sun, 06 Feb 2005 05:32:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxUjC-00033P-00; Sun, 06 Feb 2005 05:32:18 +1100 Date: Sun, 6 Feb 2005 05:32:18 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205183218.GA11716@gondor.apana.org.au> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 988 Lines: 26 On Sat, Feb 05, 2005 at 07:50:39PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Yes, IPv6 needs "split device" semantics > (for per-device statistics such as Ip6InDelivers etc), > and I like later solution. OK. Is there any reason why IPv4 should be different from IPv6 in this respect though? If the split device dst's are to be kept, we'll need a way to clean them up. There are two choices: 1) Put the dst's on IPv6's own GC so that we can search by rt6i_idev. 2) Change the generic GC so that dst->ops->ifdown is always called even if dst->dev does not match with the device going down. We also need to change the individual ifdown functions to check for ->dev. The IPv6 ifdown function can then check for ->rt6i_idev as well. What's your preference? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From romieu@fr.zoreil.com Sat Feb 5 12:42:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 12:42:46 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15KgZLI010133 for ; Sat, 5 Feb 2005 12:42:36 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j15Kffdj014369; Sat, 5 Feb 2005 21:41:41 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j15KfZv4014368; Sat, 5 Feb 2005 21:41:35 +0100 Date: Sat, 5 Feb 2005 21:41:35 +0100 From: Francois Romieu To: Richard Dawe Cc: netdev@oss.sgi.com Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow Message-ID: <20050205204135.GA13986@electric-eye.fr.zoreil.com> References: <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4204C981.6050102@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1315 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: 1807 Lines: 48 Richard Dawe : [...] > Applied to 2.6.11-rc3. It seems to work fine. I've passed ~20GB of data > at 100Mbps full-duplex with no errors (compared MD5 sums on files). My So it can be considered that the link detection issue is gone. Ok, I'll ask Jeff to submit it for mainline. > data rate test (sftp of Linux kernel source tarball) gave about the same > data rate as 1.6LK + PHY patch - ~7.1MB/sec. If this test is (sys) CPU bound, then you should see a difference when SG and TX csum is enabled. > It works fine setting the speed & duplex using "ethtool -s eth0 autoneg > off speed duplex ". Nice. Does it stand an 'ethtool -s eth0 autoneg on' after this point ? > I haven't tested the VLAN or jumbo(ish) frames. Let me know if you'd > like me to test those too. Although I'm not sure if I can test jumbo > frames with the equipment I have. Hardly. If you can do an extra test, I'd like to know if you can safely bring the r8169 interface down on your computer once the patch below if applied: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc3/r8169/patches/r8169-380.patch (it should apply correctly on top of you current setup) > One more thing: > > With 1.6LK + my PHY patch, I see the message "eth0: PHY reset until link > up" every 5 seconds or so, when there is no Ethernet cable plugged in. > This is annoying. I think it should only log it once. Hmmm... One could argue that 1) syslog will cope and 2) the printk level of the console can be lowered. Some event kamasutra can probably be done from userspace too so I am a bit reluctant to special case this code (read as: I'd welcome more requests/complaints). Is it enough for you if I salt the code with a few netif_msg_xxx() here and there to control the messages ? -- Ueimor From davem@davemloft.net Sat Feb 5 17:22:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:22:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j161MiQg018727 for ; Sat, 5 Feb 2005 17:22:45 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cxb0a-0005XC-00; Sat, 05 Feb 2005 17:14:40 -0800 Date: Sat, 5 Feb 2005 17:14:39 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050205171439.4e825155.davem@davemloft.net> In-Reply-To: <20050204015539.GA9727@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> <20050204015539.GA9727@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 319 Lines: 9 On Fri, 4 Feb 2005 12:55:39 +1100 Herbert Xu wrote: > OK, here is the patch to do that. Let's get rid of kfree_skb_fast > while we're at it since it's no longer used. > > Signed-off-by: Herbert Xu I've queued this up for 2.6.x and 2.4.x, thanks everyone. From davem@davemloft.net Sat Feb 5 17:28:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:28:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j161SfT2019269 for ; Sat, 5 Feb 2005 17:28:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cxb6j-0005Xk-00; Sat, 05 Feb 2005 17:21:01 -0800 Date: Sat, 5 Feb 2005 17:21:01 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com, anton@samba.org Subject: Re: [NET] Add barriers for dst refcnt Message-Id: <20050205172101.7874e1dd.davem@davemloft.net> In-Reply-To: <20050204073311.GA11716@gondor.apana.org.au> References: <20050204073311.GA11716@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 998 Lines: 26 On Fri, 4 Feb 2005 18:33:11 +1100 Herbert Xu wrote: > In light of the recent discussion about sk_buff, I think we need > the following patch for dst_entry. This adds a memory barrier > before dst_release drops the refcnt, and a read memory barrier > before dst_destroy starts destroying the entry. > > Signed-off-by: Herbert Xu Good catch. I "think" the dst_release() case is theoretical. dst_release() runs in a locked context for the thing referencing 'dst'. Be it the route hash, a socket, whatever. BTW, looking at dst_release() call sites, xchg() might be another primitive we need to watch out for memory barrier semantics of. Since it returns a value, it would seem to need to be strictly ordered wrt. other memory operations. And sure enough, ppc64 has the memory barriers there. Man, something else to audit on sparc64 and document in atomic_ops.txt :-) Anyways, Herbert's patch is correct and I'll apply it. Thanks. From chas@cmf.nrl.navy.mil Sat Feb 5 17:33:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:33:48 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j161XhjY019807 for ; Sat, 5 Feb 2005 17:33:44 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j161XIj3007281; Sat, 5 Feb 2005 20:33:18 -0500 (EST) Message-Id: <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> To: Roman Kagan cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-reply-to: Your message of "Fri, 04 Feb 2005 23:13:27 +0300." <20050204201327.GA2439@katya> Date: Sat, 05 Feb 2005 20:33:18 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1318 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: 656 Lines: 14 In message <20050204201327.GA2439@katya>,Roman Kagan writes: >> +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); >Maybe it should better be "esi", to match the name in struct atm_dev? its called address for ethernet network interfaces so i guess calling it address here is sensible. >script, and hoping that was enough for the driver to complete >initializing atm_dev. I suspect the only way to fix it is to split the >atm_dev initialization into two stages, allocation and registration, as >it is done for net_device. yeah which is why i just wanted to convert atm_dev to just be a netdevice. the code is already written and "stable". From davem@davemloft.net Sat Feb 5 20:10:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:10:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164Ao4k023402 for ; Sat, 5 Feb 2005 20:10:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxddC-00067u-00; Sat, 05 Feb 2005 20:02:42 -0800 Date: Sat, 5 Feb 2005 20:02:42 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205200242.2b629de7.davem@davemloft.net> In-Reply-To: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j164Ao4k023402 X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 852 Lines: 18 On Sat, 05 Feb 2005 19:50:39 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20050205064643.GA29758@gondor.apana.org.au> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu says: > > > If we wanted to preserve the split device semantics, then we > > can create a local GC list in IPv6 so that it can search based > > on rt6i_idev as well as the other keys. Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > Yes, IPv6 needs "split device" semantics > (for per-device statistics such as Ip6InDelivers etc), > and I like later solution. Ok. I never read whether ipv6, like ipv4, is specified to support a model of host based ownership of addresses. Does anyone know? From davem@davemloft.net Sat Feb 5 20:18:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:18:32 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164ISp6023989 for ; Sat, 5 Feb 2005 20:18:28 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cxdkz-00068U-00; Sat, 05 Feb 2005 20:10:45 -0800 Date: Sat, 5 Feb 2005 20:10:44 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205201044.1b95f4e8.davem@davemloft.net> In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 36 On Sat, 5 Feb 2005 17:46:43 +1100 Herbert Xu wrote: > This doesn't work because net/core/dst.c can only search based > on dst->dev. For the split device case, dst->dev is set to > loopback_dev while rt6i_idev is set to the real device. Indeed. I didn't catch that. > If we wanted to preserve the split device semantics, then we > can create a local GC list in IPv6 so that it can search based > on rt6i_idev as well as the other keys. Ok, so this would entail changing each ipv6 dst_free() call into one to ip6_dst_free(), which would: ip6_garbage_add(dst); dst_free(dst); It would mean that dst_run_gc() would need to have some callback like dst->ops->gc_destroy() or similar, which would allow ipv6 to delete the dst from it's local garbage list. > Alternatively we can > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > and move that test down to the individual ifdown functions. I think there is a hole in this idea.... maybe. If the idea is to scan dst_garbage_list down in ipv6 specific code, you can't do that since 'dst' objects from every pool in the kernel get put onto the dst_garbage_list. It is generic. They have no identity, so it's illegal to treat any member of that list as an rt_entry, rt6_entry or any specific higher level dst type. From yoshfuji@linux-ipv6.org Sat Feb 5 20:36:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:36:32 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164aQjR028099 for ; Sat, 5 Feb 2005 20:36:27 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id AB40433CC2; Sun, 6 Feb 2005 13:37:26 +0900 (JST) Date: Sun, 06 Feb 2005 13:37:23 +0900 (JST) Message-Id: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205201044.1b95f4e8.davem@davemloft.net> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 793 Lines: 23 In article <20050205201044.1b95f4e8.davem@davemloft.net> (at Sat, 5 Feb 2005 20:10:44 -0800), "David S. Miller" says: > > Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > I think there is a hole in this idea.... maybe. > > If the idea is to scan dst_garbage_list down in ipv6 specific code, > you can't do that since 'dst' objects from every pool in the kernel > get put onto the dst_garbage_list. It is generic. How about making dst->ops->dev_check() like this: static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) { if (dst->ops->dev_check) return dst->ops->dev_check(dst, dev) else return dst->dev == dev; } --yoshfuji From willy@www.linux.org.uk Sat Feb 5 20:47:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:47:55 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164lkI5028686 for ; Sat, 5 Feb 2005 20:47:47 -0800 Received: from willy by parcelfarce.linux.theplanet.co.uk with local (Exim 4.33) id 1CxeKm-00007T-Tw for netdev@oss.sgi.com; Sun, 06 Feb 2005 04:47:44 +0000 Date: Sun, 6 Feb 2005 04:47:44 +0000 From: Matthew Wilcox To: netdev@oss.sgi.com Subject: [PATCH] ipconfig invokes undefined behaviour Message-ID: <20050206044744.GO20386@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: netdev Content-Length: 1151 Lines: 30 strcpy is undefined if src and dest overlap. That's clearly possible here with a sufficiently deep path on the server. Use memmove instead. Signed-off-by: Matthew Wilcox Index: ./net/ipv4/ipconfig.c =================================================================== RCS file: /var/cvs/linux-2.6/net/ipv4/ipconfig.c,v retrieving revision 1.12 diff -u -p -r1.12 ipconfig.c --- ./net/ipv4/ipconfig.c 22 Jan 2005 15:00:01 -0000 1.12 +++ ./net/ipv4/ipconfig.c 6 Feb 2005 04:41:30 -0000 @@ -1232,7 +1232,7 @@ u32 __init root_nfs_parse_addr(char *nam if (*cp == ':') *cp++ = '\0'; addr = in_aton(name); - strcpy(name, cp); + memmove(name, cp, strlen(cp) + 1); } else addr = INADDR_NONE; -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain From yoshfuji@linux-ipv6.org Sat Feb 5 21:00:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:00:42 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1650aYv029454 for ; Sat, 5 Feb 2005 21:00:37 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0121C33CC2; Sun, 6 Feb 2005 14:01:36 +0900 (JST) Date: Sun, 06 Feb 2005 14:01:35 +0900 (JST) Message-Id: <20050206.140135.112327413.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205200242.2b629de7.davem@davemloft.net> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> <20050205200242.2b629de7.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1323 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: 1556 Lines: 42 In article <20050205200242.2b629de7.davem@davemloft.net> (at Sat, 5 Feb 2005 20:02:42 -0800), "David S. Miller" says: > > Yes, IPv6 needs "split device" semantics > > (for per-device statistics such as Ip6InDelivers etc), > > and I like later solution. > > Ok. I never read whether ipv6, like ipv4, is specified to support > a model of host based ownership of addresses. Does anyone know? I'm not sure it is explicitly specified, but there're some hints: 1. we need to allow multiple addresses on multiple interfaces. e.g. link-local address 2. if a packet has come from A to link-local address on the other side B, we should not receive it. +-------+ ---->|A B| +-------+ Currently, it does not happen in usual because ndisc does NOT handle addresses on other device. 3. mib document states that we should take statistics on interface which the address belongs to; not the interface where the packet has come from: cited from RFC2011bis: Local (*) packets on the input side are counted on the interface associated with their destination address, which may not be the interface on which they were received. This requirement is caused by the possibility of losing the original interface during processing, especially re-assembly. (*): here it means incoming, but not forwarding. BTW, BSD has similar reference to interface structure in routeing entry. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Sat Feb 5 21:12:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:12:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j165C8om030220 for ; Sat, 5 Feb 2005 21:12:11 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cxeah-0006MX-00; Sat, 05 Feb 2005 21:04:11 -0800 Date: Sat, 5 Feb 2005 21:04:11 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205210411.7e18b8e6.davem@davemloft.net> In-Reply-To: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j165C8om030220 X-archive-position: 1324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 483 Lines: 18 On Sun, 06 Feb 2005 13:37:23 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > How about making dst->ops->dev_check() like this: > > static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) > { > if (dst->ops->dev_check) > return dst->ops->dev_check(dst, dev) > else > return dst->dev == dev; > } Oh I see. That would work, and it seems the simplest, and lowest risk fix for this problem. Herbert, what do you think? From yoshfuji@linux-ipv6.org Sat Feb 5 21:30:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:30:17 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j165U8tJ030992 for ; Sat, 5 Feb 2005 21:30:09 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A5C4A33CC2; Sun, 6 Feb 2005 14:31:08 +0900 (JST) Date: Sun, 06 Feb 2005 14:31:07 +0900 (JST) Message-Id: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205210411.7e18b8e6.davem@davemloft.net> References: <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1325 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: 1138 Lines: 38 In article <20050205210411.7e18b8e6.davem@davemloft.net> (at Sat, 5 Feb 2005 21:04:11 -0800), "David S. Miller" says: > On Sun, 06 Feb 2005 13:37:23 +0900 (JST) > YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > How about making dst->ops->dev_check() like this: > > > > static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) > > { > > if (dst->ops->dev_check) > > return dst->ops->dev_check(dst, dev) > > else > > return dst->dev == dev; > > } > > Oh I see. That would work, and it seems the simplest, and > lowest risk fix for this problem. Well... Here, lo is going down. rt->rt6i_dev = lo and rt->rt6i_idev = ethX. I think we already see dst->dev == dev (==lo) now. So, I doubt that fix the problem. The source of problem is entry (*) which still on routing entry, not on gc list. And, the owner of entry is not routing table but unicast/anycast address structure(s). We need to "kill" active address on the other interfaces. *: rt->rt6i_dev = lo and rt->rt6i_idev = ethX BTW, I wish we could shut down eth0 during lo is pending... --yoshfuji From yoshfuji@linux-ipv6.org Sat Feb 5 21:49:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:49:14 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j165n89R031710 for ; Sat, 5 Feb 2005 21:49:09 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C4E3B33CC2; Sun, 6 Feb 2005 14:50:08 +0900 (JST) Date: Sun, 06 Feb 2005 14:50:07 +0900 (JST) Message-Id: <20050206.145007.34543324.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> References: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1326 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: 1441 Lines: 41 In article <20050206.143107.39728239.yoshfuji@linux-ipv6.org> (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > The source of problem is entry (*) which still on routing entry, > not on gc list. And, the owner of entry is not routing table but > unicast/anycast address structure(s). > We need to "kill" active address on the other interfaces. Which means in addrconf_notiry(), if the dev == &loopback_dev, call addrconf_ifdown for every device like this: Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 06:13:31 +09:00 +++ edited/net/ipv6/addrconf.c 2005-02-06 14:48:25 +09:00 @@ -1961,6 +1961,20 @@ case NETDEV_DOWN: case NETDEV_UNREGISTER: /* + * If lo is doing down we need to kill + * all addresses on the host because it owns + * route on lo. --yoshfuji + */ + if (dev == &loopback_dev) { + struct net_device *dev1; + for (dev1 = dev_base; dev1; dev1 = dev->next) { + if (dev1 == &loopback_dev || + __in6_dev_get(dev1) == NULL) + continue; + addrconf_ifdown(dev1, event != NETDEV_DOWN); + } + } + /* * Remove all addresses from this interface. */ addrconf_ifdown(dev, event != NETDEV_DOWN); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Sat Feb 5 22:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:52:36 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j166qRtD000812 for ; Sat, 5 Feb 2005 22:52:28 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxgGz-00012j-00; Sun, 06 Feb 2005 17:51:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgGL-0001WJ-00; Sun, 06 Feb 2005 17:51:17 +1100 Date: Sun, 6 Feb 2005 17:51:17 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065117.GC16057@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205201044.1b95f4e8.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1601 Lines: 57 On Sat, Feb 05, 2005 at 08:10:44PM -0800, David S. Miller wrote: > > > Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > I think there is a hole in this idea.... maybe. > > If the idea is to scan dst_garbage_list down in ipv6 specific code, > you can't do that since 'dst' objects from every pool in the kernel > get put onto the dst_garbage_list. It is generic. The idea is to move the check into dst->ops->ifdown. By definition ipv6_dst_ifdown will only see rt6_info entries. So dst_dev_event will become for (dst = dst_garbage_list; dst; dst = dst->next) { dst_ifdown(dst, event != NETDEV_DOWN); } dst_ifdown will become ... do { if (dst->dev == dev && unregister) { ... } dst->ops->ifdown(dst, dev, unregister); } while ((dst = dst->child) && dst->flags & DST_NOHASH); ... Note the extra dev argument to ifdown. ipv6_dst_ifdown will be static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev, int how) { struct rt6_info *rt = (struct rt6_info *)dst; struct inet6_dev *idev = rt->rt6i_idev; if (idev != NULL && idev->dev != &loopback_dev && idev->dev == dev) { struct inet6_dev *loopback_idev = in6_dev_get(&loopback_dev); if (loopback_idev != NULL) { rt->rt6i_idev = loopback_idev; in6_dev_put(idev); } } } Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 5 22:54:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:54:10 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j166s5r3001421 for ; Sat, 5 Feb 2005 22:54:06 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxgIk-00013G-00; Sun, 06 Feb 2005 17:53:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgIe-0001XH-00; Sun, 06 Feb 2005 17:53:40 +1100 Date: Sun, 6 Feb 2005 17:53:40 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065340.GE16057@gondor.apana.org.au> References: <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 923 Lines: 23 On Sun, Feb 06, 2005 at 02:31:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Here, lo is going down. > rt->rt6i_dev = lo and rt->rt6i_idev = ethX. > I think we already see dst->dev == dev (==lo) now. > So, I doubt that fix the problem. > > The source of problem is entry (*) which still on routing entry, > not on gc list. And, the owner of entry is not routing table but > unicast/anycast address structure(s). > We need to "kill" active address on the other interfaces. > > *: rt->rt6i_dev = lo and rt->rt6i_idev = ethX Sorry I don't think this is right. Although lo going down is required to cause those symptoms, it is not the trigger. The problem only occurs when eth0 itself is unregistered. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 5 22:52:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:53:00 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j166qsYD000874 for ; Sat, 5 Feb 2005 22:52:54 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxgHb-00012x-00; Sun, 06 Feb 2005 17:52:35 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgHL-0001Wn-00; Sun, 06 Feb 2005 17:52:19 +1100 Date: Sun, 6 Feb 2005 17:52:19 +1100 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065219.GD16057@gondor.apana.org.au> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205210411.7e18b8e6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 431 Lines: 15 On Sat, Feb 05, 2005 at 09:04:11PM -0800, David S. Miller wrote: > > Oh I see. That would work, and it seems the simplest, and > lowest risk fix for this problem. > > Herbert, what do you think? Yes I agree. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 5 23:01:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 23:01:34 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1671QcJ002378 for ; Sat, 5 Feb 2005 23:01:27 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxgPr-00016f-00; Sun, 06 Feb 2005 18:01:07 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgPa-0001Y4-00; Sun, 06 Feb 2005 18:00:50 +1100 Date: Sun, 6 Feb 2005 18:00:50 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206070050.GF16057@gondor.apana.org.au> References: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.yoshfuji@linux-ipv6.org> <20050206.145007.34543324.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.145007.34543324.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 833 Lines: 20 On Sun, Feb 06, 2005 at 02:50:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Which means in addrconf_notiry(), if the dev == &loopback_dev, > call addrconf_ifdown for every device like this: This should fix the reported issue. However, I'm not sure if it's a good idea to stop all IP traffic when lo goes down. We don't do that for IPv4. Besides, we'll still need to fix the rt6i_idev GC issue since the same bug can occur when eth0 goes down and some appliation is holding a dst to a local address route. It can become a dead-lock if the said application then invokes a syscall that takes the RTNL. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 5 23:04:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 23:04:56 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1674pEZ002895 for ; Sat, 5 Feb 2005 23:04:52 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxgT4-00017P-00; Sun, 06 Feb 2005 18:04:27 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgSh-0001Z1-00; Sun, 06 Feb 2005 18:04:03 +1100 Date: Sun, 6 Feb 2005 18:04:03 +1100 To: "David S. Miller" Cc: netdev@oss.sgi.com, anton@samba.org Subject: Re: [NET] Add barriers for dst refcnt Message-ID: <20050206070403.GA5996@gondor.apana.org.au> References: <20050204073311.GA11716@gondor.apana.org.au> <20050205172101.7874e1dd.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205172101.7874e1dd.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 555 Lines: 13 On Sat, Feb 05, 2005 at 05:21:01PM -0800, David S. Miller wrote: > > I "think" the dst_release() case is theoretical. dst_release() > runs in a locked context for the thing referencing 'dst'. Be it > the route hash, a socket, whatever. Unless dst_run_gc takes the same lock as the context doing the dst_release you'll still be in trouble :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rich@phekda.gotadsl.co.uk Sun Feb 6 02:53:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 02:53:26 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16ArJLB013734 for ; Sun, 6 Feb 2005 02:53:20 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-102-19.dyn.gotadsl.co.uk [82.133.102.19]) by smtp.nildram.co.uk (Postfix) with ESMTP id C59B72BCA3D; Sun, 6 Feb 2005 10:53:14 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id C05AA361; Sun, 6 Feb 2005 10:54:59 +0000 (GMT) Message-ID: <4205F783.1020702@phekda.gotadsl.co.uk> Date: Sun, 06 Feb 2005 10:54:59 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> <20050205204135.GA13986@electric-eye.fr.zoreil.com> In-Reply-To: <20050205204135.GA13986@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 572 Lines: 26 Hello. Francois Romieu wrote: > Richard Dawe : > [...] [snip] >>It works fine setting the speed & duplex using "ethtool -s eth0 autoneg >>off speed duplex ". > > > Nice. > Does it stand an 'ethtool -s eth0 autoneg on' after this point ? [snip] Yes, that works fine. I'll have to get back to you about the other things tomorrow night. I'm busy today. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From andre@tomt.net Sun Feb 6 02:55:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 02:55:33 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16AtPPp014124 for ; Sun, 6 Feb 2005 02:55:26 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 878A6884E9; Sun, 6 Feb 2005 11:55:24 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 0DF47884E5; Sun, 6 Feb 2005 11:55:22 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id E2F7622895; Sun, 6 Feb 2005 11:55:18 +0100 (CET) Message-ID: <4205F797.8080804@tomt.net> Date: Sun, 06 Feb 2005 11:55:19 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 986 Lines: 25 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > >>It is just the first such thing I found, scanning rt6i_idev uses >>will easily find several others. > > > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: > > [IPV6] addrconf_dst_alloc() to allocate new route for local address. > [IPV6] take rt6i_idev into account when looking up routes. > > Signed-off-by: Herbert Xu ~{PmV>HI~} Now that this fix have been written off as probably wrong; how much does it break? As far as I've understood it "just" reverts to old semantics, probably not correct semantics, but still not unexpected semantics (like, say, hang on device unregistration ;) ) I'm contemplating just using it as a quick-fix until 2.6.11 to get this problem under control. From yoshfuji@linux-ipv6.org Sun Feb 6 03:27:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 03:27:21 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16BRGFi015799 for ; Sun, 6 Feb 2005 03:27:17 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EDB2233CC2; Sun, 6 Feb 2005 20:28:16 +0900 (JST) Date: Sun, 06 Feb 2005 20:28:13 +0900 (JST) Message-Id: <20050206.202813.132742833.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4205F797.8080804@tomt.net> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4205F797.8080804@tomt.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1334 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: 267 Lines: 8 In article <4205F797.8080804@tomt.net> (at Sun, 06 Feb 2005 11:55:19 +0100), Andre Tomt says: > I'm contemplating just using it as a quick-fix until 2.6.11 to get this > problem under control. Would you find if my patch works? Thanks. --yoshfuji From herbert@gondor.apana.org.au Sun Feb 6 03:42:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 03:42:45 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16BgaPA016712 for ; Sun, 6 Feb 2005 03:42:37 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cxkns-0002Hb-00; Sun, 06 Feb 2005 22:42:12 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxknR-0005RD-00; Sun, 06 Feb 2005 22:41:45 +1100 Date: Sun, 6 Feb 2005 22:41:45 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206114145.GA20883@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205104559.GA30981@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 791 Lines: 26 On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote: > > Although I still think this is a bug, I'm now starting to suspect > that there is another bug around as well. > > There is probably an ifp leak which in turn leads to a split dst > leak that allows the first bug to make its mark. Found it. This is what happens: lo goes down => rt6_ifdown => eth0's local address route gets deleted eth0 goes down => __ipv6_ifa_notify => ip6_del_rt fails so we fall through to the dst_free path. At this point the refcount taken by __ipv6_ifa_notify is leaked. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Sun Feb 6 04:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 04:29:24 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16CTJw6027344 for ; Sun, 6 Feb 2005 04:29:19 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id F3AA633CC2; Sun, 6 Feb 2005 21:30:19 +0900 (JST) Date: Sun, 06 Feb 2005 21:30:18 +0900 (JST) Message-Id: <20050206.213018.92031627.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050206114145.GA20883@gondor.apana.org.au> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> <20050206114145.GA20883@gondor.apana.org.au> 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1336 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: 2204 Lines: 67 In article <20050206114145.GA20883@gondor.apana.org.au> (at Sun, 6 Feb 2005 22:41:45 +1100), Herbert Xu says: > On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote: > > > > Although I still think this is a bug, I'm now starting to suspect > > that there is another bug around as well. > > > > There is probably an ifp leak which in turn leads to a split dst > > leak that allows the first bug to make its mark. > > Found it. This is what happens: > > lo goes down => > rt6_ifdown => > eth0's local address route gets deleted > > eth0 goes down => > __ipv6_ifa_notify => > ip6_del_rt fails so we fall through to the > dst_free path. At this point the refcount > taken by __ipv6_ifa_notify is leaked. Oh, you're right! Thanks. How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()? Signed-off-by: Hideaki YOSHIFUJI ===== include/linux/ipv6_route.h 1.6 vs edited ===== --- 1.6/include/linux/ipv6_route.h 2004-10-26 12:54:23 +09:00 +++ edited/include/linux/ipv6_route.h 2005-02-06 21:27:02 +09:00 @@ -26,6 +26,7 @@ #define RTF_FLOW 0x02000000 /* flow significant route */ #define RTF_POLICY 0x04000000 /* policy route */ +#define RTF_ANYCAST 0x40000000 #define RTF_LOCAL 0x80000000 struct in6_rtmsg { ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 17:44:48 +09:00 +++ edited/net/ipv6/route.c 2005-02-06 21:26:35 +09:00 @@ -1408,7 +1408,9 @@ rt->u.dst.obsolete = -1; rt->rt6i_flags = RTF_UP | RTF_NONEXTHOP; - if (!anycast) + if (anycast) + rt->rt6i_flags |= RTF_ANYCAST; + else rt->rt6i_flags |= RTF_LOCAL; rt->rt6i_nexthop = ndisc_get_neigh(rt->rt6i_dev, &rt->rt6i_gateway); if (rt->rt6i_nexthop == NULL) { @@ -1427,7 +1429,8 @@ static int fib6_ifdown(struct rt6_info *rt, void *arg) { if (((void*)rt->rt6i_dev == arg || arg == NULL) && - rt != &ip6_null_entry) { + rt != &ip6_null_entry && + !(rt->rt6i_flags & (RTF_LOCAL|RTF_ANYCAST))) { RT6_TRACE("deleted by ifdown %p\n", rt); return -1; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From maxer@xmission.com Sun Feb 6 08:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 08:19:50 -0800 (PST) Received: from mgr2.xmission.com (mail@mgr2.xmission.com [198.60.22.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16GJkkv004092 for ; Sun, 6 Feb 2005 08:19:46 -0800 Received: from [198.60.22.201] (helo=mgr1.xmission.com) by mgr2.xmission.com with esmtp (Exim 4.34) id 1Cxp8S-0001Ew-RZ for netdev@oss.sgi.com; Sun, 06 Feb 2005 09:19:44 -0700 Received: from [166.70.55.125] (helo=[10.0.0.2]) by mgr1.xmission.com with esmtp (Exim 4.34) id 1Cxp8S-0004jo-3I for netdev@oss.sgi.com; Sun, 06 Feb 2005 09:19:45 -0700 Message-ID: <420643A4.9010407@xmission.com> Date: Sun, 06 Feb 2005 09:19:48 -0700 From: maxer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050109 Fedora/1.7.5-3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: skge no workee here Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 166.70.55.125 X-SA-Exim-Mail-From: maxer@xmission.com X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on mgr1.xmission.com) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxer@xmission.com Precedence: bulk X-list: netdev Content-Length: 1313 Lines: 34 Jgarzik wanted me to forward this to you today. This nic is on the mobo. sk98lin from kernel 2.6.9 works great. However: If I go into Fedora Core's Network Device Control applet, it shows eth0 inactive. If I try to activate it I get: skge device eth0:1 does not seem to be present, delaying initialization. Under Network Configuration tool trying to probe under "Bind to MAC address gives the result as [Errno 19] No such device. So while the driver clearly loads, it can't find the device nor activate it. What should I do to remedy this. I can bring up the device under kernel 2.6.9, but no kernel beyond this 2.6.10 or 2.6.11-xx works. 04:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 17) Subsystem: Intel Corp.: Unknown device 3065 Flags: bus master, fast devsel, latency 0, IRQ 3 Memory at ff720000 (64-bit, non-prefetchable) [size=16K] I/O ports at a800 [size=256] Expansion ROM at ff700000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting Thanks, RaXeT From romieu@fr.zoreil.com Sun Feb 6 08:50:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 08:50:45 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16GodiI005319 for ; Sun, 6 Feb 2005 08:50:39 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j16GmFfP024477; Sun, 6 Feb 2005 17:48:15 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j16GmAMe024476; Sun, 6 Feb 2005 17:48:10 +0100 Date: Sun, 6 Feb 2005 17:48:09 +0100 From: Francois Romieu To: maxer Cc: netdev@oss.sgi.com Subject: Re: skge no workee here Message-ID: <20050206164809.GA24316@electric-eye.fr.zoreil.com> References: <420643A4.9010407@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420643A4.9010407@xmission.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1338 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: 199 Lines: 12 maxer : [...] Interesting. Can you send dmesg/config for the working 2.6.9 kernel and the dysfunctional 2.6.10 ? The brand of the motherboard would be welcome too. -- Ueimor From ecalicchio@yahoo.it Sun Feb 6 09:10:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 09:10:46 -0800 (PST) Received: from web26809.mail.ukl.yahoo.com (web26809.mail.ukl.yahoo.com [217.146.176.85]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j16HAeEY006665 for ; Sun, 6 Feb 2005 09:10:40 -0800 Received: (qmail 74386 invoked by uid 60001); 6 Feb 2005 17:10:34 -0000 Message-ID: <20050206171034.74384.qmail@web26809.mail.ukl.yahoo.com> Received: from [151.41.232.52] by web26809.mail.ukl.yahoo.com via HTTP; Sun, 06 Feb 2005 18:10:34 CET Date: Sun, 6 Feb 2005 18:10:34 +0100 (CET) From: Emilio Calicchio Subject: questions about ipsec-tools-0.4 and linux kernel 2.6 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ecalicchio@yahoo.it Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 33 I am a student of engineering in first university of Rome (“La Sapienza”) and I’m working to my degree thesis whose title is: “End-to-end real-time applications performance measurements on VPN network (both terrestrial and satellite), blocks encryption algorithms vs stream cipher ones.” Since I have to use a Linux based test bed, I must integrate the stream cipher algorithms (like Scream and Seal cipher algorithm)in the Linux ipsec implementation; at aim I wonder whether you can help me by providing the following information: Architectural description of the ipsec Linux implementation (both tools and kernel modules) the files of kernel version 2.6 and ipsec-tools-0.4 that I should modify in order to add chiper stream algorithm if someone else is facing the same topic. Thanks for your help Best regards CALICCHIO EMILIO ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From bunk@stusta.de Sun Feb 6 10:44:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 10:45:03 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j16Iis6I009354 for ; Sun, 6 Feb 2005 10:44:56 -0800 Received: (qmail 10378 invoked from network); 6 Feb 2005 18:44:47 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 Feb 2005 18:44:47 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 0B526BB997; Sun, 6 Feb 2005 19:44:34 +0100 (CET) Date: Sun, 6 Feb 2005 19:44:34 +0100 From: Adrian Bunk To: Christoph Hellwig , Jeff Garzik , Linux Kernel , Netdev , Greg KH , Andrew Morton , linux-net@vger.kernel.org Subject: [2.6 patch] kill IPHASE5526 Message-ID: <20050206184434.GT3129@stusta.de> References: <41F952F4.7040804@pobox.com> <20050127210731.GA2953@infradead.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline In-Reply-To: <20050127210731.GA2953@infradead.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 59623 Lines: 845 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 27, 2005 at 09:07:31PM +0000, Christoph Hellwig wrote: > On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote: > > 1) iphase (iph5526 a.k.a. drivers/net/fc/*) > > > > Been broken since 2.3 or 2.4. Only janitors have kept it compiling. > > No, it doesn't even compile, and didn't so for more than two years. A patch to remove it is attached. <-- snip --> iph5526 does no longer compile since 2.5 wand was therefore marked as broken. This patch removes it. Signed-off-by: Adrian Bunk --- drivers/net/Kconfig | 9 drivers/net/Makefile | 1 drivers/net/fc/Makefile | 8 drivers/net/fc/iph5526.c | 4645 -------------------------------- drivers/net/fc/iph5526_ip.h | 24 drivers/net/fc/iph5526_novram.c | 278 - drivers/net/fc/iph5526_scsi.h | 31 drivers/net/fc/tach.h | 475 --- drivers/net/fc/tach_structs.h | 428 -- 9 files changed, 5899 deletions(-) --4ZLFUWh1odzi/v6L Content-Type: application/octet-stream Content-Disposition: attachment; filename="patch-remove-iphase.gz" Content-Transfer-Encoding: base64 H4sICNo6BkICA3BhdGNoLXJlbW92ZS1pcGhhc2UAxDxpcxpJsp+lX1GheTsBEiDAksaWxg4j 1FiEEWgAXzs7UdF0F9BWX+7q1rET3t/+Mqv6PhCS/d4StkRXZmXlVZlZR6vZbBLTsIP7Zrd1 0up0mp72omlZneYyMM1D3TNumccPbeYfvtcce2msWo6p73Tb7eNmu9tsn5DOyemLl6fHv7Xa 0YcctDvt9u7BwcHTKOepvjptvyxQffuWNLvHR91G55gciC8n5O3bXbJDiKqrru94ZMFM565F vjgBUU3uEL52AlMna/WWEa4aOvlCfIfszfqzIeGB6zqev0dUWxdEZPOK2cwztBjc2iW7Tckl GV5f9mbK8XH3ZLe543sG91Wfkb2h7TPPXaucEYSRuaqtHxybaGvD5cwnC4DokkfmxYSBhM5c ZuucAO5YmdNBn/z6KxFcwO/rvvh1Pp28V8aAvGamC78ImakPIMeaeYwYS/IAsgr5VDIwFtDW X6u2zcxYJ86S+GuDkxvD1lu7TUFi7hDNsVzDZBImTUJUDlQsRw9M1gDuHQckuhIjnQIeC0GC wp1hmqBuoqmmCcIZ7hpFR/okVNbssnetTEGziaLmnrpcgm5na9WF4WrKZ8AYXinjeW9U3wPU rEIulI/DvjJDLaQxd5tbO+6VesOWIGWZ5746ffHiBzw3Il0ke9Qudd3Oy6PGb+QAf0m/dRZf m/9T60/Gg+E7OlD69OXnz3Vy8JosmUZf3t8fgudlkXrTK4GgetbhbjMDkv4ju2uHuX6gSNq7 vh4poL33koLrmsxXzZs86nwq4L5zw2zPsFd5+KfeWCDcqfbhEwwBPKUVdtTsdJvdI9Ltnr44 Pu0eldrhUGe3hzZQCnt0YPaT9otT0HL3uFzFjZfw1Gijepu/wD8SDUqWMBMEqzm2QrxXpBes CIzTbsAEQod13DW5ZKZ5B678+1pbvzXspafqTNVbjrd6g52m7M4zfJ/ZGFQCmCsm9OPEsLkP aDjxjGVTuL7FbJ+3xFg5uyUhpb4Dao3mkfM03UbdtLxyj06h9Wcp9+jk6DjR7+H+T/nsNsl+ LLZ2CjH2UETAMCSh3TD05GMsRsdMvEM6OzsQmfqqh3EOqPYd98EzVmuf1GBmdF69ekU+GjaD iHxFegtPXasW+f3WUuXXt2vHt1TDbEFkfIP9BY05hkfXc1YeIMPXpccglThL/0712JmIvppq E4/pYHvPWAQQ5wwfc8ohcC5IQNQ0lg/YGtg6k+KAMBaXoZmRd+MP5B2mHdUk18HChAg5MjRm g6wQkQUNF5v5GiLt4kH0GSAfs5APMnCAtOobjn1GmAFwj6B7wDPpNkjESE31kWFICS6i1oHL B2KqfoLdqpQ7EQ+CvS1YWDsupg8gCqJF+QCmAThogwCmoPNpOL+cfJiT3vgL+dSbTnvj+Zcz wPYhM/uE3TJJy7Bc0wDSII2n2v4DqEZ0v1Km/Uvo0zsfjobzLyjKYDgfK7MZGUympEeue9P5 sP9h1JuS6w/T68lMaUGGZCxSrKBSoVz0LcsB9ekQCg2TC+l/xufwJ86OkbM63W3m/XYXMk6r 022BS89kPUGswPQNiOrgj56OsrRftDrHiNHTdVDtAPw8qWsQDmH3KIGP6TWSycDT/dNFE0Ih KL1MoL3z+Yxce47vaI4pwV1BfGDcAxicU4XCwPMC4Xrkbg2Gjzn+PFCmdHrxBcoPsIbHNAZz HydxG2rL35BKH+YYeJfpqDgYzApXBV7D+fOeeRAAWiISrADMmaW6azAsb0nuwK7RR9hbWzPt hgPBJT4Z9q1qGjh9bKhalNmcQLT2DMZDBlJSnnvAgKZyH8IU4X6wXOJMJ0shI7AY2IaA+obF 0L8XwQqI/BxXkF5F5pOLCTjEzpTO6XzykWCBCemnc2xxpuHUHDmOCy2uYzqrhxYZM2ANEEB7 EMkJYrWkPmZX1xCHOIoNLTtgKNK7GM76ZH4fqQaLRKgTUDGD0eTdsAWBZP9wB7MY5jVwJyj2 QF5trXpkPwo5ryX9vSSq33ZabRLrMnTmKATXSkNw/V/23hkO9Itha2agM/K7zN+yCG2t3xRB N9IRykDM82ynFOJqRmm7YRt+BQAiJjpyKdSySpt1ZqoPpRB+swA/Kh9pSVXPLQWhh3nl9FzD Nh3tphQI9QIkfoh/pdClFgMJuNoaihicXzrTTNUT6YWLoImqoQKZqJZjr8B7MPOKj4PZh5MD EtKGemhJE8IE3Tg18l6rdQj/uMYN8aO13kvzFbfTtcNzCg+7LrUj+O+KjumuKrcO+QOUYnmD IMCQviBmVFhpcJdpBq5O1lC8YeUBZSMX7CYj+rCyy3IomijkxkCDCi8LCv2fGm4FoChwDLKd W8i8LU0KpUMRazMy/TCmvXntvk5qXw1YSTHUMzzW00gXyvmHd1QQgTlX2t6paO9iO3KzzFBJ 4V5Ph+P5+xo4gaX6DaK2Wq06+duFlYJ/U9v7Bz8lew3QXPONrVqsfkb+JVxjR7pHiBZ1/uUX tQJjD+Z+/ex7Mi6s+5QpCLqzxVAxkTj8kFOM6AyXM+QfvIaRpUHuMwOMlN5H5UcGMJl6m6Yv ycMAzOTsUQWWilrKHjbCEtlYlhiqUxin8/9nqVI5O2WCVrHfLXTv/pfZ725mP0Se06vZu2dx WsZnERwzmQzZGw3fjZULOhvMaO/iYlpTdd2DqACfwObGyoacb0JgrocAiBKIev5hgJXWbPhP hTRJp14nv5L/VECapJRUvchEzEADZoG9mQtASI2cPFWPlqo1ZJQlkLCpTCfUiHeeKLb6C/PP v8hr8jfo8G9cItKPyvhiMqXDCzrEeSUW2w0BkZtLWYjwQwmG9QrAst+/N55P9/5xut/B5ljg wdLQsGU1ioXog8hB36EWuppcfBgp0QiwJhopNRC7kddBXdRNIfYIcMczpbb37nq0JyGRAa96 n+mgT/u96cWMdPNqXmrUsJcO2V9qf6YxDzp/ncW4sdHAU4VhDO8bhWKCneXJoU1ibL7GpQYs /nTHAyOeFWGxgREmy0ucP/AEE0EDF2EUd1vA3JRiOSIWGJHpn2359FZudjf18ry3J+30bPNv Q7zd+C5tHasPFOoxP/BsCnW+3FimcQVaQ7UDRoPcOjAX9kFroLJGPFN86rEVFDH4s56YRCAX iFHgRjeZlyW6T8qJ7pOIaMIq9gNbGLCc+jdDLLAQ86jriDF4reBZBvYX3GiQQG0auNRisER7 qEDNDJUIYPgV+CnsRWCYOv0WsIDxzdiCH4keDSFLwpJuDRKgAon1IFQkHzyq+Wb0oKcA/oPL 8LvwZ86+hSDxqC+jXnICOPchVD568lHOBHT2nHgrBhW5x1g1q+USKhfnpWIlAyU8LE11xZNH DPYVTJRTLedgUsFBQU15bcL40VfNTqvO8oPH9Iidxp9CZTVCz0XH/hYYHouHWEINziisfnhh +uDWL6O+E/tI5O7beJfHYNlOTdXX1ltjh+NscMJb1QxYcZrfsJhHZ7nE4LzVmKoeLkK25tDA A68tsAMX/IrRSf8PQNHvt+8xvKrsIW2oOYHtV3SGMuf8qQNeberz+JDZ8PHEsWEObdtDBm46 uEplhq17gYzP6TaZTJ7TbfbM0SC1PnM0KG3pp950/Fzd/Eh/dNgf6f/BvrGdO5sORBx6BoHz gBtM/4H+EAVw4/f5FIb2Ag8nJJUZwAP+w2T6jmVB85PoRFuZMB0txrm6YnG9Ux1RDesb/qaY uPMEl4ZpUtNZGTYVaWIDGcQqli/3lN1rYst6iwycS3iZEiMqK/IJUuTBstSWy4zVmS7kE3Jw wGztGXyGqTjN2aa0nMv5YZbGuuOpOTrMh4YIpcJKG+yzjzc0qOt7eRvDIhRTPK5FwWeoBvGc PYeOB0XtLQM/caztiaVVqlng7pqjs5yINjSheCuGs4G6HrvdyF+wXAoGcmS4oSdUNhCAqavX z0pWioIPiW06zg0W8tXyVRaxusFdU32o7JqZQ7K6uRfGfWTupV2wUB9JClTVtCdQSXlueFpF hUeXUHc9cxN/WhjL0LjPHAGYczaM8ERqKlhhkypiV3wut5x6X/1n8ptuVznE8ogR2cjuXdPO zxNJ1RVWdm62mh6NcFb8m5UpaKOnPFEbuKkB8dW7hfoQItsGwgAthBWu2VtkMTk5y0bn2jYr RcCi4rwpu0dHcjNY4KIFHA9CnThtfmosEiRc5uGOaKUj5vFNR1NNisfSFHtAoK3cPyiJ7cIw Yi9pA7O+p9pc1UT1kOTMsqAc2SqJ948OsI2nILOZ6BgapCpG4j4iIvBWqyX2D9PEbIdTB6bh tjaFiO5ujSwNTyM/2LZb1nxbdyvTSXkvoRNxh2Emzu1TSkGLhd7AWYWZZngG2QeDk3382SjP fbbxWHaE1O+Yt7g09FbM37TxITEqFoeD/jXtX40vtlghZjZmZlttzEQr5u1XoJbq3YjjTAql xJYhNpRTTqs8wfhSBrChzOZU7IQ/bwIJ8y7QvzbW25nKtODVZsDX8Xp+U+lWTiQyglCRc1+q oworPNYl7iRc9NLhPp0zWOvgjVt5tE396Pk1XmEWRwVyUdcvFFTRUUJ4gyUa0wbe5Za82GQu bvtGJxCes2B4DrGxI/aQ2/bZjlWddpu4rW8sSa04DsLJ69ekXceDM7lVTtp4ahB+byrjyYXy UZ4cZJguY2ET75KNohVArQBuvnFB2zgwHvbh3QjRfCbueQNUrA3Q86EdMeLnGMPwvoUw+HYW ShxTRiHHH0ajOkFBU83Q4wzbxCULuRseahqPk3ocoyEJPHLV65Nw8YH3fUQElHSwH0L+bOPp WQ05WLWsB5lTRYWyNlZr8itp3+Ol0MGg3a6TN2/Iy7MChc5foQglBIrY3arxTOdODIdD4UcM 1z0qUnjxGAXJbkihc1KkcPQ4hc0iH1eIDP0FcmZRI+ds2k8rvDJlzY3uOFPmNDzqm3waK9PY 9oJJx2U2ia8VU3yMYXjHOQXTTIezGAiRWafAFQhzbwE7CR5nUPW4qnbD/BhbhDYQgafw4rZk QGgRd/7wjpyoiIh06RhDhmdq+UGasbhRuLlAhNo1umP3Oh+zYmp3uL+uOysJAMTj/ct/lmkf pklybhWdK4mbfbh7jtdbJ/YIT0xzRcNjJ1DSQvJGx14aWRzEiumdOZaCLjKUiWPMHXmxYC+D UocCyzCZLilk4p0QBaf8lOH1xVsmL/uiQx5iBULQK5OZn97hjzLJTnojP9cYnT+IamgymH/q TRU6VcD/QjR5SaVEzpDJTkrd5yiTuFx2RP7gpEmGV380yKQPP8SeOwyBv0h46XHk+OK2tG6p 4HorxmEysPAmaPS2zcVVjxPVtCAB4r1i78Ff4xE62MmR15/xBhmRx4vipu/hk84HhS1Fqmt8 BUHC4mU/CuChkdNU9qIQPIx8C/n5A2Hko+oZ6sJkqUiMEeRby/U9cdWNOto3ipcrRQWWmic5 tLW7HR7uZEKC03NoGUQcErNSgQoCTBFI2tlGCAXFxvQw7fwYyEfpGAgojIGNhTGwMS1xDrRx eGvJFxUMSFCBBdlcYEI258fKACt4RCAWwaUjISA31goBFCFQyYnTpjLBeLVgvFwwXi4Y3yQY 3yQYrxKMFwRLQPqihNJSc6lYXFeZkUG3UlkFQKqqSBZ75o7kSomUHNulCcWruXwKQ2Cy2s8B Vi2xjA4w5Q56o5mSAFy/vN007JtSQLjGdjEwC3fIwW1ZheDdoQJMd2xfVhjFbrIXLqIpXisv MvQYgu1QZxmubXnWiTmzsg2ZbZ4iKVBxYnkIoiKyYoaQ0RJzp6zaCrGrFi4165TG616RNGrv Btf0vTIdK6MGJNmyXCuTK96Xh65iNOxZnmyRK9QCWAgTGSLLvBF44cXhHbwsXZNyEIP8jjh0 pIzfzS/h+eBALFlSMuiLP42omMyJdUDGEzoZUMgz06Ey2zdyioH8Wa6YVMD9eYrB0TYoJi82 HoNWiw0csrzcMdePyX0VlwkFyTOx/ufJLkfcID2UGOAWtZosEOplDMFIYaET6gXKkxfdeMlm 4pYmLNcdKDnXwQpfWAnsGyyAwvKl1SL4OjAnd2t8uRH3wmF+LSBgrEQ9IQ/FUsWF1E24+qxF xctmZRzXyU/QBsiDJ6X4Zkq4+GSilGOW6z8QGasrZktaQdJxJCMC76vE+wp4GQ+BphhxZ2e/ 3B8OiLGf6QUtX0FYsvYd26zdGhjmHMgkPLyHeibJCQUevCZX2SuzAvo9XYLPISDYgbVg4v3r 8H0i1AGD3ILdQ8nx1bqXLUT3mHj56aW0X4LBEar64oI5kAi4eHmOHLVfnTS7xydk8eDje06f xKt3GIgsSQEqY9z2cTwVsgCH9Zp8300ZzSLnkO/44bt96GdgTwsXOxyil3irT5LByJbYDTmE QhZ3V7OFK8RrMypS5C5Chd7TNs2a4CztAZ3QA3qf6bUyvhiO39HBtHeF5k0HkMywRrIOT7c2 O3/BuCdi7yAdOWbVkYP/30SO2bMjB89GjllV5HjuTJsVZtqW80xOszCu3FgqRq78hfL9boMk qgqnEqpcdgt3tf4mcoqFmgulDq1ITsPIR2zHJ2oYH6NFcFaRcibu7OCN/jAMoP2c5VKWLOV3 50NCOQvIjWqp8bRIEXrGQiGv/M9CbPn6V9qPoiVjKp5I5s6KMYv/cMz6HsambeLS7L8Xl3rT 6/K4ZNiOJ96axlU8EghfQSWXn+j8wZUu3r7viO2a9v1Ji+QCk+q5kReBETZMLdDnrDI67Rfi h3JxnkSPWunaZLvQsVWexdGeUHHh5UEQo6zcYsUqM2b5gHQLFZZ4I1a+tYeNk890eMGJh3ty BA84cYeUNOHn0WAwyFYcaUdm3H+qWraIqMjbE9QijpKqK1FkMq+bhPGyUnSnRNKn238LQbc1 P5GCSk7xAC8O1yXiAqfcdIoiJ+5QQxIY8Q6P6pFn5OSNF+s/PV9Gh5xPsbAUPOpZKnbEcF7s rCDVC4+4PE+iV7QHeSlfHYUYd8dME8v0qvlQvg+xre62CBjZAZ6uwnmvf0kvld6FMg21SLJq zA6QV2aZfAekcxLPmrQiw9wuXy3WDS1auZChfIr+jtMirj7xLwS96IokQ8TFUFW8sE9yu6ml O6lRmdLdf1GsTNBM1X0ztUqk9irsjTVLwQibd3+rBhEnIsK1Airfm6vCrJN/YKGY2LCIcnAQ 2iaFUNhffor28p0fUV8O/Uf0lyWV0V8WdLZBf1nMcgVmcYQGswrMb0k/RX+5vo+oL4v9I9rL 81w1yCblZRDLdZdBiVQXniIVD1Lyp0g/8jqOOMyRsRbq5fA+yiKQRoxuAEp+woOdavrhS5UY 0PpQDHvyhIfLihr3SuPsACWtOEqTEapysRft+YmFR7JjmCz0KntGu2aiZ7LptkXPqAIUPcPi Ebq93Nwrro3kGikprrYYkadHLJQrQCCqPDaTKckzDXFvoFGSx/DvGiWPCfUnlIkiJcdXcmTW m3weXtDex95whK/knlWm1A3lWFSKiRPzgEu6iD+YKsr/tvfu7WkcS+Lw39pPMdY+yQobybr5 EivOWQTI5gQBAWTHx+tnnhGMLGJuZsCWTqL97G/Xpa/TM4CkXN79RXvWkaarb9XV1dXVdSH6 8jpysTkBUudwC550h7gJ5+FMoSekgHxAsYXgN7SBE8OAoYq/3rZr3WrY6barpVNy//4tEL9X nE+tkoB7F1bfCLL4LQDfH1Ha6VRPj+vvwkqtA62Rl3tWz2qTvIWxorZcbSHzyPa9IKorse9Y YxB9v5XbDZ6IEw59MwUFKT04bwosDTelioS6lkxANGbeo9N70sS25hzmvCWknLSENjbydrCn 6wSy0jAeqzoWK/IOyoMJZ2gGK3PHp+r4VgZ0+96V8b67Pszh+QyyFLmSbS1HroR0kWvwOgu5 ss4tcGvPZTXcWnVUhyZySV3uRW/6Rdl6INjGk8/7VHyaDuCw9C166aJore3yZdGw7sK4U/DV MxeHq6Vmma7HL82qpkBxZULRTIcQggv0TMwIMDbddBZfxHM4kgUP4EeSwQxsRTDGggBPJmD0 A1c3kiaAdQzmWqORGpuxWr55YaFng3WyaSD9+N7JpAH7Vb2TRwPJLWkgWYMGkkwa6OTSQJJP A0kWDSR3pQFafaKEZTQQ+IkgySOCJJ8IQHPl0MDy9ZDy1grLIUFTq2FIaenFgFoORgFXiE1x 3R7MkyCky3iIEeUspGDTDhE67QvByV016oWwXaqH3dppNfg2qIYVDG+H5lswBAdX3KUACd+U 6mfVjt3RxUhg74s5jW4sCECKBqLN6aD3KYgwhCbbyEIUw3rYKlkd1JvNVlhr1Loh2Lzhg0G1 k+7MJ+i0Y46f9vZtgzSl1Wqr3TwNdoLjxbyI6o7x5CvQWkRGuoM5BlvesUbwttmuV8K3tUo1 bJROq2G9+TbV/devYzA3ddfarfq69uq1t+7lwBi6it20CcLyu2ZDG0eCAZvYHXUMFbmzs4OR iYxjWOCpVqqLpfchaD6bDNUINzb0XW/J3cq+7a0RD2VJ6BK8BHKJsp0PHqKZ4EuueqQgpJEp FGOwmYfqt5fBViZQAX7d/kF+0O3Z9uOyfPsHMuamCzVF3AB0QVC/EKL6QYCdJPoSb30LCBaN wMciASJic8K6AF4kRmTwFmp5MZZtC5l4PpllN8+38Fr7p/B1qVGpVyuOCfM9xpb5ay8QKmql 1IcHyJH8bLqNF4PeYjYT5TJ6RYznbxEOoy/62xEbl8LvxYDsqOTznDKDktHjNuW+S5kWM7o3 l2uTHkhvAlQh+8YYCNZ7OdzKkfALUn+k31oF3ws7pK0di+tscBlNwQQdGZrUWckwHjiAnYCu j7XGqwBDJrXPWt3OgwcP5Bwlc9m92iWuMpDSNlgph5dfU7zlRj1TpKf1Q+C5zOBF3MV5uu62 r+4RTz+zx+9X7tG6xWz5Ll3b6VEV9KOM0556IGCiRHSRfgHxan4QvWvlQQrBBKN5N3rimLXB TWJfPkcADTAJhGOwxJZUsBOcYjRu9uAXpy94GZg6MUUi3Ym4tkd9eEGBSN/Hoo/qbDYR1+U2 QGNwtK1BAcYgqIRMB9K267q9ZTS2PpEZ9j72TvaRjtYJyf1/FEjqsFaNPysLJou/uBZy8XsP jXygFTI4kKjGO9lqjQlnIycwBsa4cUJgbOiXLMNClc03C5CrYWvL7l1dUDEMSiH47bcgBdFZ CmGGUikU6DFq41wQ7ScclBshCIa+J6/fqJuFmM865LfcJUR2d2B/GbtesFebLOTmsJabXlw2 VqQgIrng8UO48k0uKKfBZDJ9+NiUpvyHAUfnpePbr0JfO2aOdokwzqLcVuxzyUc/v9LzxHKH E/mIYdgZYkx80VoEoegXczSfpI3DEet/Mh8IHRXtVuqeWhAXQ+sNuGAaIXrjGUm2k02NN3qh lmNKesucjSFOd9wPy2B6fiykYzhRgzuGLMpbvtM/Y/lqP59WX2CGBWDvot3nKhJ79ro5Rmmp BTq98wKd5i7Q44f26lTBRfxxxt5aPR6U8UJ1FyETTK1CV15ZLmjaxOAf9e9IDLdnx2vLfcF9 CH5rS373J/qhRikGU7n/mkNSHkwGACF4gmiOPC+JRqTTZx3Xx2gwNrZTmkCUlGF/fUQKxbSc +UD6Xtuft1+yBvJ3EHvSg15L6mEB1gR+4AgYuEhrS0bpcfEBD/35MG0uPPXpXQ96p/ce/PlL 4mNzFiiO22Z3Obs9dc+/e1A19qn/OoBQmFYJX0zBcKh51j1unjUqYbl5Clmsas3GC8SWuhB7 IAIekQoMIUV9LTRmNR7Wljcf1jI78MYsVDeSdPfh61ooesqdXRpmjfmlK/tm6INatZNag/AD Z2XmNPxAy9DoP8CzBgBP00sHYAMtXUcr0uWyAXRWwUBnLQx01sLAWePHRvNtg/wlUuvshVo2 gKwwlMuGcnzWqVUr1EfGOEyQZcPICGaZNQpCwOmrdqju/M4gPBDLxmDFWM3qmQ0oSt2zjtOj UbLq1jLvB05rZtEqROQRPbOmcJrd6+kavZ6u16t59rgEYxQt6zVDzF5GruU9fH0SrDCDWDXA qot3DMuNoXY8e8AuXEr9WaFYc6bFUVeR3nK5UhpwKY5z47ou5ZIYxrV5elpqVLJ4pAGy1mDS 0WFXGk2l1C2twLklaOaQwEdiPCRrZukJzcpN3X0/vogWw/kLVNxoLWX1pHRWTxNXMWCJ9pur TZ/c6VyfzOjiNPWbjPvo0rDK+ddQfKOyY+OxtOpkcyA1cREDu2IIgyJVG0H6TI7YdZTz1gPy P/z6O7z2OIHd1PV6Hn303YUtjNGS31JHm8KbvODa7T2C/Cj4UCcV9Vlw+wUjxpHCdE6FA2pY 0bg9IqY2ckko2GX80vhRNO5Mg4I2UcglNUtzmVNVjkzfNDEQiKhOtv6cybK/QDMM4LwhsN7f kKuW6q0S32PhOR1e0TGtXzCRmw8CIDYX82QnEKyTn/bRDIQq9aIFPEacXwfmmc47Y6avyNLG WeL/ZdAsn8pzIGy2QzkaUn4/4OgGVjxDu8gMfFAgF0otkgBzl0MHLwf0twqWLQYruWsJJh+l OIfoTscJOhOwRAatGkRM+kfQAJtwSPp5HXycTPqEOXZXYcUATTq9fN+/RK9c5INg+MoqfySG l8FJmUoAJ91S+1W1S9p8KP7ejMZVMB6Lahcw6gEkn1YrVYQFncXo6TdASx7d5A7lm3sYVIdg 7Qv2E0MI1gXqDg6nCwQDttfbYr47QSmoD8afZK1ZvK0MGjCpnaa4efQJkDQdRr1Y9vJY+avm zJHdzZGPmI/F6E/EJPU+jcxvNS4FKj+wA+htqxsRR3jEOB77pZdHuf2DOCXECSTqVGoVYy7B 998zC4GfrYcEjBbP4I9ZoEalAyy52io9mD7KoMeAT2IkusmF3FoP5EkJGg1IYQ6L3sWTUmLb 8N3lWAWjQZKIpeHYIsBExGIobrex4Q22KcPp2RFbeOjggCQ2Qp+3yFf47wRZwldBbRQNGx4O LsVfH8XMqRZ4sH6NrtGxNZpRmllIpyvGB4crJFlHT1TR3Kc4nqpKl5MpUBZ2BVG5+uApMBSL OYzl3JE3CfqNg/Oo90nVxNzSO8GJthYSYwsuByNA644EI7xtqMRlm6eEMNm4YCB9wUBsNMpV pCgSW5/TpAJE9Hn7BwJH7v3SbUPBqrdb6vGbflAnJIpxiq7NZmTHGxviK0ZnFwOEBKOQ37Bb PW110a5kQ40BV3ExwsVNgh9YvbUhfbBV0fa2qiZDg4PiqVrvhC1oH4fRt0aghTJNzyZBbwAV iVrj+GpuUT15VgMNV0ktZ3JdxW3ZmMtyRxcT0ufzD/DS9KumyTHklqVWgBCNXQ+kYLDIHfng RYxKRmtIPp2Dy3V/R31m2gCDmU/kv/DpHGx9tqSclHxCD2khHqE14XwSgv3hlnPMqCgY43g+ uAi/gj8COuhsccBLy+PcwIuaTworJlQGiGVacuJFS7Lo9YTEDInRr3f4oXeAZwpARmNYfjrY uBOxlSIDzfAnoDUkyg3F6QiJQOlsIJCtwZhbwIuDGG4UQNgmePQo7ARnH4fXD9yzUwsMu3RI GjLZS3SAxWkpcXO5MIXv2JPxfDAWIhG62+P5qMSMILqAZN40YzhQTczw2W5ibiewBmkd/4ZY iEND+UP8yovMGlv4IIkXMQM7DVMFv+DtA9H74vm/ZRSAoAHo7GDAc8FdkzkYSUoKlTE9rBji ou9u+6x6ZIHY4pUZPUrDRMNphAxfvSHBaQnBYDsSMB0DHLiFG+1bz9rmFmrCLXPC+kXMCdMF JMBhsnTQd/1cpjiad1DOmKDXBnesxmYyrXuYWVrOeWEIEHcXc+5JzskRdNaRdJaKOt6zYQ1p x8awVADckhBxLOow8dP7DwbBK5xocHcL0TbTyFtlo2WFpVcKF4m0FXfkjTOlrDFSo97A/7Lr G+fQdY5WkOrO43hss0iTN8rrAh6y8mAlUTFK8IQlFQ94G8hm03eGvFPgB0x9+uufcTp7DR3S ug1pgNJGuz0WPwHXYLfXbDY5ZEsqw8CqOcLy1EvwESfAvhUUI6cYTKPr4UQc1pCdg8HoSVNG OMLoUZC+nCIfDDC+TRQk8RSSmMcywg0u0i11NyqYUI7ORsWOFj/PoJKezAoVzWPfqmj8oa4/ JkqWKIi2Azbql06wECWGvZejYW+BYeLnk3k0NOIEWbGjbGQ/emktSPDYFxsNNoIF9Y0LZRgQ cMvSH1wMbDqbfBn0tWMnXpSiMWaaxwiM7hAzwqaKsVpd2PYrKXDBP23zL9yqKuefDvrtVnwc pAKbZQ1p2+kDBEwoMI2UjCSEmD1JJhyEHZyl2F2a1C9z5xWNHA1aGXo9jQFxuN2LmAZqxR0K pv3RDOx1GUj9qWJe+RM43HVru8xTcFVu8ussmobRDB4M5HkmrSKwCOChK3th2KEubSZ3P9rg vxhHUcK/BflNXy5ygH9BonsPBRTuiSepQThtoSbD/Fb463IwPQmXknEW1kfDgG3LhkZr1O9l nDiWGZydFMhisCBLVz+yqqSWPuXJgds+HkH0YbexLe7nETer9ynF64CLLNT08cH0oBH0Gw8o qkkc8Ac66tGGZ8u64NvILx7HV73hQhwgxDZYX+iOw93uaUal+qRpsm3XTT5iRUtmpfTMEOj7 nGltv3ShH3mMk9kJwh2I5YD9yGbG0vPBZIfqqi1FRJOE3ca/6Wt+rgMsftP3cVPmFvmnQZoP y639SjTtRNlCl0ry4jVFOnV6iU5Nedm2H00FJrUGlgq06IyTpW0poMRXQhgXhw3EIwRuQ2oq sq80T04V4asgB6MH+yg4VIyaWDw+49GLWU6tA3UunOAPOemZJ6nBfc2KT83nQqMgFU/g8aH9 SujM6JsrEgj4V9kl6YvSckPRk6gJzHClQsmsQVsiIJ1b912rGtbr5bDTKLXw3gwXMvIDxPhG cHHaSh0LtNkA0tYOTGcCo5+2IPiSuIF2a+VqsPlN8iKojf0yVCE4pXhKidjIMQg2/dlkikp9 Soayg/SN2mgYOm0u9qLEPCg7s6sQ68R96fexhqC6sb6oypFPbyGt3k5eXS6xyhu+tlegDzA1 gw/x8JWwJmUIl6s89AZiJnXqYCirWef2tm7xyFZzmj19g8oW3QQzLwVilBrxbFO8K1BBZXvT ayDCcAoptT6dG00VioGRE01/ZoOVWzAzpQrw9avHbfXrTEcpTzLbsfaZ1VR6Bwq6h9xFQEy0 VZAqRDNYHARaMWZqxVi1xraHzFORw0oGskN/+nhNwUqI8/cFMvMC6fF1WWLzvX5q8vW1POmb VkZ3/5fuXOzJwdo1DFW1oFlvstISafM29AxEKmcrpInUzbZgegt0THLxOAjkLUUWtayeh/4+ iMXf2/9xWjnHSf+1SCVnITIpJcvM9bZKLPE7xqKjy1+RIOP+uVJusVTamw+LZjJ5ONRmFA6H X2IEksRk8G+d42g1JdjA0HNxImtOeU//Usa7J3v7OrWYYXOB1OGzRsxC1v8lUl9dkUQYWl1k skK/665Tlz/zzge3K0EpGXeq/ewr3Kp3t5WvbLN8QABhCN8jqo5mPb42LQXB/gi1qmheQMaH WDACc+IYzSnoq8wPEs31Y5qKM4tPY9BXkTjOeSwucUMIT42WFlTXsJcRXAeYWJUT9IJmF+LW Yg5g0eU1Ou1TKDaq+zZmVjZMKN41GcaYTSqTTtH4VyU1chaC4Ge4M7Qr72iihnppR/PKKIEZ Q9Ar2G+QaeBCzloMUA4WbcEuoy9opYoJI3tgGSYY60QwkHj4BfyXX81ms50dOzw+EdLLAC3P K9VOuV1rdZttEhPXNWjLsuFiC64+G28BNarbocliTPMsmQwDmZIogNSb9Ml4wtZZNqjINZPC coOfos2e2YHNUzMo+TlfZhQvzoD7Tu7ODYoc3Kwco7Ark499pjBD+K/B13eR9RYdnryL/zPH jqYCBWmDc4anH1Jsp/oTbAZ492/HQ3GaCTJoEjFx0AE2u3GUVx2ZKWzHsLkxzqnlzAtyFcBw IbvNE3nne7hltgEFKkGIiQmYz/6hv8ozXcVeoYJxD5n0z3cu+zPJZ3MGZhgnq5TetNcrx/yM bmCAz+b1Zv9MsebleTCMoEhmMoyXAf9VcOmcv29vH21Imwv0HtaNG9qKX2hr9Cdyh8n5iJvj Pm8hoGHx5xahWEoj+mCU7/iQeGdg5ZlB6wCI1Ayb/r2YEVjCVHWQYGnfMYD52IODEulIbI7L mwWEn7q0oSOnGduCoX8f+KgC+4XiH9xiBxPKQNM3pV/khI7POu/8XIabMXXvhpEH6wwgWQoc Hxeo1KbBc1iJTWO8y8XcHEHXVWKlWQOmbJngMSR5geBK5n7XewlQwHspnc5Hkgj1y9oYO22g J3byh2Lw7ZbqoSCYnxCgJhdbYgwFHyfzDBeDVKKAhWfciKxA4rgvTQkxUc8Fnb98p1DnKhnH cAACdVYas8/Zz0vRYNxBILCytTBaI8PM7iW7LCCrLhiKV1nO+0JRmVlKlKaexvihUaWjCI5L YalcZhvSUtj+Z9d/yLfL3Xp4XOrUygBvBuY6HyYyYsEsHk2+xCG8bLi2YEpZvmEEaOTOpUKM nkQ6cCDtXn1zZcpwoCSDZZ3FyVRI+yiroNqMjkQ+/+RQNCL14OwpHHc7lv1qp1sNzwdz5QJn MHvRpRCEII0HkYQQGC1yUPZS3IY+4X30YexfCf8tBWx/4836Z9QMvpVkhfC1xhvJawdqtCEW Ic27aLdNp4yYb54lFmRwf0ssGvt7if+8JTYWg+3PAeftUKCKcL7C2uA6kIrBWA0dK5Y8mSx9 jrjObBr3mR3DH21NvY7Fj+5Pt5One8jS7uR7DWepeP4Mv9AV1EpQNkumOFj+M4nFxqPRKyPl FQ0Z/WZQpCDK8VOFrFXSvRZ+lwOSabjpqx6X/s5WXG7gNliZxFkZmePk/4ZG6ffVEK2nsFr/ rf6PUHFposoY0N5uQakYJcXhYAyQQ/U81jMChUJqNo4z0O608IqConCadL39ss/yxpKmO9VG p2rcf1J70xr4o/TOeRwcHslxpTaPd2S8noa1jNmf6b5rxKXSMDqYrmrAWgWwrZCjpFFgk3nb 39QBOmSWUgYu8enA0xXA8soNv4wMnwxO48OOFjh3OqRQ4cIXlHSpvq8o5645ZiZFn+EOQApW FA/7hvvVqpSBLwC0U7P7Nwww0vTwPVbk+yI3lQaznuR9CJC5jWyyIKwYr/KOS0vWNE9LnR+x Uq5biynlrOrKgk/YWbJU2rZnXf23N82SJK9UpqW/wiNX9omZkoL8iPOHSvNJA/LFi8pW3dq2 rK4v9ewkOSCl/mJ+jOoSLK9iuSU4PthKdYSdYEij41q3YF54HqoUUJ5ntw05AQx2J8+9RrNr jVpFJl1P1vcrGx3tayK1r67u8e4a2LWyaQrEbuVm1KSDyhhVSj8plZHpfrgL5rmpBaEkaZym Tes+lBO3hbAMbRpcN/00XdjM1fzeq+L3D1D7+lW++Yrev4jS1qtofs6SdgGfvPSfHuuv5TrV ZVSwIWNwd+Jo1rukPK/zJCD+fOluSTh4+mKZZxPBoeYPUjFJ3H0KaWULEMF5WfbZrdN3Yav0 qioTGrOON9XeS+kWqnCQZg25fZkPcgaPE6i+Mp7fLO5n3hLsyVmPvkYoUa5ptwlYbkUzcfYN OKqLWB96dzTDRKzHpG7Ppmyf1xxWxeCr8SpfvJH74VeZT5ym++y9E2AeCVpzvQ0ZplVafExz ZC7BP+bR+VB7gUhPWdLUKFEQ3vg53CuE9JhZ6RVL56ItMMgEiQFeBigT6mJKzwiCdbD4Zer/ 7a6XviJmpcq0m3HyZub5yC0JGvc72abl9/p/20bNsM6gHGuUSgxCV59LAw2xS6WJBoJL+uMn KfL3wABNWjz9068AKyzqTU66hXv01ERzBcPlwuuBEevniF1SS69syIbBenDr5eksL5IQ1QO9 ST/254b422vyjl6TaztI/hF6w/V8odZ0gvr9vJ+yfY82tOvRcZ2D+a5p/6di5UA9O1iO89pm hMwp4Z28hmHq5pNZUTPLAFMqWfxSSmn8Ik9nrCnuGS9Y0M+qj4mb2R5bG15JyQmvimirSrTZ nGmJudeGwWdQM9cPKSKbIEPyHtEDYfQ67ZvLkA5RlIrYk7CAzm4W16ZMLR9AZ/FccTQHrdie g9eKjdfdlfFKUqbsDZTVgI1w8glnnuVqU6AYI2rMMgBaGPV6KghaqVxe1rmMRcMJsimui92z BpYxcSwhGRFGB4M6BVBPxRMybjMmLIR9GkvgNLJxPkk4+2WuCKCYOnhUf0WjufRwb/KiOQkc vdChflZ4t8/ApKYObjWTPpxHewjeZVBJbL3Ya4JX3zXe/fS93pICnqezoRE4r12vybEgcwhP am1xcepUfzqrNspVo6oVSy8jINiaozE25BKma54BZl0nDJcdTszooN+PosDiAIYEoOEhoBlG LOTEtGZAMwWkWW9mIMJKrV0td5vtdwKR7TfVtkxjl4PHRmphPfHEnOmtu/RGW+Es/oygJ+VO 2D4ph4c2aNIzIz1x4j+IX9mPvwzAGASNoiPx5zC6FifWxYQVrvK0knle4QxDHrkSPhfY3tYT UFcFqwz9VUsQ7eFyMgVC16gdRbNP9AQhTh+X85YqFZSC3i1vtVSpdcq6WVKlKxUEnnPOeuhQ cJJ4JgbLW2cL5vK5ljkwm1lhURa72rROX98Ql8sLGehxWOY6oyAH3H6s5QTY8V9c1BrRQTH+ 8honoxn37W5zNgnNQbwoWWfGW5acBI8oFcgQ/epVVVTjTIo+kFa7Wa52OgaocYq4B8AKQsOa m+Xm90BpMxOlzftCafOsm41TeMBqQU6zRteis9VmZaACbalz15VeVlYVisqnjQqOrnPWahVB /Vr9uVVvrNN1ml5+P3KpVOvVbjWDYryLL/7X/mf3dxDaqOFV5bY8mY2UYXyFA2+oy08UDxru cVGCQcj7bCxpHnck6wW5wp5zwmTIG4kt5dvnBAeTzMJv81Xz98CuaPY+cGuOI0fOKaq5mEeX vB3lEixsi9gwk1VYLyyJNp0sZVztTrnhZ1xQssYZvNJE1kIVDCB/8CelditsV396YVF5f4Lv L8liiuGJAUgRdiAkRLBpGQpRfHittMODuU9ZYXaxKib8QsZx9+cMGUOU/EkH7u/Ewu94kFp3 NWcp8pQcPmRxENf5lPOC2gFmZc4PkNo4BQNeGDAEPqTxRR1YI2wJIpJVxKUBI/7VJ5PpAyAl yu7L2RyAo3KtOsaF1dXU9QEcNNVj2eTiYjgYx9YtRowKk4FDkHXI8iEugdWwEnabb8CldMIs my4uidEwZxAXcOGbUv2s2iHnwzknEr8YiWvYF50+3KhSbzbFDaVRE6vbPOkKxlIRUkS6em8y vhh8tFswTNOtxSnKkHop5NQRnzs7Ozr3uR4JDKJWqtf+VfX1buc/d8Q4vay/0za5l31ibZTV d0q+vqjyJvMC86b8N3MxUFUtv86Q0qHkb1SZqOp0M6gKSv5GlY2qTiaqOn+jypQ2yxmYEgV/ I8pEVDULUdW/EWUhqp6FqPrfiLIQ1f4pA1Htn/5GlHUjzqKozt8UZSGq+yYDUd03fyPKoqha FkXV/kaUgaiuEJgMXU5jAikYh9eQt3URj3txlpIG6t1JQdNuZAi7ouDvFTIR9SZTgnvztwhn E3MrSzSBkr9RZaDqValW8aMKSv5GlaXyLncz1KOi5G9UWahqGIfJ69FoBCmG300WQX8CNt/6 gaAR/OMf/8h+AVjnGeTO8/dPpZK97JW/191GViMTV42/UeWgKpuuGn/TlYOsnyadth9XUPI3 qix+lWlVdbKuVdX/VWQ5KTgtLLHbQiq4k4ko19Xm/xXEZdv6Q8bYavtNrSyVp6YfEMRfygol Y7nagGOGSutOps5mO7YxP9h33r/BNrd6H8YprumIYZCqjFfthMcZ1rme/Lygjf5n1XeA6LL7 mMNKi2+l5pE5P4x8H1sc1/xhITdZiNG2tUHZz9dIA5LanFkph+6YDOR+g4WsnGDj5HRlv8CL ETvD6oSNbOCgPqec8MzmyRBAtYKbJ+pTyGDDBIBjnEgLALsPbyV0VnaqKac1MQIrulHXbY8C HI1UfCO7w4IKLzXSEXDqtcaPYaX5VtonSqoZCKoKymLq43gY1AfjTwEAsQHEuhPfIOIccrLj bwFabmH8VDjyQIwxUXF2+XBJuSfPshmRGTLRo5mNkaE50wbHiHI6pgTKcye5s10tXZCdFjoj h3uqhXh2MZmNyArbKGcP9Lo4lRZzGeN9iEZCiRneKRUFXZ4L3sDpGDEBoLIDqHPEhi0Fqi2V 1CexSuj68TIAa5tGWOp2q6etbrVy5EJyYkOupYKiWwmxx4tRSPOSQT44jjAKD+nlkZnijUzy 4iINybQHcyOPPEeXyLVzupWR07oWTjoJtt8RRxqE6ekMJxOLTuUSEFODZN9+Dx25gDTALQKk GOfBb4G2rzopHbfB2ZIsrKyiVrv6ptY866xufmVEh3Dys7nTuOdZ3H2od7U8c6ZpJoXXMkht HNQrbxvrWKLdwgztRp7tgfhxj4NGsxG2Su1urVxrlbq1xiuZUVAeDJVBH21Vo97nxQBjz8CO aJV2gloQjbBoCpkfe4NpNJfhw6EnJwRw+hA6axFhZx1P6Kwph5N9TJ21NjlLWqobz+QeWATn HgzKMQxjyNin7bdBs3ManrSb/9Lhh2CfziUPIcvmdrvZFoKlkGk6VRUG3YWCiNzgB9E1wgnB 4i85L12Q1IHpAgyXAWQemSlcNuuVsNVsd3ldGAEumWvPuszj0fFX9IoTxnYCX9j9Q3fnnF4T FSoZyHBKtvp3T2F3gDmnsBXkCfFhIUTwo11EhsZMipp3r3ZPEAbKMfBgVdyaurU3mnHnMAob UaItI7B0EFEo+u35ZBt/CQhni5nYhZMxusOLucXinMcANBxjGqDG4qO4EIjPYi+fEIsJuhCo vj8bgE9hfxJTcpnrWKmgZf3I7if4SlEmMUae0zbdFwzrZFG9L1hIbz68tmNeZyxFipiyRSrj aPHKAyqdS65pszrz22EXT/qVDJuZJbe6rXB102audHwcltvVSq0rjq8GEMkKNs0eqdRwaLVP l7NW5uHS8Jg538bIOR0Cytn6xuBcH5AT8gE5of3Dvqo3OjeO43gst0CG1zKRQ8DyMaUcwlcU KAZZGdIkmc6z7fhzYiWasN2EXYE8Gk4jFFfh9hpfKZmUU0hkRGnUs6BsQRjV66RdOq3qhKwy CuBoOhQHKbh9oOcPevyCbE8em9tCrkZpeMeN+JYp699a1M+S9FcW9JfK+TdqZ6el/IwbkKak x4/z70gr8YxVqNHInxIo7ntBkkdvMoK9JIhcZvIIMfhSGMBBihHAJrRgkv19BWZJiwnaJXL4 lsHnbG6oQru6SNEpOa52c7FlnWRMYSiKyKRlEBKMO+VQfNCQ1gTaNETfQfM1iqZEREw/uoYe jv6WAjKJ4BOEnUMyMyShVH0ZM1kIlQGkAoC4uxcg7qHkSXInTYRm6gq51XqpI4RAcQA329UQ RTSeGzjYTCbBaNG7DH5ZiDWdUBAtXF9jkwHc7Br9ESdBD0O3iTNPrPz5ddC9gu8U30SUYkaz C2dzGkKmqWDI8ImzpJkgc1p4NwEp+tc/R2S9wQTvG+krRSdsoh1wuSoknUrhVxsThtQassrQ OqWV+ks09Fg0JNg06TDlMZWhHzNVYYYQaHS3c7EY91BsgTTFSTgBNS4U+KFlToTFOBl8HIst O5yMPxYuBn5oIb4I4QaG0j4Ddri1dfDw9b8Kj/cwCoMgoIPdYJTEPbnNlwrzFJgiDyADn5pP 3li0s5r8ulSArZ/s0cvMCpD7BSnoarkE99ZJNBhu14AJiu63oc4OL2+ujJamS7iWvy2Jba2J M2e30LhAnwOO6r96bzoKMaX2ca3b5oujcwGpklgIWE+EaLEjhC0DPMDnKsHYNzNuU2Yf4dsm RfhfsXkhy4kaq3fRbFVXaR/A1mu0Wlmx2Wpl9Ya7P4flemeFhn8+rQmRoxKU681OdfX226u2 L9nXuh0o4RnIZnk3JrjbiSnLG8I7uHZqoPVldoNvW1M4LlXCUr1VWq5v5Ieq86gfglAMTNJ7 j59dhaijo5u8DDiGd/rnf5aeRXDik8EVimzHB4cyr+RqB7Ec8gOvcCmw9sAjipl5RhXGMKj0 CYsB+kSDDK2WYkNWKHiz+RmqY0f6MzXHeplIaNSRTIzwbFQdyAvd9jV9LblucXBvs3d9o75Z IirUa60TR05QqBBlWyfPC87pn8HbQWt4UqrVz9pVQxyy2X+nA8+SndqrRqnubsxKPCfNRX2S QBbboCNO/Gho7nZLGXbWxbbeNcrLW7oe9y5nk/Hg36gx2cmbh+Dvjc4pKLBL7Vr3nSuqCup4 EHQ4yOEEsgpPp/F4J+hMhgtoe/uH4DXECmjDRjADCbP2tBUJXnEdVGezyWwn4CU3qjxIjc17 7/2BsgWCJUbHFe7c+5at319+JwOZx6OUVCR1k3cdV6PyzSJrZNAg5GQehjYEd5l6n04/C6s0 l6mHam+7WS/VS59H6OpJKSVJQQfKt2KQQDiACeWHVgwkCSDF8miQJBx1WtICBwfbl7HBDB6S wihqevVhkH6esh/U1rtPy9wyywJZ2lqg3wI1yvfeUcvkeDK4f97USIr1Anxv0DgJxvdmq4Sg y2aBlhTpF7BCQQU/89bjtK85u9ecmF8rx4ffcjwH+TuSx7IOI1mZk6zASpbyEkMFtZSbyFMs tcWte6R9VQzgAmnl5zP2vJFsj78+LFiJ9UyTlbUNMAw7J3VHhoCMMEjvXTnrKqnwucRWw5RE nGgmQO0ZwiRd6WSS4Hu8o/Ijy2rX1ObJiRAgqp6rak1fT4PoAvL+8nvASpfV2zwn3OIx4dZP CXkPCRYOcJmLa7wk3O5OYr0WE8Fkqoo8T21MKnjPB1nQo3kQ9IeaB/9iOi+mprYIKVerilzI XE2RC5xWFD03FEUrPeM6mqFUeQb29PLei5LFWrC/nG7p91MuecQ8SR33cwBkrl8WNx7ePzdO TTLrNM0UZzPsC8xt5Sk+yqmZt82y6qR2m/3i9DAQWw933aqmEc7eywBLoc+HuvshlhWtIK3v kuazl9veDP4EfCCmfImGi9g0tbXVOUVuCPIqQnpCqZDhLIzirKIMye1q9V9V/sipNsQFR1bb KwYqzxefLdivfaygLa17sMBWQFhkR0ofFOh0OZPeZ3GlmfRlNord25vukv10Z3Ix/wq3L5w6 XcQGo1HcH4h7AYT0E5MqkuVEJHN8CZjxf813gtocRhadw3P1wW7QEzfIT5hDqC/lBeAEyuqa ZvbgpcupiC/SI67Eo6mHGjx6FPwQ7Nmx/1lLgKqA4KsYmqDPRa8XJ8nFYvhAmYN3rCcXj8mx zx7+lqbQfD1NqQg1UbE9EnVrkMzukTerE5EPxPuWbSoJTO4JH4f3nhsrmpyvJrIT6XRVAp/5 1wkY1PQHwCoTMvNViS1Ex/EOAp9G40UE1vl9ygkENBLPZsAok+iasl0Ex4KYoKC3mM3g4j6A JFUj8RvZ8AwSqtuPexRzMsGnYc6nvgEE+fhxtsJbC1zBrymdVrpctBV8ncw+RTPMnhXhxaS1 Ezz/LjBEx9fNTjcsNxvddrO+3AglW3NiGk3ae2QF3mGqWrkNviusYBfDFao/17rherO5scUr D+7Vy69Er3wF9iNfvRHfFhFmFtz1EIE7yT1Zor44fb/MolHmFoINJLaZ3Md4ZnMfVDO8/Gp2 xUYGA4YZ9C4HUwcED3l/Q3onZrWjIUhWmF4+ebL/NBzPBLtB63LJPCQlCsY9jjn9YKtcC99U G5VmG+LS18DJpPUani0AnTTLA0yJqSS/0TXZ66A90uXg42XAyiAYO5z770W1D2D5DHn1fgvc okd7H478jQ0nX31tPdrPa+3Abg2FzdyhPTrMa+5JVnNZg3ua19qzD5bPjJoqHlCOdaiNVG+B GIOTOUoOz9egjQpvATeYIWAhhWXL0OJI2BoUAMY8+eX1uvy61gpfl9vmPs7bAgVKOvc1Gszx /QvbFbLFx3huNj8iDfHeLsP34+0oSeLZPHcMleo6o+BUWGO0QRKIDuBETaT5jZyzv6dqA3Jb w0YqBStPWvZ1fj2Pg+Rr5G28dNoOj9+J22XnbamFxv5ht53RBbjnhaMo+WSxOktoYL1qtvAM xfL3vspejXmdx3PI0AEm92DrtWekkpOGhr40F0p7OAspBxcm0AKl7pn4RTu/gXcg6AM4/xSI 4dxCSEobUJ+JrxmtK2NG07bRSGPHM98sGFkOMaDF14jmRs8n4JYoyHCyEP//dYzYoASZD0EO Tnqz+GsiU2RiHAyt6RUCOwimO3YG7j5zXPPdlp8ZTGzymTIcUnIR8oTECz/8XTjSjNhNyHZS BnRBdc5Tz6bLw4Sz1LOuXLD+D8XgWymTiE4oTf3kYgvNJSmJl0BTfNW7jMYfqXeZ4D6v1ULR aqdIK01enUUkoiIvT9EiomLAzs80RTVD0Sbp6bUMJT4BEkH/3RLHVq3xiuxV6b3AgCFE8vOY tebZ90oz59bqGyM/3btnw+xm74TOkp1Q/bn8utR4hdJRq9kQfA18i0p32AcwWfYg/X+N6FzX +9+Z+jSmcykQs3FkU1+P85NSmrQ7UOHeX4cfw5Q3lYhqzlCma4DMOgaOocKOGZsAsqQnW1sq Cc9vAWZqxmzsmLAOW9dXpuXNQAABfytejr1x2826sZHFBPBmYwxUetsP4/HH+aUaLcwXh3hk g+NOteZ1Um6FOLxys1J1wWN4XRxFH+NwGg1mqk7tFDDQKtXabgUKPwDZqtHIatcpnswGYpND +kt/OXgyDHrQm+AkCfcnn2W64jpyctaAFWhXS5Xw55OqECQr78JKrQPyVcUYzL1wJBiSYkhI bHfgR1Y7d+BH5kb4nfiS3nnLTsVJDk/6o/mPd2MppmR+tHkSVG1UzD89nIw1vJyMV58tmHcG 1x8w0H+PF891jtrJprGI8Df+g6FRFPlbOW4MSLjczL5odiNJu4eY/9Y0xhAUd+BW53fUQT/c hVHi+Hc/ZALtKaC9bKB9BbTvAukLJjpZ0dQa+NgWNsC56HXt1etCZiW6aqdr1Ztv73vfQ89F a5HvKIfcYbt71v6eRZDJZtZdkGwjc6SO0X2IHPct+K6/5b2bm3JBLd/NbIwDqNoZ2rGRiFh1 lCMXXJBPX6ZsUuC7KbCU9ipr62xkVszdPG61lCKP62FCvOzeXJWdW8vfl+QcqoLrGI3C38iR /GhxlEWee4J4xCc+Pbwi2YqSqyF63QubQQwQn/nz+IuPOu/MYLzSAsU4u528YH6HzHqK67hp pv+067VHOsBEg4W15AHEkSUR4JedNFfRqQzT0AaOFPyW+VHpps2E2sE9H6I4lj+bvL1outcD VC+Z9wg9nycr0/ytROPjUgfC3xx3O34aPl6HxRlUvLsO4cI0N/PFsGOiIJcKwFOWiGR9xaAz /4K9MmpM5rrQjKaoeZl8ylmZh0ZEO4kVvTQq773EEy0goSk3IiIaMFBGc1kLg04eZGVCf1Jg NUOqBrwZ9MIk/pxV9Zmn6mQaj/PqPDfqGGZqNLNvrvRg4Xfdv/jLaBmfnHDdCLzojriooEkk QJrbfikNNsPX4n4vLvf1akNu0wdb3DMg8fmu9gnSY5R+N+zZjLEIjOHK8J4H0nZOLSEqCcul OnivaN4og2weaSszte5SGoCRAWq+F+v0dKUBnXbPMCKhDM8oaq84nna1/CY8qVXrFR2GIWdY iNIHL6lv0lb9upE7vskF7X0KG6miNy4dWK3xJmyV3tWbpYpcsbyBpYiXovNsrLCYZpXNFUdX bjYghOlPy4alyXfl8VhVNu+PrOgJqoxeU9PJPB6D8fLwOuhdxr1P+AA1mszA7CYe9hOIKyo4 j5DUhRw07geLKcYdQG+beTT8xCEARpNkLl1u+jEo2ZKd4Gi7QE9RaMgjIBNRHs05cyc8smKX YtbRLH5B7YL+ScgRF3Ekhk4RMK6eiw1JpfOJ6BPXlix3mCGINodC/pgHewIMe0zP3Ht85r65 /CXfWTw3yXJ5LSnQeHvBa0KvlyH/ccP3eifp9f4KIps9s/uU1yRyPWY+otQIpwMjzKE9UZot qYkpFm05ao2HcIvwjPDL6z6xSPI+KR+GlSo0EVZK3ZKocNboNOu1cq1brUgbr3z6pAUUHys1 cQp1m+13OKpqW1Qrd8PXlXbQm4eX/ZlNyA421eP6CZgGLqYBVI2jfjwjJkRNiNvLFzESUyUg kCBA29U32ACDXaio0O6gwlKrZQMmi3OGRU0EY9SAmUzJaJHJRY0k+bLnfMOdCK8c9iuKmJ7x GMSwo+gKQEODEsym91PfzGubWaKvaU7BF8HxJ7NwMR58XqiyFTgCx+AGIiahRUefFkCHFJ6Z 2YbUI8/ELjjcoY4LgmHQb0pPSnRQsAJ9UJUkT70jQMV5tkU7NRgISepgX/z30SPLZ5AaOh/M IZTP+8EHHWKIbDVk2pFaS8iHYJ9thyayq+9/oFhEe0eZIAcEss+d2PwcUcSDX4O1Yg+mYPXH sFfmqrDUR75A3zp4uXfVP05F9TWXneuQiwftO1p8VDwiX2v8jFrITsGHYI6lvjaGqd+/Eopv fpczzMdXfdJT0pvl2qumjy17HTrlduFOp9ctDAPyn/3yTycOBcxHWh2PJ+M4Eugw5SrxZ4Zc xfM24Gbxx9DwAuJj6axeF6fSq1qHo9zctzAmev6jhTFDBrOxcJ/0KxciRbN2UI480hU3FAzp sSvt9UCkOI/l1Ros6cFfhT1BA+lTNYAwpK16pSSuSl8Gs8kYfAoMk7wlPtrG9O81eGFG7EK4 lV1RdBMMUIox08fbHG70XHDvPg4d/g/MReeD+UBc69Snx4Y/ig5o2Ne++eRMQ5Fd6A/lXy/j ohT1e0sxcFopelmB5LzLwikaYR3wb1xS9sCXDgUCAzLoB3jsBhW1KOQPa60uuX+AOAD+Sx8H X/DqC4ENZbRDnEbc58jz8wlny2BPlGRCt9+v0vbzMvqCeTSmcggyYt78ciJOzq/wL1WlyJLQ bZjMwWIOvMwG/R2LsKz4yKZToU1vtlehXWmZP6ENnfbbRRw/PLC9d5fHcXY8CFMAqY3sZD9Z Rc1qeiI9RG3ky8DSoO5jTDqKdYDe6Gz6hAjm+E7SippVClpNcORhG3wy2GPddKIRxGD6C4Tk AUMCzQ/8uSRQcDoKEVILOD9OiAnw0ca6WkQU65FP8Ed5EyHgA9uS2PCfS0cpQfNtFfQDgsC2 wB6+0c0PstFXMR6NtEOr9MDhRCCMXT6XyWMtgZdVbJjrbiQl0ugi9saRvDg6N5RyI3q9ez1O XcKIJ72x0bzEAHCogEO2WN0jO32+WzCuYpk7n+PTWOXr73y6AwmGF6uQjcDx4qh3ybo+g9eB 5x0wwzFEGe5DlGFiYWDTjjeneAzCwCBOnHPxT+It1m4cxtGXjM0o5QtPUYo9+dD++/g2+6Zj hotwwybp0EXaDZ5DFumQShjNYh4HdQjW5B6MMh4slmHgPSOU0rIY81mRZeiqnBN0yrzpZAao z7Ym9J2Af9CCbKy8Is7EHtgJTf4I1GYGTM4PgjCfmNnSsg/j+SwaJxHyJtasW1ZeFvad4MrT YvDwcypwsvg409GQ05pxX1s4ZearnwHJUJtxDI19RnxBX5+1NAkomhpU4Iyu8GkkhOdJb4tu Q69OWoJjNU9rZWVhhAtu9MSe5VxPMAwxHoyAncZnQb/8cFggHA3jAaRfC61HVCjGJooUbvkr zMcIHy0vG2ZsaR6mN+z09Mhwe52p5qaZJCJ12d60en5CyX5syaAMH1V89gXipsHITHU5ZABo +azw+9IdDAApqeSz9K4yo4Rr1eKKUb91fkXumzArR8WZotILaCXoMco16UogqSj7jKRhxhr/ rIKF4ouZiR8SfqZ5u0LhQFENn6b7W5tlFZfxYgCiAOKT0ghai7jpTa/I4/Hae50vBsO+Cj9w iUr+HMaD0qp6WSFdhf3EJ1VL8DtK+hRUXv3Zv5C1DF2VQa5s7IYaE32ScGWOCKsuxmSioe8P 4AXBCR0IRia2tJLw+ea8aXvmKpkS1S/cJEqYNE8rcKB8LalAcpOBvo1+FPfPyeP55WwRRMEJ nkX/0A6FW3q0D1QwROVmyJENjZg6ToREgLZasIfEofwYYTKeP6u8wA+fpo3PGwxAP36wZCKu d4IDirMgwIggtQN4Zm2eNPzwODLuHP7DGOrE86BenoGLpTghh9eAJcRWPBYXyKA3i/sDIwSJ jCzbrrbqtXKpWzX0VWZvw94MRweiAvjTj6bquWf3qgwSLiS1K89eHlDbkkms2FIW6oCQEbpv vpuQXvQ3fflI1/wCdvdY03px0W8t6SqopoQaYvuMUe9KdVSqUM+ayWwO9EvGQqn2aGNmN9XT 9/E0gDxBCema9XiwZkHO8iAnsj+8NQMvUJK1uEUtIHXqJSRc+RyWUVsgiOlTHE/hGO99AhOK WitAtS4FKLyMSb4OmuWajrPKGT9nOyytD40G7SaSYG/HkxwlpUImI7p2s1QplzpdM92jH6WS UPd0YJCV6+ybQdlM0PFXtcLhGLmX6gYu10trJZm1nGenjE5h/4NReqGI94FisL9ubQhuQJXB 2q0YHK7RQCLuyL3YHIBo4+l6g+A2rGE8l8O40dfYzNMk46ytVo69B6w+8vRpeDGMPib6z2E8 NgKgiXtO/3znfMGKN6l62sKzsPBlAG96k/B8kdDeMZ8IRL348oKrJFvYjZKwRS/BN2KeeNsR vz8S0vphsK0LnJZgBFAkW4NRZk+/mTH9lLTgChWiWXXRGZsSBD6O5IsTUKnxlheH/rRfUziu EmzgEM3eLDxPxCxhYBafZ/aKKSLT7B6qzCdzRoz4V2JXDcM4y0xggW0BkjarTEPKNfK2QSvm r5Q5TPPh3ygpGIYIJtpMi4RGMyw3T8VtrYFhaF4YHAxaMs6sZEuQQFiulzqdEIQI+Kta1QFG 4W/RGgTuUH9A0+IvaMX/Ni6gsWscQ7v60x36z+6ERnUffVhz9HV4Y61Q/pmJfSchByGxjmgu SuJYV99j5ZaGuOzPJAshCjB5BwWyk+GbNIt7TwX2R4xz98ElMNpWmsSSLbalTW0JnTkJw3Lg IR1wONvkE76awjksTnOIcLcTnMxgZospvyBmnPCihrwVpVVsSOdw77dsXwxGcGTDArJoKmkT aHFCpPauHSJOTO0yHk5JIAExBV++oPvRYA5BS1CZniwfoTlE1pvLV8LfAi1/rTjwNMlpaFqx VIlKxq1LxGGwCh0JMCYeqEAv4QbhpHXAbmCL/NgehtWE5aI6GFtef3KMTtQIAhRNTy/DL/Es 0WYEyVbrdfim2u5I+4FUZDiDG1Mz+CqG8xf/5cuNbAyjp6nAyoUjO+atqVleq9lWd7/VddrF 2yZUhWuiip6vw8orX71yuZDqLG1FzB2htXo5PHGHbrZIHa3a5InVpFlDbN8vIUgxIZpSSzs9 quZkPUxVllGolcEzmzpTbbA6P2u3qw39eNXx9D+E0Izh+TXZA/QijfE28PETcUaJ++mrZvtd qjJn5lF2KxQZOmuYq7iP5tRczfma663mPppZK8d7VIXhQgvSMnKpvQCDRcQ6JLlFFHCDSt7v flChJbSpJ19CUkPRdShuOESr6BmHcF4NQVKD6QAM39eokU2EeRVtI/tFPO7Fq82KFzYeoyYb /uPs9rzK0uchnAr2Ku2RVpwo6oQMwNRa7q+ylnu3WMu9tddyb+213LvtWu7ddi337rKWe7de y72V1vIgtZYrsnHqZD+9yqpDtt+GXAO1imlgWKnWa+IsfWceHndqPAsF+2vT0/7a9LT/4W4H lG4ml7rwOnEQeg6snBZvT3b7y8iOxwNZ+FYZSZoSUXqczEyT8kOyKDcfauUJnHwxzcnNMrat Z3FNCKdf4qEBe6N8SATdU4JVuE/U1P2gHombrRMfsqiMzK4ni6AXjeUVIviPbYghKCsnATzG qQDWQqy/WIBUg2CPfWE5h9BbdlhOjhqpwzrnBIxFnz4KL9lp4920XuqWXxeXBZr1itmLqaDf OIQ45iCM5wffd0Kb2wanqbjnFB1d3DNedV8XlkRH5/l7IOx4wFbRsknVTjMnRdogNImx5jcY fQZhMaHBPXpJIPY0bZgfXgbQT2qaNtS2CZWasAVrT9gqWjbhzknneLV1TC6S85yVdIphLant 1DRTkJ71dGDsCRqFS2Z3mje7rAUdOePzL6kLBXmk/PN1IbdtyNTcR3lzH/nn7p29R+WybJE9 VdyF9oCQQSBkI8QTjNQFHQMF3jr+d2Yee7VyvNKAHc2AO1inGOUU0XKds9FmAKVGhkoCjrcN Z50c1RgSAJA53kPxXx6Z+Dq4AC4qzlNxNi/iLSjLeWA3m+8NJ0m8WvuT6WrNI15l+/BgOVnM 83vw2mOJ4u0fprPBF7RsmYlBf9r6sdpuhG9L7QZkjt38JnmB1tlogwjnJNgjQkamIlWGy6A6 +EXjML5kZ34V9meT6TTu0+ohKOmxEIei618GF0JcQhsKmvxXyIVgTT4LnzCEcBr1PsVqzlJB +DD5dC6O77shAk2gZI4FZGT0oMDGH/hlEaK9G76eHJmtDoc90Sb8h6UcNjzwDH5TCkKZqw/P 5vPZYIpB6zFccRIv+pOAn6mU5aeY9fYPbHyqf38U7D88KYclUPIFEooUe+rXbQMGVhHHbxrq 4XwKqlH0cSE88PsRQGz/EEO6EfkgDX1NB0Iam/Q+hYPZ5yT6EpNhn8A6fCwG+tmJHxewrvGo UO2+DlthrUWadrUcgrKERCMXHxebpwJM1a+7p6ZKbU9b0cxsjKa4pMl+fBEthnNqiy3QeLs8 ePBA5ZUNzsafxhB+uoXNB10xv52dHbQBjWb9wfijkQvX2jwzZ/M4TwOI2cVY4lYIluJ6k4le GWeC0qho2drcqhC7PIEzUc77yAdFaEpoTDfO1e2WO59e88GASsbjrrUC4tvy3T7jxZ6dQVRC il3MPjKIOTYCVKQneUg4g1EWtKIdMtvygwG08ekcXgku8DkBnxas2N9bRO0vNRWR8tTomhSn YqYh2oKFokWgpkIeb5MvyJlsYZVzBe9k4CCWwfpJHIIHF2J9OW3a+8rHVG1DX9wd+ZlqDI+O pUGS8t3f4ZPtu8iui/V6Oew0Sq11/R8pmoPXEeyzZS5mooXW5TOl7fsULqYq51XRYLoGQ1UK eNc0kt+SP5OD1pGdn1q0vX02DcrQdtCBRElxnyPam94O6s15g3wtRWMco0JaP5K7EyZreVVr 4NNlvdqVCbGzXSBrLcuU0fVoNPgkEoHPazHTZdF8FYItYmRfNkYuDeG0IU2O594022OPg0CJ WYScq8tM5JodBEt2q5zXKxNB/oMexEaZTyj9Mrmn4ZuiduLzRZdmv8GpQwOKCqYGFbAfoOH8 R4ntX7omfmyrak3ut5e3WSvbR9e7aNZWk6m4pjR0bX17k20Naw7Tu+BEqg/SpMoRfgznkgZ4 7wBDJy8mMWI4VbtX8JiqXP+cHYJKz9rPp9UX4DYIDoD9xWiKz6/qnADOL9dxuVOVdH3UZrr2 vj1BU/RNJ9iZw0ry2bEhmljmQeuy4cmU/a0wtY04v8JmC6KIh7sfYC7LePVuMWsL/bkcfIUI PTML3aJMoYJ/+f774DmY7ziIMSMnZ/FHFY9KBjwV9ZtoGnJWlfzKf75ksytmCDb7WbbFl3Di Nfc1phkcqeBTKmTH67cYEQIDcvAusVzkAdckt7G9nHEM4ujMy4hpnaArvv/OhLGifyzDgeNk r9u0er0vLDGe8s8EmXcZeb97/q989HgEhVVPCHnK/LH0g2n4llIQQd6VgNYiob8aEakD0/EG oa8Z56aTHDnNfFr1d3ms5ygwxV9D6GRvfLiEwKkIqp5oDK2KIUyH13xN9Yu+XqnXK/Z6yfkO gm9a8l1R9N1YcxOsuQNW56F/0ib4q9C+kQfzrhLeEpltTQHwRu3EVQQ828xPqoSi2Vh0ACqh 2hjjTARN2q8D2lmkF3qw6dqUpyWXlKDoPC1ehXDvt+/uPvtqN1quzEqjo+b61QgssYjf9KXZ 1A0ooUz8boZRU0O5hGBU8F9DQLNGTdM0qptDE7vAb7WoWIdR8Zv+ZlGNI62YntnaLtn+PndP muAQ3UmlGke3hIo0ALK4mqk2bzS7QgAmrXlt7KxMITiNR5PZdZB8XsQxuLiipgyokCB8avUl qkHbnRU4zyfQFkM+X6Bs+TR9ghT+2tEaG4E7vIahAco6Kl/J5U6faMcKRVwMTH5kACdp4L1d G9oawL5R3yBUo19PR2brTwk4SQPDKnIaFtIZ75ttQOl0obXJiigKxuidkiOldMftQVuDvkxn k/mkNxlSjhWU8VD3SO1L9Z/OA6rBKaSv2YZhTPd6NBoBH4QQQ+JonMJ5gkplOk+iRHC24RAg LPWlMySptdfKTFQlKD3B+z0+MJ5q5eXsSmkzkTaHQuQVH21NrkumlraYOVt6y2dzs9FFksfR PFxoXQ6Wy5Z09yoeZnky5prXEIXjdTTrB2ZgzPQ+sV5ilu0TE9jdJ0Shw6GfeKWGJ3+nmO3n 7pQ/hKbXoCybeJyF8ehNlGCz3NHKcS2yfJqlH7PriiTlnJQTEb8RXulcGF63IssVGlgs+yfB iw2pWy5DDgdnS/+WWxNEdMkN8Gdltje1JljXCD9k60wk8qTGxG7Hm3IePehs+yJNCfIA6sj6 31wF9AL5TR+jrPOJbffDgqaMug58zBnIt0GzcxqetJv/wpDpdBSChRXDkRjYbjchibGgoE5V hn9wgcA6CTMMF+wr0b2MXPr2S6pAcyhfyCTWb9NTqEc7IG9QHAw0hBhAIeTXe6GkX6k2k1EJ k4H4JL78Fijg8LjGigXjPdNu82271q0ubTTdiPUqmq6Jf6Vq3aSE59tjYHbv05+tOnfZwnG9 41TN2KO5uJutjjhJXfxCaV+0+KnpgvWzKk6u5jV7UuV3KnofsJDYYdvT4B9B7SK4jgVJQ7jG djM4l+75ylP0B35b3OCETb+Bu34dY4eGzZMTGaoMu/EGm4ANyGElmPkSqyXmy4hnr1AZPEJz WHbw9CogbLLSWPi/MWW8flh5CF7Fc3pHl3yLRJMEA4lVK8eGdfdHwQHxnVqNCF+01WdwUhbf CoYiateIiYXTtqO1ZdDepbyUreguZypD1nQ71IkUDYfugjxLbYr4fXpKT5GPUOf1BCKrMr25 qicVJdez4jZh8B52FS6u66K2rslmqH5+msUU2ZRPMcOtLJsbkx1m2M4YDE4auhjOzvK4JBW3 FWdcHi0QDREH+HOtkjaUsbzpZDwMCoQrWLHgy4ZTgwqXsZv2SaAy6yLjCkoZ+lqPcKqWfm3h lD3dM/JRpbzeHZd6Q8hcwwVee9wzatwHdSd0M09uky/3MuKBJnMw1Kw2KkjvBSfO8jIHUb3x RInO1CuaLBj9Nbk/xUIpPTjgkSIHIB4dbrrabkqNdaLGahmkGyOdmCNtypEazqODMWjTVZQ6 KzfR/tbmyUBQdFAWlDaOh0FdQKNidDHdCSpSd1RlSnxgRThLGzyknJG7E4jFzK4PSXQh/hlA 5MyIU9gIeoLIU+egsewNF/24zx7WaF81SMhJGxQSBC+mxcpV0D/NFmPQfwZch48l823MdTqQ rMSZgIzNB+N3LYm5So5xNEMYYa0tIl1t47onZvaDO18CIZKylNw4WK5xWgChYbgZaZucedpI 1YPEL6wUFbMr/CKJdUBlSgiEMZWiMTziiCnQgw6no9agvLYYUSwiwSEZCspCNRK6vKC1WhBR jVF0NRgtRhAU52CfApByk4kgoOG1oXQy5qlmttYBixamCoFGBjSz5UfBUzMFGtkR9oD2onN4 vcLgQDBMNMOXg+xiRGiAgvKvA0yaNBnHCc0SLQfHYAYYYQjBATidRUMUBsXM2S5R60+NgOA0 1u/5eOEzibfzcupcbopvEowReLxDyziOQeF7GU2n8di2SOLHiMbEFg4vpXD4JRoMIXTEpjLY ce/HneZJ922pXTUvyXLb7OkXy3tZ9rXX/SbfisYSaTM3rTSooWPRszGdk8i3KUUH6+1IJM63 QJx/5ObkUI00LcQMzA0MUDIOXYwaILjtSbtatcnZ5cH5Hho++nVoE1AoTX8jeDAjurwTWbr0 AUZnFoXgwxxMB1+Mc0OgC6k2FBTtRrddxbQHRTHDU/+94ZtfbXxQENK7/r3hUU/l/L5m6+vs wUtFNYWsFacyhhxuwAWXLan5UW0HaAzZHHx8HsCDmAFsKrONMRcDiQFWUFtzMAUkNQ27yn4x sKZF+mZ7qxvwB4V0CHXaeErasKUjCJ2CO43Eob7Jo01LBGV3CMMdTe05ft7+4fIrP/jYE5QZ B7UNTsKx3NmcgczCZaMaB5+ZIOgvGwUU/bGQfgN3pwabG9/FLwUT4AnKN3FIPK88CUxy1zYm yiLCNYgQUP8pJlOpHp+9CtGofJ9UUoNkOoyulZkHtP6fYB1ykcH/PUFN9Ww0cfUhTCaIsCPw hPXMgAU1D2kH9JPnEMVhfzlZOw9+5T2dGfnY3OWFLLtxM7ayzQDs+MrLeYF3r/um9ofu+APf jr/T9kW8RUN4UbgO4iuBqeT33rOpLfurZYXzLdgOqVgYBRsBz4rBAbiLcEYtjO/VPJFp6mRu rQ2yRvIjxZdfmOuwhVOitb08Jpt9mI098THUlbY8lYMSJ20RP16MkKzp6fb2zMEwZls1Hri9 oe4/HLjNF/wRwRUlTO9GCdN1yWCaogEeytQg76UbUtdZh2imucQyTZOK+DSPZiBek9bsSs0h Iza6zRFT8dHd4twY6StRaS6N8iGTzVOzI/WbUdjXPmfyg/WvKEx6j4fMYW3egk+zzliP0nTL rHcgR0zzhbyC2uzcZOMbWZHhDV78Ms2Ll9pwMliaxZW63eppS7E4fSVR1BL8EOyq+lbJ9nYW t1vK7yyOJ/lvyq6Xv2uhSGJSxSekaCIwGrEe31xB2preJdwqtS2kkFHAnEKbPbqerqLNdqfc wNX5VbpASWM6HajVIYLnBZl/R7lNjSfA/KbRR3gNw2B6GzIOO5MX5LiI5lziyzfg78u6v28Q MRONgx1plHwS4hJ0i+AvTd71nWH/bk7p++CQZG/z4w+Y690jWQN6KDH4gM0yZYYqUe2j+Cwn sWlalibh7Jc5KZY5i6SdDtlIIl50c8DbkrlJDJA4DaaKUicrWROU0cp0gRf/7SujVGNJ4NA0 Z/sYULAd7PlztRoVzRA7lFtJL6VeL4l/mYeJUyPwMvngUsmu1FO+3Yfe5UiveICVKhVxie+E J832aYmjxwK6kt44ZHdfxDx3L9FpPaFze6V2tZTRHpZXmqclYBT+HjHsvIOSl742FQvZAIIN XgZGqgH6rlNR2EAyyj7+ZDiHKDfAzyoNILSA0uyWXAP+prJa+BAmOavqMM2UNL+SoVfFtZPS 1EOeRjBjH8dfdSq+c5UmAzRPMgkO3EWPF/MiVeD89XE0Gw7imQkPbysxnA/iEhtBSKTFUKW7 x32pejYqCQY/nU0+wqrgPYay/n2N6Omhv5gOBz3Is4TaW6NefCHWcI6+3sN4/u+gB5kZO+U2 JyWMgmH0cUfDPzaPhcxUYElvpvN/ZYDnJQHLqJLO02XsWTdbFxHI0pRdG7zDV4CyNpJtjaKk 6jTf5K0S8FZJ8c1bcM5GM6z+3Kor3wamTXUePJJGKxs3YNKPqdEu0EMEwrDyIppFuOvxRBSF eIs0n4hvKTfmC1tpkdHcl9lSomRvtxAJZfhbskIjBYab5s/knioorKpgZ/+rNXSAWBek1W6W gRNqUOZbGdzMcemWw5C8bqkQlyvDpUU4h5xvnMRAPm+rm3QM2wy8yKyIWTkRlRyTnRZx7Y58 Ti3GWqaoTXGoO2VmC9ZIzZbOdY3j1SnLfYa6NoFm74okf0vAg1GmQ61+n1NEKfVI+FVTJfaC aXXoe+bdw6RqAsWr8QOZ/8/Swfr3i5urygS2gW7MlCArj9rjRV8wlbYOndl5Rxif1J7cJWZF IwOpj/pG0ewTWQeJBV4po6wyVaHca7dca+tSzH9w7FAMcJr4bsGG74j3Gmw1kFFxb9/U5eye 7P4BhBexNPJSHF5QGorFaL9TLNWgS62y8V9tl91svVcW9fA5wPD6ET05dlEfZKazfrDlYPDb oFtqv6p2w5OzRrngHy9nn2+2jzbub9BWDzQGFReiC5YsFJdfiJOjSJBOxNpzreIaQ8kcxMav HBZ0xs/sQeoVSuDEiQqieIWhM6PrgKUQIZMgEvwIMrEsCmjgHXn2pZoMPA1IwzrzQsICnWiX cdEBq36By740IUodm/r63FX9fdNXynvOS7ZZDJxBFe5JhbwKf/IcMsgm1CkD6dO+rJHlOpMJ HSkvjodK1ue/C6oNlykte+Fdlzt5HlsttuTT8wpyVzZb6gFFvhVRBnszXfcGuQsJmXtXEPqh 2wJ46wRPA/KnFLK2btGqvC8NejK9x7WTh8kxdRbJTJ6Zfmxlwsh8b31pvrdaLPd+X0ZVQlnH CkGyY5NSvXRmYyrfWnQJuZqJM1Mvk581MZuPktJ7nDCKVKW+GWpna5SblhGA+UJHxp+meb5h OkXJPn/Ne+H7VkOqx5D3+/AsI9ukhbXCVskaaQFHIsRo1HySIjI/noltgNE9aq3gH9q8TaFj 94NsAv/cs//c/2C8i+jPBzbUof3nE7NSFjIUuDt7wuHn1R7UMl63U+9sTmpS23Qn/dJmk21h 0zbMUQlXyWRAvXj5It7Qk6HhF++hNbtZl/vbOzXL/Gu9m3aaJfjz6WpDNn/aWoNpqIjF5P33 ixGKdfN/xrZ0gSYgtTFpXEAGBNXHNwn6jeN4pdu4bOD0GiMWVTifqfjz7dsGObPB35tF0xXQ +MNOD+ItgOR4R56UNSopt+EcjxYgYZfiPjVC+Ot/2GAplUlnaf26Vd+vdpD1aLZMhqgX/4X0 4r8E39vPp+LTo0fEQWRlgaRN07zg/S8fWAMnIUzcbjoKVwlT5/Nls7BScD5rBM2GrKYYmCo6 OXGaJPlWCrh2Qyy20WD7PFZLTNswiM6I92IqS5BKVfxP7/moRgcKkGD7B9BaBKfR1F4tZ3dI riIry9cjwCrUh9+QxJ16vKE83wW2mPOkN2IK2OD9ck9mm5Wm/MvJ5R301ByVE1CK33LiMW9k aGGsMMQ8gq3MLoUQZLrdH5m5DvBOlszBOR7jriY6vgmHeePh9uN53JtvdeDO/nqSiF0m8DME ndTD+Wg6t4MmK6jg4eUkMR/6GUC2CqUoAD6Uvx1lhV5WpgLq1RGqJMQNhZzzS1GzR4q8jG+a vYHgtJRwbNdoG76D//rDKXmxy9ZtZRhHzGYfZzFNdE/vkfQqtipPY5Oz5dnvaXQlE1u/XGpX OvyihvylR5knuE+nZk/0HJOt7eCDzFtB5ki71Ig20N3i0cNswAyYF34ro42i0ziTCRRAQwUp 8Sok0HMttM6WwoqPwDfKJij7pBbI0XUyng/GHMMRoGlhvrcQomKc9d5jMWAkU/LIEDroVNAN OA9kklHwMu30XgRnlAFRXEtm8UeBBnFVhzDLwX8Kdoe8g4YqbkaOoaRBcubdV0heSTzXYygC NfqHX7DvqQ4zM8Z4yobajcXoXIwPnydm/UTevncU480aGw2NjGYwFAMPDgsT7PFiS8oB4kS6 6KGLOuVD4Mh1vG9RRydRtQVbwJ2eu5UL8rDZgi8vX5orQlE/1XhWnYXiElpkTTOQAvwqzmCD j8jVkd/E4gQrDt+VAVztiiEGyJpwUH4M4SVOCAB2bAoDhlZkoGL2MJ7hP+Rz/JjmMYr4dEv1 LNszYJ4YH8Hlir4Sw+K/eVlNfgi/z2LOYYzcHzexwFLB2ucKBqOFK5jg26DWbFc7zbN2uRrW moUsig5eBGUhl07m5KpAid2DVrnGoc/QeEM+ExrUjbS3GCvqg/lxkZ+QTFai7hA2N1IRZXUQ EgMjGIVEfWBxBzEQgYnT+GLwMfw6mfUZB2IKIJGdlsBV8VuDTfJ4ZPXB7LPguWMMWIVHt/hg iVLG5ge0HNeaoGuDy1wixHZwpBs8ngTf/KcQdERVwaooBJTNzWkzq9HTr7JrM5am2BUhovxl MJjMYnER2dJI+DZolV5Vw9NS58disLe7f6iSeBo51TlA1Sl4EvUFFexgMlZ23giSadQDdxXU kCZGylWYWxmxuJjRvUSuLbwOC87/VbR2fi1zLAWQlYirZgNKXyUFYfoOouI2mv8bkr/OVOKm QEw5URVL/D7dgWGnk79KJyTG2BZldCg4qHykHLuFwN2pdsWHrcDE6v8qtAZOBBFvN0iJnKY7 DWB70pgrap+Avq3IS86X8QcPHvzOG87ebbX2T3t4t0ACTlMoj5jzdGmqRfsu3qVbuAC4lZir SU6l2gqUUZv49CXSIR0wxLMYcj8YiJMMXiLEiBw9vKzBZijQqtW62OtyMVTCAXsuwT+CTins vBZtC4zv6kt3MTBwCqOmzrIllsAUWXi4cDPbUqP8pl/YSSGzyPOWQkzOymYsbcba2ovLZzQd PMCZSH9Bv5njIWiHF+5qa3LiZHhqZciuknvL5X7A3EYc5ko+CTkddCJjVTzQ6zSYY7CKbKmL 92+g2mXNCemsQB5QgiJtmrSsiJ5yQC0KIdZ65ywCbWVppQUJ6Magwxohn9XBE9bZhXYUmEyf IZyUxqU0ywFeHw3mOG/gsuhTDi7cYLm1mGK4EPhO+gm4FAELZWZNcNOhuDLuBCZDnQgRkq5U Wj5CQ/eHr/91hLet8Dy+gDQlXFiUVzBS5Dvu8C/lczpaobByCTRA0uDsWimJDAhpmXARnc/E Td0DIcQTUJ2R8YYCKBwVlLnsRm+6EGQ3jK62pIVtNJsNxKI6mQoMXciGIeDq7Ch6XexLLUjk xhcjwh++RA74GfJTHCSLWayzmZTKZZkNvdWuo4tnjA6n5AQq1xMfZUr1Vsnw+hz1xYSut/Z2 0YJM9HT2cXj9IKjH1PKrSR+NuD5ChsOR1BEYExBU+wXctGyVgTxevFI+KyJMRcP5YJLgQ7BK LwLbRipGEhS8uOQck9vIonERrzeiS8Ew5oKwxXk+mF9zHIvp+w8p9y0JgmqFKWnqnx7yX6io P9jnv1BPj9XAKHlPaiSp5AcSlPjQ4Yb2n5BULpt6eiD/1G09xhYEOKiFBFghy1nZRBA69bKg SfqY8kjsxofwb5HMK7Ye9idwCprFBSPpeTr/xDpB+lnk9cbpPym3zByu/Exfe6NDzplJ6V8G MDaMJCiWUHDM/urx/TNVTXaTfLFaqnfKuVt6rpZeDZV5yctLG+PmBHMyf5nru7l2miyaPe2Z CR6z8B8dl8nGjrixwqM3h56O+3aAOYIVMFZQtU4NdNChWIizqriUvmILUD17cAjZuehNQ44I I2giLDe69fAnJBGqnxEeDcIigZPUrVtXDWR0EDTblWpbUPGte+AGlsVnwxdpecZtBx4tgUv7 HwqCk2w9Eczg9b+02cttB7axSo+OmkJZ0hpmIHdd1xsVdFg2unKLZw2xPK9oRnzaeOrqB1MU KLMg9pdC7C2FQMbOmY0tVA4XY96p0jHQN8n+eZG5Uw95tfwdnTMKGR1jxmhyyYGeh9yzvJyA NQfX1hHeIowv0SfWueNEmJjGVrCXxM5jhs8SZtguyRLWSidnu37fqJydlPdMNv/eCZn4Abl9 DQwbzzrVow05pVNpbRXJvG4q8zIHuhCHyaQ3IPN+NP2PtwqBtMcnyUfI8iyUgljP3gRmFAxD ErKXQRpl+4YLi8Es2uSZUA0cQg2POIyOFj594XzY20192X+Rn/xDB1s7chSQ7n4iglG7CuuI 4zmjQn4Kw/zhQES4NUcDVZYMhs0sUhG1EAhQzFTFf+qwWnajOrYWQfaFLL9BTX/Ge34yGX6J 2RYOzY1cRmmkSHSMHEioOY/6TsRcSK4iZrd7dVI90sozmV0Qw3ODMDzeRldI8FIp1cNWSRE2 UOcmEPKmvFUp9xIg+PMYHVXEHqenIHKXkJkKdB5ErttfoAIhCrp8/YJ7QATDpm53IAx9FLS6 raBnKuiK8kZHjWqpEVPYwy0kifFFAMJizlHHho6I4ItIOw+33gX1kuzQ5SWaigujuJmLq0vv UwIWaWIjT2afErAUBNeeB8alMdduYMOTMTCdtkOlrUgRRpoynLwVtLArpT+TW+FYCCD8tn50 G87pGlGCreg3V+jdqQ0opWgGABbD3TXjCecZEGhTKvZvTsTAFPEXg89KBNEDMiELrBpRIUXW nacdguQmd+FW3PpLl5MtL4qcDCZjJc0ryvffB3tPacAc0QgZ2GmjYoU1Wj/jKnCE2kWgLFKK sH/GcKBRHCjTXJqPJoTPtt/nFpB98KW4J0Pz8RkoZAXQvYFtw2QWzQYQ9akzgU6HfMvnwxB1 CIJXbAtmYRyMTjbS1FUl9+IanYs7hntjtayr/oDLXHD/t7k/4ua80pXYl0IVbSMQ8zo4u87M Z19E03dRrKjyT69+C13vZL3juYpnCgdDAy5JAe44DBp/j4Zfo+sEdgIr09W7Eo5QbDcaYzCQ Pqq/LFBtBoLZzg4/C61/hOMd/B4O8NR5bZyQmj+fjXk+/UCdHdJY/691KN7ykLvlLeSkVKvT NVIFwl6d9QpI4p63Yb1UE+Kn3pH16ssdJrtGuzmpzC3rikjgqMrR1zqvXZIKiGx4+sM2zLj6 DNC6Bhk2SwU5gMYrhORYA9+jhBRTBsEPvoCYbD0sZ9dTG/w8DhSdizkjMjbvlUDu/TKXcaki 9Pz2Mp18AHDjsG3609rEWF9yXBkMIFvkgzcUu1H5tqGj/V5CDGTF5CC933G3I58U5rwn4Lkf cCvZk2DAyOm+0i6Ig+NSCC8Rg8QIW8LUCu0J4gw2AsnAwE/2fJ6YwQjMqVkRielc6AjUng/m ZOdHZ6NKgACbeywDwwXSeCXh/sUGlZGQzbd+JlNaj2/tHQLl3KF2vNESKUjD76HeB/0sL8G/ FQe6OKPfyE3zcMtbL/hW3o4RvNZ4I98F1URCLBF8Ed8DTfQYWR4c8cw4vdfcF7wtOmdlcEr1 GM07tOj3ljKEFjvwMa/Vl8lQNCgOP34ZGC6SS5xn0VzgJUujT5ISjMkMdU1WFApTAnj1ZQQq ohgrqrVEjHWI/qdf4n/YWrOM9cbsmzxua4cbsXlrF3YvFhOHDVQbn4PBQjGQroQngCdSX4nO girQBAUFYpOW/0oo+6Bt17Au7dFyyBd07YplUN6GXrLsnD8EAwozlfdHhXzaMhoAz7XnuzJX BEa85PfwW/eyxq5VI9JLmRoOjWadRm898pU3vmFLiuK/ES7pIQfKNwxfZoKatpszCJHcjsX1 Nh6dD6+LlN0S7arw/ZaY+QtFb4MZ+IBhiOzg3/FsAqI1VOHcnxwQif0Dq5Vjlk4V5fE4IEzT IgEFwpeBuAhKD0Yf+oJHwbOCjJXoximCkMLoiTGQJphGUGGZHIAEFv5L+sIajzUkd6jGJKk9 1GNVv0q3bR20SD+PsIwCQYnRwBFNi4iUwIpjhvgcu+xSOjw5lhkG3wo0AfQ3rUV3PAftcP26 LZM1CPzFRtMwUGzc27BOBLDhcdz3MYUVmb/D7VOpx3JcfDhyCBDgcOt1U+yHcrPRbTfrdAeR 2+liBEaa89lkqHcSPh+krCSYpwYntZMm0LsQyufXpjzQn0jnz9tlNhN7kKwp9nfZmvZGMphU irJ2tVyFvEAwmBCCmrxjTz05geanneCV2HUQ3Bwtb3AV5I+pLGUUac4lrsoTnRlmKd/h+tWf a91wPTzb4TEzlbaE1blYEUVEfDNSVk7/v1+xuy4CPBUgr6V5S9Ms634IqYVPwZgWVgFsX9OG q+wNChxAZ8cwOETNZUvFtA0csC/B7MkVb2dHG2fzHElLVa/9q7qUQm5W8GZ29EU5OYpZKXD/ EV88ERi4LzOmtxkpQnnSrRSfw86vTVECnBTXehiZkVqUcQDd2KS2h4NA9hazmRAYhtdGamyG ByXyXKuFI1mT07vUJ71oKP6dTIPJTFeZwONQOx5N5jEVisUdx705RoqeTRYfL0U53ZnNjsZB PIBHIVSiFUHV8RUk6E/jyVe8KcY6/zAMQtcko7XmeLsOKpPoYyQmALo3j6ZEV5I6E6V/G2Bm B7iBzmcDUojYMdz48GYUfNN3son741Rs5GQR1wEIFGRqpU0TCyuWqR0nSNLUr0bYPZDfMHSe 4GjJZIwY7Q9o2DADjJU3nYwTqeBkzIAh4A7Y8f07AG4A13pE6Y4vrp0nwTrUH+hA8tjczo4d wG06GxroEBAmNrIiXXH9GwsxKYzdrBXfI8vN23y78jGWlCWdl62M2R1crIZSF0L+LTCn3GOB mOTpeTwbDcaRuGYjcrXbYqLSXiSsoJfpXak8tsp3oZDl+Vn8mUvIEQE/FtL2ILGOKoJCbILy LONFWVVioBp0dn2YDMUwxL/7GswY70c2i7l9mjg+kQbjc8Q/3WZ2UN0Qin2MudZBDoAMOvI2 Wmsc09XnjeB3R9mtYF3L8zMDkGYzi3tf+jTkZKUK8dUUOd1qdTA18YVOIqmODFqlRRILfKpd bSDYLJdG+0NwlaBV2fItW9bSb2QGdxVtW5FdN9IkCRnvh3vi7KFb3WPSaByfnZxU2xin1oya bEJ+k4JU8U9Tvah4QzBJ9ceNE1TIQZM9SK8ZVPZw9Rq4VbLHnTlsDB0pWnxA6yUV9NLKAzJH gT0DMEsMhYk5FmbxaJCwRMtC7Si6wlMRjmN52yZGzuu8/THCA5R3PftUQbtPD2QWHFlxckFG xWCLzNF2wGF0B/RYwPKDEN5twFRqIWTnwWT8j1T4qTSifwie7O0rcpGpeJRjasdIxgOJI/DN EZ1JU01Jbs9tVAYJvsR1eKKvcKIPHjxwM5TsmZ4mGxrPHVBgYmwxzkwnuppjk45tGB3/Xwjz ElmYSkjcS3AVyJtN6a7bcM3Srw7kyOAJ1qXSRnWMTKjuuDX/NfQcYqiQqYltGOBPndtqQ38E GL50uKCiPdGrINrOuxxuBOAy/Krkq6B7gYPwfJFs8WAKhWWcyhd8hJjMch5D74wwDI7VLTja 9g88LBWWmRvHshVZz/4qrMd0wNhI+/ViMTnzalHroUKMF2tyKgUrfu5MRp7NGrQkBT2YG2fy u5op7i9lihkM3ti7EOjb5vZLJqbli4IhvyqZwzO3x4cSzp2cOWxPt7tXe+Rj0rXFJPaalfea pDeDBEDBNEJVOBq1CqH/cjLs8zs5pLQR1ElXYrEl7G3q3xXUaAiNym0pN1bOZlKCwGyyRAjQ Sc3iq9VAlezDsCmLR1SNuvanRQrs4Taqnu+VCEWBHzMz8LrZezkp6WKeIa718UGGFrJ51tVy WvBbMB5YFyB/U+C4TkZW2rA52YKqkAzle4jUn1fdsCdNIF1qSLlVDkT38Fe1Gpbb1Uqty383 mqG40eg/4Bqd2/58Mo+GkAE0ZP4C8SbfYDpgmYI6oyZ4pumRKdTUa40f83uE91aK1xkayHUW PLcJlZvYTEecVwHMLGZfyAPoajcPkvMvKmTQ9PyZrHn/EsdhZY2TVn3DykEMwcz95kwb8iEj 27hKm1bBB7POqqZVfLVeOc/7Dmsc1I05W7D8IWCKVqE4l2WCz8kFb8XfYmscudfys8I7RJRO Du+KMyvke0+JOX9YpvSNZVSaJ+/cYnTqJFwhPav0T/7rX/jiP+TCF9/twhf/SRe+eNULn3Hl w6x5m6n6mwHqwQcfF5NFEsJjY6Ke8ekiKO4wkDR1h8MlKyOVC3h0dYQZ7wobvVlLDUzwFwMX GUlXH6WbKQQ/vFTvokYEfU/GViWy6gfYFdLFik4HvpSxHvl8YATa2chOKuuyMIdXucxqY2AM /cbaurScHyfzIB5DVDQYHq5b+v7n3eF+3hQvuYitkthecSJiE7dhEMv5Q8ZFz7ifrcIpVrpl 0VFHK6XNUbEDRhUG00rtVXWfSh052bjTZwxYAygBWXRuXOLw4XH2iZLWw4t+BAbD/IIPYW/s 5C8rZkYmKtcXdUVjpDzm0NgjcZoYL55St4w0yAIHGlSoHMiJ5h+aw6BF6ZzjAxgPAEl0wcZA G4bZ3ZINtWEuRd7F9ka/Rf1zkcyl1XQwmP8bnw+iYATS1XSIOX/0g43bHimt0s80K5w7a1PV kvZ+Nxq7G+HkrNZN5vEq79IY8oETkCfiKjuIhjvwGAhHF9nzbEI2HCHjbqrnI7JdFtLvjiP1 PlwFJaCB+IDxUcCcZs0av6F5VQL4E/fXSiri/BLN1O/PhmWva8olq/BGPxFrVUw+Y7xnml2d Ld6JuG/DFG/LEy2WaHPEnC2WrwpL7bmVeeEyVrjCVTOPJS4nJt5ixWDlxn8nUrsTAWWvnO/F XVO1wRkjgw+KHjfTZ9EfwfdIvWLzvbSUejIYR8PhtdoVYBggyBwciCaCY4/7D2yJdU2VosM6 1XpppVaGUvEGNUB56de9fpRZcdc3PH6edMAZVw6zkHJkQQgQ2UFH5Q9OgaYGCMeJHQIha2BS icW2UgistW+yOpuSq1w42nlnkDD/JEtyJ0hDNA7ECoBXGcZqsOIUKMtztk9bLbTCA46tUHpT qtVLx3XJIXg1rJgPTnhBVQa4NefrxPlvTIgV4wSTIAIjU3iR25QZF4QgIRUoyIw6zZPu21K7 GoIOrGu7Be/58mLgctEroIeili/ahjMhm5KcmW6Zrga4OQvaus6AzCQi9TiYSUMy0DJ5bhJi mTLT7xIuHXVIlluTivB10yIlqMRukhigNaJVhNdHdqKEZ1T09Q0iqjHiEMXiDDvYt6gzCYRQ dW24DFtEuuxV8wE9axo6AV7ajsvV9e6XtU3ihL8ziNN8sv7DKVRNYwm7k3NyOZ05V2JyHTwm uu1a1WRzGs7vij2LwWRJmW47fteWWeUfGTIrP4LiQEjKEKzWjnnqdTsX4p+YDIk6cmzQ7ZIJ 43phLUEh75/vUsIlDpgtPhWDzRp45k4vQaaDVp20XhDhFndDqR9NIbj4IoGNR0E7MWakmpg5 btG0HPl/9uMLMHqEfBP1amNj4zns+//EKOBiYOTGBs5b0C4GE1aplLKTD2BCgfCi994MwP7h yGFZg8mR/TdGKTY+nEf9IxjN7tU5Pp3Cv4KBBRPIWBXg5gkiwZ9gMGYORzOGeEzhciyAEONz BnqhBvMt2DW8JXAs2p6qPxtA/sg55x/YGU36iyG+9byudcLTZuWMolBZ3SJlbn3r1FXO526b 7IOMO8oZvjSmDizHCyeg6AuiAlnLDCVqRtxNN628L9xooTkTIKGQbJopt4Cd5MRPDuBQCsH2 BVmIv7ZkzG+B63g2M+LqPoC4/tlhUzHBMDaRDpXKJD94tFfwxiRVaSwoSP3gA0dIJDKYzibn cTjtDbZgBJTdZDZDe35GiZgRDF0Vw3AB5HuV5YgYigv3O8wjlEkdKCixGIsO8UmuRirzFO/5 7SrkHHtzlJdFBI+OMIyvjN0Bf2TtjtsQAQJjRAYcN3b5kBfFyjOywZAfd/rick1b1nAs8Pt0 QBWOnjLOXLdUvFtdCzenHEXBCIKLf9OwfEtsZ/VwVyO174yQQivuu4BXirgP8SyTgcEwuAxX zFw+MrdCTLtTz5ILcJWLvxjhIp2adpYkuuGNLpLzz3RIKkRhqvAtGcU83x/PqA9BIZ4UDH/b rU3Kj46rsU+9uw9UnZPOMZpMvOq+1t56rgKM5BiWYYznHnsuyUUi36feDx5adYRo/suHghXM evVqWVPa8yF00vOhc8uMCe8AptsYjFZsQwGuvrCeVgzQdDvJ6u0kee2gNiOHzNKQkpqc8aDa aaWGFKi/JeeZfqUp+up4xrjyXJPcuSpNxEpjs6E9RKtHsknJx+zegIshVYJkTNcj6NLdLh6w I39bl9PVGnPgMloDWhfnfX9JYzZY1tY9MHKIcVJ4ywOMTsRb5MFU2Qjsz15YIx8aTUUnsZQn kTFAN8lZdrZAX4pAGlROGkHvYApO4kTfgeJqNXKD7medXTKmVE5d7GxwseXLhcFykyE2nVZP kcT/YxuzDbDP4QBSe4SXX03Pw42XQa38utYKX7+VrqziJv8KDK8E+0/3dpTRpPYVDYwWO91S 96xzqwbRYHgUJZ/cNkuVShvThKzSrHS3lMcNN9Ys/xQelzqgtHhV6wjk66QkKzU1jMdGS3R+ 37YttV2NFlttcUkri6Zu2aZiJ0abYnU7Z6e3a1OetHItTm+PPmhKow9auj36oC13qtDiXafq Lgm0eZcl0SIGN3iKct9tUUjNaSSeGlLk7dvDSZsN3n3GuDZmk3dZGGgSEnNb877DrBN3UTp3 WpTEWZTOHRclcRelc+dFSdxF6dx5UZLUonTutihSaJWt4bvqbZcEGjNGhobmtx+auPa6c4Wn j9u3iNa8nDSNGpQWvWJJTmqv7tKmPN/tRuXxfqtWrSNeNqpP+Fu1aUd3MNo9qZ91XtMz6i3a pugKGq8np6/ad0CqHazBaO+2+BQNWtjE9m6PStHcfPLFbKtbu+WGFk19/SpueAOztbdvG+Hr 2h2aG06+uu3Vm7dsb3YVRkNxkTMbbJffVEJI1rNqm/+xLSPBLZO5jacszsUDvu3/sR085FgQ X6IZvpAlL/Aj+kOKa8s2P/e9CDY/9nrBduXHartRrQfbb6PhMNhuPg22LyajwXwb3Xy2uc9g u/Z4kcweJ7Pe4+FgvLh6PI7nj+e9abDdC5QydpN64hxw20ybL4I5ff8UT+fb4/jrNgMkL4In WFIVw4FfHv/H9vZ2gO1v7+883dnb2571DrZHo73ti8Vw+Jh0eQn2fdF7rLR2053Ljf3d3Sfb u/vbu4fB/u6L/b0XT/Z2duVP8Gh3b3f3Px49ehQ87sdfHo9Fa1DjcFt0sf8k2D14sff0xf6T VI3//u9ge6+4fyj+LO4G//3fmBN73I8vglrrNXYOwr9+/LG/6u/1ejnsNEqtEF+Gdq+ecxbn JrqPJdoRrtRuURRrxIasLr6GzVa5WamGuxtbu1dPBf2YTRa8oHsA+iwNar8oorY+K5W1/YyE WnbSmK4EL7uYTOPxejV6w0kSr1cFLGfE9ut90vFnxCUNTsbgYfLpvBgsbe0eUn9nzAaj9ECw 3Yx6lOoKHI7sNzbUNAvGAuD21HyhdR6iGEApRDGFdnQ9nET9EAyAjJGZjQrhNa9hDx6dKc6v xPbLRbudmHsIQUo9+oZUq9FMNUuTozzAK7emM73fhqWMJ1/EJtzpMZPY3xYsYH//xcHhi8Pv 7o+tPHuu+crjh/fyEyBDBVMRGZG68aZdOpVhgtxHcHj2th/Cy9EME6qIVkriQAAeHo+RQ5Et 5gWovl6ArcpsHifXZovlyQwiJMOT6Q420CFjZTDuHH/CvHc/CpofBz8tBhC19NNn+O9/D7D2 jjiXsNa9/Dw2me/JSXhaelUrB/yze3X49PCpLq8cp8oPD/eN8rqnvE8bVcKUTyvAXSVI8B0x eP0DU6NjEH46GI4lTjAoHDVBBgKkwkYsJzt2na4V61FWAptZ6V2NEgGEfBKNTsDSVlYFWWCy SIIJho9IZOQFq7OgNRuMMLw1tCc2h64OA+vH54uPH0XPalQOtqURBhpwOInoaTuFHEH5/SG8 t/4q2hA/cnGK9KdcC/ln3fpzN7g5skSdKEC1KScFUpZMaE3MwdrBHEBGXms0YTOwqGGYbLTD 6s/daqMCawv70yyh3DtYcmiXYB4cKnlul1Tb4mpIJb1ds6fq20qHqpi9vG2X6tyQ8bWqvu6b X98Sle1eHewaiKgYNIRBSyCBM2/6jFkf17pbVwVFscHWHjhwi08FCzdvKrXwWEMd7NllgfED LRJ8wQJqukDfWeXlqlt+sGsBdH50AfbtFgSRNM4IWxLgeSF/B9bGveGiHzs7LYOD/Bh35kI8 rl7FvQXsoBalTZ3MGIG/qhCZcHr1i8H06H8wrB+ux1b/5e5R0P/+SvwDzgL4bQrfpt/vwb/i I8FDDfFzI2nc/6MmgvkTeIhM9zEECF3EKs0rR5Tj5EDKAgPLp4t5gu3MKSi42JqSMzjgafRk Mtvyyauw1KhsUXLkwELM/CigaYo5zq34jmO+RzGjsN8CCkcC3qj47csAmz8Klv6oWhz2cM4Z nVfrTi7FWgsxmf1l1qHZ/j2X4be/3DJ0YjSCdcJtEvsrWvEHyfq2N+rrMxaj/gaCF0F550cM lY/56WJxgJWrJNGUId46RmdyzhzwvkrAZlevnFhweAnEmM0YTKrzI7aBRkH4QXTGocmxl7i/ xvqiWBcKsWML8nyIJaYg0hLV6F0FmXJHffVNbs3/3QKe+xvw1ULBKhUEA0X6IxmGAKsafM8i jnQ71YsayMHUf2yedbe2esG38jCRYtE22GAXgn8Ee5BWXXI7rNsTgJD/K7hZcZVpoTB9RrVI QukIPHbOWRCiB2VcI2O5ZTio9VFcb4d0Qin8IY5WHCvQC+aTAbvbc4p6Jf4DKeCBWiwa3SEh j4t5Uizn7IGx5m4x4PMdG4YGxN2arRQhzM6Yhn4LQqK1o67F6qoFMiZdqRUMzsH0oqqI5eaz 3wDKPjifGESgSE8Q5K0qwwCD/3Xr39xhiYBqWMWmcd+PZQpOlqyQxzPrBj+3yMyaAXH9bfFr 3RWpNYh/88+vkhsGd8GZUZ/X9ZYtAI2KIyDv9DAiNQueAJKg4gFHgdnWTb6wdiITMInBzCcQ MyXJv4WY2pfxLMyKSczhRWeudsSo2p9YCi+/zsKt1ANvj2QxyqiVR5fr/NhIIrXvTDAFQUQv As8kNGxrIa7qCUDRj1Y3810twBBDM12jEie92QDvjy/sftP9oERBUhC3pvSbMovSNYYCg600 HUa9eEc3Vwok9lRyGt5t4qobKYHqNPooEF+eTD4N+BaM1eK+0VTtQoBf80k9QqDzqF80diUJ AnLufR30UTfCl1ba63Rhj8ROn2Ewx5HYGdFHzJ3ZHyRiKtdxfyd/q6+txlifMNF4h5aVEkvA 786VvHeJKCbzYwlL3gFkri8v/vL4l6ptQhx5zuoIFHL/Aw8le2pn++F2Q8sl7vnRy8CpxAO5 kb2DuRkBY5IHGtzekVlsteAZoRA8DtGgWqoZClZDazRzgM1I9YTZTEraNSzlljS6T43WfWPT oxPfGMkrL4esCsa8Wxl4kbmj0ku3e3Uhfo64nZtAe0ukYR3VzkC0nNnhB9WkNOn2sExikQx1 8ycwSwxonsUoZ5jJAfLmfhxirFjQtBlH/DJmifWBwew9pSsDCg4jSJuwmAJjgRbhSJL3C9ZE B4GtCJTVBRSKLcp/ngaIv4D0AvJwwhdLlGaUyHL/HGrdQ9fLpuiCqn8nKUOzJCX3sM6noEpQ EwY/DzWWMRgTynRKQEN5z2T1F0LaAV4e9z/GjHXVkHIylzcJRDY2IWEey/71jUzqBh8p4SI1 wsbkqx4lJmTj9YZVpRMKLD9x6AgnTpjKHmcrrOwXVUMwqGQSQMpmZzwacy4r33tqsApT2iQT V6hIdzL+Q9z053pPmhc+uBqllwYuCvoTS5mp9SKCJBWC8Yj9B+92yXeyt7yo2luA74gUZpR8 Aq5hBkNcZf/rxiLdjlTacvss7gxGIFlQQoTEaEHliBiku//9xY480XZtuSNNmhlnB8ScZTeU PPGB20sdUttUicjsNu+BYGRFRgb2a+CT5/f2Gniwl21kgAZdHjMD+T1dUi41wp/OqmfVjYP9 jHon5eDXgCNNwT//wxxE/Oyga2r65+UyN1rThXazSAo81Wg/noNGLN2oxDIBFL36Q9UKe0Bn t8IAxdxWkGaDnLEAQDFDl6laMdNoe1sxAYquRnTnfDCB53ex5zc2dB34ih+LOT33ojE17o4/ RQB5rYDyDCK5prAg6HGpRle1knyk+O0YxN5sZf/Jk+LKrfRG/XAKwWoXY3ssz4vB6mOBoH69 4QKU5XCm61YqtQ7EzhBn1hnYYdUar4rZrcSXlIJTJsdNrSuWFpeMRbTCdiQUnkA2JnMXrzgl 0cw5KlHMNoJbtIKeOE4zq7WSCkNAO3VLeeOHXfavDB7OR1MUI0xwcxtspfK14BGz9RCu+oXA LC647SyJfnC0Str6o/WDDDjtqg1qwVcGySdxRvfFf5RNyjmmbZWGPuMii8jvP5AUdDsbFTAZ TJ9FB/dp8Hb47Mm9W6Z4n6k576lrg0KvQEN+H7MNV7CdrUEBHHKCbqtGxir3ZzTCR28IFr/m mas+6E+n78JW6VWVhBT6Odz9zrAsaVdb9Vq51DUeuHevTk6MFko/h+BN3tEAe/vPjDf6drNU KZc6XbsB+PEAoQ+SBeSCOunIEHbfLS51u5Aaj4v33OJGs2uAGKYJ4IntMg+jNkZIcIot4whp Y12vnda6ara7e9WTNAyb0QbSQGLXMahkdaOgkwAJxbSmzHQsAyMI0eHzXSFx2h0VPLUdJzJV +3Cl2ml3Maz9nbdvnJqk+dfRrP8VbvgyiWBbPiZLmyDPZMttCoRjkNHung+qUjXhBJQPqNrA s7TW6JbYmAV+DqpBPvAxAx9UAdwHW3sL4eAxPSPCUiLGLAR0KK3jKvPvtGEAYb3ULb+WM9vP arfEkSZPI8HSV2m9dNoOj991BSd4W2rR0nbb3MvzJdCNpqogoA95TKye9vbpuSE9PZRXZ7UD JIuVtgPSKgrepSHXnHofR4b6k7IWkix5qyRNGvryTVsWnUbjhbi17yiTIuh2Mac8nzL/zk8o nW41yz8pQDmDLDfHDaSkILAh/Y4sCHtoQ2Y5ISHsc7fdLP8ihC4HPC+ZvvSUNf08rdppelpZ 7ocbyFNsuOxJPT+0IfOG+fy5DZuHgOdlnhFmTLiwEyYcU3RMnhw6xRWc2WX7BkLr5V0XMnuG 5UMXNm/c5ecudB5GymVzmbM98QC2IhlLh7S5J3k46fhw0snDiWVI2MnHyZ5Jyp1lONkzmUpn GU72di2cdPJwsrencAI3eZXXGjgt7H/I0oXp5lOYyHKI23DsJnO83RDUxEO2GxuCSieKoE7h oFmDKo1df0oCZ5BWFJGNjec+PrOxsWWKdY8P9gu+nZsLZm4Aq5tOZoHGysaG2bCi0H/H7vw4 OorLhVBMPREngyWXCjFv99DeSVbYWvnj1LbJxldhy+3vkS//h0so6Yae7O07c+DqJtDTQ3cx DUiWobeshSk8dtuyrVvteKN6VtmLC3H7LAx48ZuK8Scb3jrYf2gPUDZYSB3hfEBPMJOgPHzV eU4P3TnH9IiOaQ995PhyGgLinnkULfPWNKs9T1fLcCK0qpXT1XLcLWW17yTHyrpbltGGcsFW UhJ97rZBZkOiqn1DuTqUN2R629VG2zUQ4brtqhTCZAUhtEKwPVSHvYSXuoePjbdhfTcsVTzV 0bDbrP/0UNXXlVsl0fu7sPrGcDngq5Cnq2YTnBpLnU719Lj+LmRVGM1tOfJkonI/2qwwmxs6 dbrNW2XpoWne3m7CcVUXA6uKov0lI2FhP2sg6czuikLMsXROBa9q/stBG0B5BsxUayB31yEY iHf6r6oFJ5Hq28kkYQjxWUiSM2cnG3PJcwsWIzVlrVyPX4A9dGAzNiKAPndA/c66AFl2IDMc cQVoddcD6vGxBVB3qNneswD9PINebByvtvmPj2XiOc8PSnKWU0ir2e5maUtpBwSm0qTZwsxl 4UnpuF0r422v2ulo7hJ4oVvt6ptaUyyVhkdFhx8a9qHVMo0kCFbFUu4uf90UDJipzDPj3X2L 3VR/FgPKqiKgDyzedHJSrzWqWcjcfWLqFDD/W91z+BLsUwO2LPiKkD1Ostp9thJiljAdxP9Z K4MIbKrptkuNziksLPNu4H/WAWNKDw0A69bKtVapW2u8MjhQir2edVHUeNcop5bFha03Ox0E rr1qlOoW7F56DAK0DpwCGWvFgBWXabddgQfgLFVkGmJIBuyhA1trnaQalbD7NuxxiRiAZ/12 d/fcdhs/ii1Wq5+1qylYBDYotF7qCOSKITfF0SVXQmmyDlPtetcYYfdTsJXm24Yf1roRltrH NUETxupasLt7Nmz4ttnIGsOueS41W9VGBs2Tls6BtRbBgTUvbt2fw3K9kw37xIBtL4F96u4L cRvIgn2262EADtIk7HOXJoEeMtqtmHioV0IfU5ewJwYswDGtl8qQDNKB3T3xwlp8TsH6262f 7KXHsPtdBuy+B7bE3K1MXg9w9kkFVhesp0npt2VcHFo7e8+eyStm/g0CMkk0zxoV+Y5QazbS WMsFD2vu+WrzMyFLtNo1f/vQ+t4ScKN9aN1UdDdoLHD/9TUP4PtpcJCg/eBiQ6XBOzmtH6bB y3s22zTBn6TBzxo/NgSP4Uu3PdWnafDjs06tWiFod5mepi74oZDmG1li0LOUAiEX3NFOLgM3 CJymBkJgDWIQts9a3RR4KXWXMoX1FPixZ5lAhMcHB3uxUGeWAS4gT0uNitt6xT60+HLgYFyD V63WCZwlc5duAPxEXifGSguEGWMSlV+pB+8W0Tl4BH0FE8GvsfRECaIxbnZTQe/yhK1m+dSj pT+VZBmKm1rqLEat9rL742tyMaf38MUs9twfawdpDJlMX4A0PCDH5nkuQDx4fsKDEzekbt2+ YTkJieVjpBZhwR1c7Bo60Uv8zpWWvqAhE0Zf4XddUaYjBA4H1CcnIogrOO9elVOAdgpl+7Ji wp01NKRqV83F157Ru5qKvz3Vs5JijbAJsLEq1U65XWt1WcCCRckfH++u3aunu+rtT21zsYxh VcikZ7CeptIjNRkF2nFBD7ygtDyl465x23++lwdaLpvi/mEOaPufpnrs+ZNd81ET8lzb+jlI fH2ckp58IgOCVn2ge15QyBhfbQPVd3IuFAgqQwbZd7GMVlvpATy3JnmS2oDVn8uvS41XqDdq NcVWa1sbwtQXc/JvF/DQ3YlWFnJzxd0NVvLBqZ3j6VrnHffqA3xZwWkuxnzh/Ej1Kefrs4LQ 2nOKu2BIJY23binZWjz1smLF+KVVsvh+jE6PW83KcZrtV46F8F4SF8WDwOE/NlCDRCJHVZqC qTW6toLShalWHeXL7tVJxqlSvZrH437sm0rVMxVOhWwTp0cD/7wQ2JWqjYrvQm8DYYJhx5jF LIcUd64tjBTK8YW8POk7T/vAsODK/c9u/m4GOJMBZd33Aa4FVjuOAsYHd5KGO/TBCbCmq6Px wXVb7XrTXnlve6VKrVO2j23/PNJwu164dr0WuBRHCvwUoDORfS+ixQHmIPqpd4DtTrnhwHnb O4EQbe3qT8ZE/Ig57v7sKrj8CHxTduAqPrhq+XXTo9dMw3W6bnvlDLiOA3fsxUu5k1K+eeGq ncxTxIKrp+BOvHDtn1y5O2PdUu1954XrvnHhqv72ai5cybtBqp2uMz4vvbRTir0n3g3cflN2 1uNwz78x6w7cvre9V6Wac8052PXTc9mZx0EG3btqgqf+9ip2g6I977o10v1659FIt+fdbz9N Om3/y587vhQj2kvLqtizw32B9aJBprIuYmY/i6NEXJZ6cCCkrIoab+BMwISbENbRrwu1jTTL pTpoNYNMPeBBGj51XJnwhhai1W52m+VmZgcI/8wU79H8r9sMW9X2SbN96oP/zoykJiYKNqad s1Yrq/1jG3/x1XQYjemNx4tEIYdUf27VG9mvNq5IV34TntSq9Yr3rZ95mDHoZgNk659y2v/O bv8nNcdmu5vSwYo9WbYsJAURtErv6s1SJS3REHxFSdstivsozWLYhnDHtYZB0qSApBsbeyA8 2vM5a7eFIKuk1o5jMtoG0e5EyIClbvVVs/1Oim6GakNcrsW6v0mjrrIbiHHuB524ZwtAgg5B 5bCRWpw9rPG/e0+CURL37AtT8034plQ/s46PLW4JwpLsPYXkvDwYYwLd9OCAKR2ip2Yg9nS6 r1a3Fab62+KWsrviWxdUq1WyZEp13ahU6+I20X63oVQs+lFLyOUHoWd10ia9DAsqfu9tZ1eK o93LOImly/BsEHuCl7jb6W2zLXbG21qlGkK6QyETvg2k593HndF1OAXnGXAigxDL2fVe1169 zqh3Ofh4aexfVM/bldauKEe5ykjBKD/dnVEPk8b4Omy6SMmsiB06Sn2qae3w597GXRCrpdeh oJ+OoXpG/vOdFZEYnkeMd287ImGru9/qGsU2aeFVISyHJ5akBpumNJzHszHYCkLdWdwfzIPT j6PxHGxYXNZjNvCcG4CX6MEY0r8PIbZoD05GcOR65G8an2lHMbYvdQ3R+WzQ81pOV2qCr3cF r0I1iH5yYm8J06qBnupZEVZXoAxpaHtPQr81AENWrUCkOO1KrQIcFwEMZimFBS7HYmmy6zhZ xjNwKEq8czwpiyPxpBweOlfDvWeu4lJIeK2wVjm0mUJpLw2XvmqK1dp3+qz+s1ruOjDqxtuV imD/kMMy2He9WUGP5S5hWCIhQaCrbOdglaou944sD0lwRoa3MO+QcC+idqvWWnbZ1bCNn5EY lCHQsxNLCwYXSe/8idgq1a6YWrUC1i4bG0rft5diZhmA5oKc1aU1ELwwNxsG2IFrI+GHOzlx tBVKhR9cRpQrOoDYPOfXYkfOJxjpAHwm5tHsI1g8udbjMiN3t9R+Ve12iMADa3eUCUKGVfUZ VaShZXhWD/SeBV2td7J9HB3+VvYoYB2BxIKutYJc6Cd222mnLtc/jOgFLohSevPZW7/J61S+ LABXfQN2iM6t4pjMKt9UM5BdcusXg0qqGWxCCKfZw3jGPmiB/SCc1/nysb8BicYrCNvOb74+ 4X0lq47kDaBCyhSbQW/o6VqqU2DMB7M+bYxt/GzXF43764u9fohy8S5Wdplki5iMcwfUZ6+A 2EarfdsnBYbbKtXaqQsDjzVOwHl7kFxywIlpNJg56Ebtd7MdnpyZqgif8Qntbgcww6gFH21/ BjvwdkUZpVaMl45921JbiD7i7ikuIqiDfCX4X62Bt3lXPmp2DS28nK0DZLTgtQE1gcx3eXSI s3TTgveBN/RsBNW+wnNscjlZDPsQj1LF4ME32YicKtD1hoIGDkYxBg1NGYAyc4M3V0KplBeM 4wT1jdJV7WIyG2GuAvcQY5vAEG7epW4OGyuJ9VgCbeCn0jwtgatoFrxx0kpEySjlJrZiNG2P OOXFfBaNk9EggeQgjEXE0znEre0PekL4g30VROMAs5LMFtM55TCfey788DgBwWfgBQIEKpOi u1iAEOIqLq6/Vk0o12UbciJNHOwvi/GnnZ0UP17yINDJeBAwz0dxU6vUGq/IbgCOn70nlklV rRI6j1ySaykutwoQ6h2Aun529Xv2fVQd2Sm4XeDnAiHQG8Xew/vi7vbh7ndP0lb1uNGPa92U bi3wdNa0exOAzgzFBEtvSrW6bam/64DUGmeus7GDbThBahX/4Ztifbanh8vvcpyexV1eSGvo BPLOCyB2kFtKXcjwAIBodnNZO0MO58cCwS1Jhwx48mL/4P5CBuw//31CBhip3jtSBNUvgssT WkAjGNm01nqM/JdwxPGcJ9Prmbi/z4OtciHY++6774I3YlVicbUMSuez6DIaBd9/GUX0639f TuajaDCEXBU/3HOuCivsgBDHz8SVKBV9QH//j22Iggo1ONQEhPJahBxjCfINgx70yPgos8EM UStolkBLKfAYs/YKgSAEgYBKIHrFRKBrIK7hk5ko0J/Zpzi2vyZ0U6UYNwmEX0Lx5yhz/Jhl aBh9TMIIUiYLKQgy0ifxXLeJH3uTxXhuDnc8EYDhLO596Yd4mCTp0vhqGvfEEWIBQJMQ4S28 6M2Hxsj75yFfaYyPvVk0FztqGvX1R9XqbGJ2Sd55kK0zvvJ817O60bI48oFVkdMf9M12R9EV zQsW2Czojc15zSfzaBgm8WcPHQi28sn8ewZpiI2qcDpHGIfX+s5Zty1sYWwV6EUC4geIPTP7 Elvj5trmaBCrNv5vDAF+CZao2X44jiKznz4QNKjqdB/4aTj5aoIlbr1kspj1Yqcmf+S6N9og I3/xxGy+mPgRNAkrGU8ujK84qmg4tUYx7M0QFCRGiKo8mhpbLxSUSyRhrcuXHmSRhu+JvY6w 3eHzRahpw79gfROE8SFgevbem2g68RIObQyFo2D8lTO1E/Jsg5dlCytZCqeyMbulQL7AmXr2 mAVbGEwH8XjuKfgSQpi48GIQDylTlrV3JmMOtwdbBt3Cbb5C6mPIPDaf4H96qJi0sDONx7jh ILhVzA7V9iCIKm7I6gbcM0hzlU9Mw8nHCWaWz9xg+ImHKChh3/t1z/t1V6+eVpAvpr6vahOA YciSISehczQh/4hm/TSvtRX6OR3TZ1sd7/tug8uZ0tDRBuUIE5NnDt4zcnq2VR9v+DkyHwlW O6LrctkHb1QA2rF3tmDi2Vw+tQUZIBH0Cf77zsckjl0eb3P3PrF2s5r3nAFA9clk4TjPZuV4 DbRI9H4MLzjy+xGIwezfjAFZUb0CspPAYae8lPFC2kKbt10kIcDbX5LFufPR4jNyk33ZO3LF LRCAUkIUHMqiwOArqoV962+LjvgrPGqnPn4RTEYwuMV4INgRURAIhJVMBFDpRtATp1/fkOMS Gxvng3k4iqbvD/Y/IKoP9gnDEH9WfJeYxpeFdTc5E00vnF6GnPrTlYiAfeJ/0/wTwsYJ5FzE EUr+67Bv3uUk8wAvBz5sNzAESUwImhj/LexFhqBZxUfcFM/wMZnwrlzJZf1BDwTW5P3BB0vE /vL+0PjAtMAoFZvvSzxkgBsM1bUuTRC2gP6N3cYhlI3tRs9GS7hWAOua4hzx5YWz9JJn3FSZ QxgBmdoqdBH0zH0MQiiDnBKJ7m4D8k4MsMDOInTkh9CJKTIAYOBiQySfGIbyzskhWFkinVF4 kxkdZYC442BZNSNi/Ac1EHi2Zw8LL5JkWmEbS6BZgP4nPZ1g/shXyKnEvWWY+l1ca64yITCT uwHhwgxGOd1DYVb3UOY2noZwB+jCjDDdfOYAqDhrCFSKXWQXy1T23mIjVbtncEn+4JLcwSX5 g0vyB5csHxxcTbLHZqS1Txc6Weo9rTtp54+yylN7ygLw7Gyr3M7s7hmGlaP9yF+aOQQrgbqv lPOh+4p0fvOsUk5X7is2s4+77OrjcHIeDSUfwMS5Ttpxbu7hKB4Zn8zbHRwIqF0mNT6o32ot jM4J76qkUKHzQV3UICgq4NmoC9XwVVPcqGbXEj5198RkyNfun/2+uJlDW6ProD8ZRZylCbPC wO/BBVl+YKsq4R03P5xMpnyBcYumcyyBlr/C4za4zAWY93x7PqEE6KgayWhYlGQ0LMWP2bW3 lArFhR62ztwHMkyDiEG+Ho1GOzs7wdsYsuP8F2Q1oAynNZ3E5+slNANZtMF4xsSzqDLHxDFH gYncLEnFNViySrLkIdesypSxcY0Ej4ohL6sj7U5mcUgA5qUUGqFsREeBNebRfGHQbiwET1Ku vU8/ppBQC8mHgmQa9WKkRJdyKSAwJJ6mdnx1VH52Re04mAvZN2smoeanOJ7Char3CXw2T086 MmIXbiGL9mGryBgTdB0T9SHOF4bVxo6nKBgMkt5EIOLaT4uIdAXjpfV4Bi+FQrwRUOYuB4VT CLl00xpL1BcJaRSnfURGWvy+KVXqkG+afnsLCR4fPt4w1g91r2wWgtXlQ2CUQGYAthgRu12h FFlUEo9oASZBcj3uXc4mY6Ds83j+NY7HkvuoB29FR+GAmPpjyt5hLpataUImaGiiUGQGtcoA BVI0ApjOhgMua6LGBf4gjxWFQrZBFuQ3+wUpWtx1Nyb9c/jVVu0KNnVOxyTyP4S11ZrwGOyC lMrljaiHXYmL7kbSw9EKcXkjpk7I3GsmLlgglG+wVdfHqUDpoXsWYCTuUJPWr4SpGjyvij+B q84jGRMAgl8H4kyYzK53IHOPQfEYGNuW9or88XLq+2pJZsa2hfPL25YqSLWnStw2aS5vrH2z JC6pPSlTODaePEgiLuIv8bhvl2RNSlDAex1W8EPG8PLDi6ZHJ2Vn3RkLzEX8xRqdJS7bn7MG Lcri9zrK4QdTPnpoC89HJvc75zHQr9YoDInZ7tCQldMFLCoW1R/Upj2YxDOYRA8mSQ8myRpM kjWYxBxMYg3GGQqfAMl7M8ojpPoxo05qOuhqIkAm1tXPK0lq2ZXkfZT+/t4IHvnBPGpncRwq KcwDpVvpn3sbF5+T4WT+PhXM0OxGQrHgmwksX9U8VHfRm5LOyDMIWfbeCdVotKqqW2yAgpVi 6npMkDWBA4stTOZzTNOX3l6xHxPi83t2Jv1gKzj1M9+V77zFNQA4OFrNJswxCunADpeQeMcm ZXY6sd6n41+6y2pXcOblFPIElHbhjM/oETx4irOgNxmBJCnOIrR4AtFpBi8iyTwJQJLDZLaG AgJvDSHIZKA9/NX/WoRIHKJKz1vtIaTAUqMia9RoNoOEj5i/heJdgGnQl0F/EQ1Rr5aAbJzM J2AlgGmUAPLjRIg4czrcA2V7tROUhslEHXpw/E2nME0pZJyWyts/nJSlcWuszFp18iOUjrEP eZTO/439vn3bCLaekyVfoagV10/ZuG9AwxNdKNtZU45hHdR7yyvgAwvtLFixXP7ecgv4YAj2 +GwA3izijjQM9ESKwYFhYriBTJeEaTEBQhIYXQ4u+I9oDmIwJqgWdKkg9jWETK/cDxTp8iOV kKY4KaIh7aJkJ/vg/BgCIWwh10WJ0EKHEhKXa0t9a2NTkpO66lcp+yMyn/M2QiEUlR1SiYmH 5+yz0cdYDIlTvAD3S6BJ/CV7HPJX5Aiy1fFihEA5W4H+lJU8ulBxgzBKLAXg3CpyRUBzQlJV 8NHsxNZ2jkNLoyvumOOY10X2jRdWGKp5yfUDDJcByHthDghnXg17Ys5pQL1GwUPxX6PESfOC JWL7Y84WXDf4LUv3CzXwYPnVWmqZCw0ao3OpH8hHWiMTDR5XnIQn42SeRx9DIREm713TeUsL XB9Q6sAv4t7fB/e5Vok2Ne8bda97v7f/DFKh/Qo7ESw/i2jRif/u47+H+O9z/PekiIbL+O+z IlXZw6K9Y/y3gv9W8V8E3j/Af5/gv0+5yv4z/PM7/LeE/2L1/TL+i43sYyMHe1zlAAdzgK0d 4JAOsM2Dp/gvNnWATR2UucohAh8i2CGCHWK/hwh8iMCH2O+hqoJdH2LXTxAJT7DfJ9jUE+z3 CTb4RM7lCbb2BFt7guN/isBPEewp9vsU+336HVd5isBPseunVAX7fYr9PsN+n2G/zw64yjPs +hm2+QzbfIb9PsOmnmEjz3FdnkuMPccWnmPF57hGz3FFvkOw73BI3+H37465ync4jO9wGN8h cAnnUsJ+S9hvCSuW5FxKOIASzqWEwyhhIyVs5BjncowjOZZzOcYhHWObx9jmMc7lGJs6xkbK 2G/5CVcpI1gZuy4jcBmBy9hvmapgv+UqV6lg1xXsuoKtVbDfCvZbwQYr2FSlJKtgO1XETxWr V7F6FStWEVeQdObmyGeGKY3wYJv9fyx8RELq8QIA --4ZLFUWh1odzi/v6L-- From tgraf@suug.ch Sun Feb 6 10:53:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 10:54:05 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Irwai010031 for ; Sun, 6 Feb 2005 10:53:58 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 2D8D5F; Sun, 6 Feb 2005 19:53:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5DAF21C0EA; Sun, 6 Feb 2005 19:54:17 +0100 (CET) Date: Sun, 6 Feb 2005 19:54:17 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-ID: <20050206185417.GU31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050128230327.GV31837@postel.suug.ch> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 595 Lines: 15 > NLMSG_GOODSIZE specifies a good default size for the skb tailroom > used in netlink messages when the size is unknown at the time of > the allocation. > > The current value doesn't make much sense anymore because > skb_shared_info isn't taken into account which means that > depending on the architecture NLMSG_GOOSIZE can exceed PAGE_SIZE > resulting in a waste of almost a complete page. > > Using SKB_MAXORDER solves this potential leak at the cost of > slightly smaller but safer sizes for some architectures. > > Signed-off-by: Thomas Graf Dave, did you get this one? From rkagan@mail.ru Sun Feb 6 11:20:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 11:20:44 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16JKbV9011298 for ; Sun, 6 Feb 2005 11:20:39 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id 045834DF0A2; Sun, 6 Feb 2005 22:19:16 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.53.120] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 397882792; Sun, 06 Feb 2005 22:19:16 +0300 Date: Sun, 6 Feb 2005 22:19:18 +0300 From: Roman Kagan To: chas3@users.sourceforge.net Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050206191918.GA2369@katya> Mail-Followup-To: Roman Kagan , chas3@users.sourceforge.net, netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org References: <20050204201327.GA2439@katya> <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 908 Lines: 20 On Sat, Feb 05, 2005 at 08:33:18PM -0500, chas williams - CONTRACTOR wrote: > In message <20050204201327.GA2439@katya>,Roman Kagan writes: > >initializing atm_dev. I suspect the only way to fix it is to split the > >atm_dev initialization into two stages, allocation and registration, as > >it is done for net_device. > > yeah which is why i just wanted to convert atm_dev to just be a netdevice. > the code is already written and "stable". Is it publically available? Linux-ATM CVS appears to contain no kernelspace code. I'm just curious how atm_dev attributes are mapped to net_device's, which doesn't look easy with the current atm_dev and net_device. Also, is it scheduled for inclusion in the mainline any time soon? If it is, maybe we shouldn't create an atm-specific user-visible interface in sysfs and hotplug which is going to be obsoleted by the net generic one in the near future? Roman. From hadi@cyberus.ca Sun Feb 6 11:49:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 11:49:16 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16JnBg1012398 for ; Sun, 6 Feb 2005 11:49:12 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CxsP6-0003ws-Oi for netdev@oss.sgi.com; Sun, 06 Feb 2005 14:49:08 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxsP4-0005tJ-V0; Sun, 06 Feb 2005 14:49:07 -0500 Subject: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-hXDhNYmEsldW+1l6It/N" Organization: jamalopolous Message-Id: <1107719343.1055.22.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 14:49:04 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1343 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: 3521 Lines: 130 --=-hXDhNYmEsldW+1l6It/N Content-Type: text/plain Content-Transfer-Encoding: 7bit bug is around since 2.1.x; never cared about chasing it until now because it is affecting someone i know. Dave, please apply. I will prepare a 2.4.x version. To see the problem: tc qdisc add dev eth0 ingress #add two filters at different prio levels tc filter add dev eth0 parent ffff: protocol ip prio 6 \ u32 match ip src 10.0.0.210/32 flowid 1:16 # tc filter add dev eth0 parent ffff: protocol ip prio 7 \ u32 match ip src 10.0.0.144/32 flowid 1:15 #now list them.. root@jdev:/# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 801: ht divisor 1 filter protocol ip pref 6 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801: ht divisor 1 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 filter protocol ip pref 7 u32 fh 800: ht divisor 1 filter protocol ip pref 7 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 each filter is listed in each priority. So if you had 5 rules in 5 prios (which is where sherlock started) you see 25 outputs. AFTER FIX: --------- root@jdev:/usr/src# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 cheers, jamal --=-hXDhNYmEsldW+1l6It/N Content-Disposition: attachment; filename=u32multi_p Content-Type: text/plain; name=u32multi_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 2611-rc3+bk3/net/sched/cls_api.c 2005/02/06 16:28:26 1.1 +++ 2611-rc3+bk3/net/sched/cls_api.c 2005/02/06 16:41:47 @@ -326,6 +326,7 @@ { struct tcmsg *tcm; struct nlmsghdr *nlh; + int ret; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); @@ -339,8 +340,11 @@ tcm->tcm_handle = fh; if (RTM_DELTFILTER != event) { tcm->tcm_handle = 0; - if (tp->ops->dump && tp->ops->dump(tp, fh, skb, tcm) < 0) - goto rtattr_failure; + if (tp->ops->dump) { + ret = tp->ops->dump(tp, fh, skb, tcm); + if (ret < 0) + goto rtattr_failure; + } } nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -348,6 +352,8 @@ nlmsg_failure: rtattr_failure: skb_trim(skb, b - skb->data); + if (ret == -ENOENT) + return skb->len; return -1; } --- 2611-rc3+bk3/net/sched/cls_u32.c 2005/02/06 16:30:44 1.1 +++ 2611-rc3+bk3/net/sched/cls_u32.c 2005/02/06 16:33:13 @@ -76,6 +76,7 @@ char indev[IFNAMSIZ]; #endif u8 fshift; + u32 prio; struct tcf_result res; struct tc_u_hnode *ht_down; #ifdef CONFIG_CLS_U32_PERF @@ -641,6 +642,7 @@ memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; n->handle = handle; + n->prio = tp->prio; { u8 i = 0; u32 mask = s->hmask; @@ -736,6 +738,9 @@ if (n == NULL) return skb->len; + if (n->prio != tp->prio) + return -ENOENT; + t->tcm_handle = n->handle; rta = (struct rtattr*)b; --=-hXDhNYmEsldW+1l6It/N-- From akpm@osdl.org Sun Feb 6 12:26:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:26:20 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16KQEHU017228 for ; Sun, 6 Feb 2005 12:26:14 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j16KQ8l21411; Sun, 6 Feb 2005 12:26:08 -0800 Date: Sun, 6 Feb 2005 12:26:04 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: mh+kernel-bugzilla@zugschlus.de Subject: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Message-Id: <20050206122604.74a41796.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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1344 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: 2004 Lines: 50 Begin forwarded message: Date: Sun, 6 Feb 2005 04:08:01 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses http://bugme.osdl.org/show_bug.cgi?id=4177 Summary: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Kernel Version: 2.6.current, 2.4.current Status: NEW Severity: low Owner: acme@conectiva.com.br Submitter: mh+kernel-bugzilla@zugschlus.de This wishlist item is mostly relevant to German users. In Germany, Deutsche Telekom has a near monopoly regarding DSL connections to residential homes. They are, however, required, to resell their network to other ISPs which has led to a rather interesting combination of Internet tariffs and feature sets available via Deutsche Telekom T-DSL connections. Technical Basis for the T-DSL customer interface is PPPoE over a bridged ATM session, so it is technically possible to have multiple PPPoE sessions on the same line, allowing concurrent use of more than a single ISP which might be interesting with special interest services like streaming, fixed IP address and/or flat rate. However, Deutsche Telekom technically forbids multiple PPPoE sessions originating from a single MAC address, so one needs multiple network interfaces to originate the PPPoE sessions from. Sven Geggus has a patch against rp-pppoed, which allows to fake the sending MAC address for additional PPPoE sessions, circumventing the artificially introduced limitation of the T-DSL connection. The patch is available on http://geggus.net/sven/rp-pppoe-fakemac.diff Please consider adding that possibility to the kernel PPPoE code as well. Greetings Marc ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From 64vn@cardvn.net Sun Feb 6 12:39:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:39:56 -0800 (PST) Received: from isp-go.FPT.NET (isp-go.fpt.net [210.245.0.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Kdltw017955 for ; Sun, 6 Feb 2005 12:39:48 -0800 Received: from isp-mta2.fpt.vn ([210.245.0.151]) by isp-go.FPT.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 03:39:40 +0700 Received: from [203.210.206.111] by isp-mta2.fpt.vn [210.245.0.151] Message-ID: <4206808A.1050304@cardvn.net> Date: Mon, 07 Feb 2005 03:39:38 +0700 From: Nguyen Dinh Nam <64vn@cardvn.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses References: <20050206122604.74a41796.akpm@osdl.org> In-Reply-To: <20050206122604.74a41796.akpm@osdl.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2005 20:39:40.0499 (UTC) FILETIME=[FB3CF230:01C50C8B] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: 64vn@cardvn.net Precedence: bulk X-list: netdev Content-Length: 2297 Lines: 60 I have another situation - there are 2 different PPPoE access concentrators available on 1 interface. So I want to be able to specify the MAC address (or AC Name, or Service Name) of the AC to connect to Thanks Andrew Morton wrote: >Begin forwarded message: > >Date: Sun, 6 Feb 2005 04:08:01 -0800 >From: bugme-daemon@osdl.org >To: bugme-new@lists.osdl.org >Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses > > >http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > >This wishlist item is mostly relevant to German users. In >Germany, Deutsche Telekom has a near monopoly regarding DSL >connections to residential homes. They are, however, required, to >resell their network to other ISPs which has led to a rather >interesting combination of Internet tariffs and feature sets available >via Deutsche Telekom T-DSL connections. > >Technical Basis for the T-DSL customer interface is PPPoE over a >bridged ATM session, so it is technically possible to have multiple >PPPoE sessions on the same line, allowing concurrent use of more than >a single ISP which might be interesting with special interest services >like streaming, fixed IP address and/or flat rate. > >However, Deutsche Telekom technically forbids multiple PPPoE sessions >originating from a single MAC address, so one needs multiple network >interfaces to originate the PPPoE sessions from. > >Sven Geggus has a patch against rp-pppoed, which allows to fake the >sending MAC address for additional PPPoE sessions, circumventing the >artificially introduced limitation of the T-DSL connection. The patch >is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > >Please consider adding that possibility to the kernel PPPoE code as well. > >Greetings >Marc > >------- You are receiving this mail because: ------- >You are on the CC list for the bug, or are watching someone who is. > > > > From hadi@cyberus.ca Sun Feb 6 12:44:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:44:27 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16KiMmm018501 for ; Sun, 6 Feb 2005 12:44:23 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxtGW-0005SO-PW for netdev@oss.sgi.com; Sun, 06 Feb 2005 15:44:20 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxtGU-0003tG-Ez; Sun, 06 Feb 2005 15:44:18 -0500 Subject: 2.4.29 version: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> References: <1107719343.1055.22.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-i+I4Hm8GUCMTgdvgQnby" Organization: jamalopolous Message-Id: <1107722655.1054.24.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 15:44:15 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1346 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: 2021 Lines: 84 --=-i+I4Hm8GUCMTgdvgQnby Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-02-06 at 14:49, jamal wrote: > bug is around since 2.1.x; never cared about chasing it until now > because it is affecting someone i know. > Dave, please apply. I will prepare a 2.4.x version. > Attached. cheers, jamal --=-i+I4Hm8GUCMTgdvgQnby Content-Disposition: attachment; filename=p2429 Content-Type: text/plain; name=p2429; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- cls_api.c.orig 2004-02-18 08:36:32.000000000 -0500 +++ cls_api.c 2005-02-06 12:21:32.976531360 -0500 @@ -289,6 +289,7 @@ { struct tcmsg *tcm; struct nlmsghdr *nlh; + int ret; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); @@ -300,14 +301,19 @@ tcm->tcm_handle = 0; tcm->tcm_info = TC_H_MAKE(tp->prio, tp->protocol); RTA_PUT(skb, TCA_KIND, IFNAMSIZ, tp->ops->kind); - if (tp->ops->dump && tp->ops->dump(tp, fh, skb, tcm) < 0) - goto rtattr_failure; + if (tp->ops->dump) { + ret = tp->ops->dump(tp, fh, skb, tcm); + if (ret < 0) + goto rtattr_failure; + } nlh->nlmsg_len = skb->tail - b; return skb->len; nlmsg_failure: rtattr_failure: skb_trim(skb, b - skb->data); + if (ret == -ENOENT) + return skb->len; return -1; } --- cls_u32.c.orig 2004-11-17 06:54:22.000000000 -0500 +++ cls_u32.c 2005-02-06 12:25:31.000346240 -0500 @@ -61,6 +61,7 @@ #ifdef CONFIG_NET_CLS_POLICE struct tcf_police *police; #endif + u32 prio; struct tcf_result res; struct tc_u_hnode *ht_down; struct tc_u32_sel sel; @@ -577,6 +578,7 @@ memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; n->handle = handle; + n->prio = tp->prio; err = u32_set_parms(tp->q, base, ht, n, tb, tca[TCA_RATE-1]); if (err == 0) { struct tc_u_knode **ins; @@ -639,6 +641,9 @@ if (n == NULL) return skb->len; + if (n->prio != tp->prio) + return -ENOENT; + t->tcm_handle = n->handle; rta = (struct rtattr*)b; --=-i+I4Hm8GUCMTgdvgQnby-- From acme@conectiva.com.br Sun Feb 6 12:48:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:48:26 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16KmJAw019037 for ; Sun, 6 Feb 2005 12:48:20 -0800 Received: from [200.138.51.5] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1CxsbT-00067Q-00; Sun, 06 Feb 2005 18:01:56 -0200 Received: from [192.168.1.6] (amd64.kerneljanitors.org [192.168.1.6]) by oops.ghostprotocols.net (Postfix) with ESMTP id 511A41462D; Sun, 6 Feb 2005 18:48:15 -0200 (BRST) Message-ID: <420683CB.2010205@conectiva.com.br> Date: Sun, 06 Feb 2005 18:53:31 -0200 From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. User-Agent: Mozilla Thunderbird 1.0 (X11/20041220) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: mostrows@speakeasy.net Cc: Networking Team Subject: Re: [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses References: <200502061207.j16C7UOB009882@fire-1.osdl.org> In-Reply-To: <200502061207.j16C7UOB009882@fire-1.osdl.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 1862 Lines: 44 bugme-daemon@osdl.org escreveu: > http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > > This wishlist item is mostly relevant to German users. In > Germany, Deutsche Telekom has a near monopoly regarding DSL > connections to residential homes. They are, however, required, to > resell their network to other ISPs which has led to a rather > interesting combination of Internet tariffs and feature sets available > via Deutsche Telekom T-DSL connections. > > Technical Basis for the T-DSL customer interface is PPPoE over a > bridged ATM session, so it is technically possible to have multiple > PPPoE sessions on the same line, allowing concurrent use of more than > a single ISP which might be interesting with special interest services > like streaming, fixed IP address and/or flat rate. > > However, Deutsche Telekom technically forbids multiple PPPoE sessions > originating from a single MAC address, so one needs multiple network > interfaces to originate the PPPoE sessions from. > > Sven Geggus has a patch against rp-pppoed, which allows to fake the > sending MAC address for additional PPPoE sessions, circumventing the > artificially introduced limitation of the T-DSL connection. The patch > is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > > Please consider adding that possibility to the kernel PPPoE code as well. > > Greetings > Marc > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > From hadi@cyberus.ca Sun Feb 6 12:51:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:51:10 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Kp57l019573 for ; Sun, 6 Feb 2005 12:51:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1CxtMw-0007dd-IE for netdev@oss.sgi.com; Sun, 06 Feb 2005 13:50:58 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxtMy-0004bz-S3; Sun, 06 Feb 2005 15:51:01 -0500 Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses From: jamal Reply-To: hadi@cyberus.ca To: Andrew Morton Cc: netdev@oss.sgi.com, mh+kernel-bugzilla@zugschlus.de In-Reply-To: <20050206122604.74a41796.akpm@osdl.org> References: <20050206122604.74a41796.akpm@osdl.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107723057.1055.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 15:50:57 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1348 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: 2351 Lines: 61 Does that patch help at all? Seems to me all it enables is session setup, but after that what happens? Do packets go out with the MAC address you just spoofed for the data as well? cheers, jamal On Sun, 2005-02-06 at 15:26, Andrew Morton wrote: > Begin forwarded message: > > Date: Sun, 6 Feb 2005 04:08:01 -0800 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses > > > http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > > This wishlist item is mostly relevant to German users. In > Germany, Deutsche Telekom has a near monopoly regarding DSL > connections to residential homes. They are, however, required, to > resell their network to other ISPs which has led to a rather > interesting combination of Internet tariffs and feature sets available > via Deutsche Telekom T-DSL connections. > > Technical Basis for the T-DSL customer interface is PPPoE over a > bridged ATM session, so it is technically possible to have multiple > PPPoE sessions on the same line, allowing concurrent use of more than > a single ISP which might be interesting with special interest services > like streaming, fixed IP address and/or flat rate. > > However, Deutsche Telekom technically forbids multiple PPPoE sessions > originating from a single MAC address, so one needs multiple network > interfaces to originate the PPPoE sessions from. > > Sven Geggus has a patch against rp-pppoed, which allows to fake the > sending MAC address for additional PPPoE sessions, circumventing the > artificially introduced limitation of the T-DSL connection. The patch > is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > > Please consider adding that possibility to the kernel PPPoE code as well. > > Greetings > Marc > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > From herbert@gondor.apana.org.au Sun Feb 6 13:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:03:11 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16L33OI020273 for ; Sun, 6 Feb 2005 13:03:04 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CxtY4-0006Rz-00; Mon, 07 Feb 2005 08:02:28 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxtXS-0006Iq-00; Mon, 07 Feb 2005 08:01:50 +1100 Date: Mon, 7 Feb 2005 08:01:50 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206210150.GA24206@gondor.apana.org.au> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> <20050206114145.GA20883@gondor.apana.org.au> <20050206.213018.92031627.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.213018.92031627.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 543 Lines: 15 On Sun, Feb 06, 2005 at 09:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()? Great, that definitely fixes the local address problem. I'm not sure about anycast routes though. Who's going to delete them when the real device goes down? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sun Feb 6 13:15:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:15:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LFi8K021157 for ; Sun, 6 Feb 2005 13:15:45 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CxtdR-0001vM-00; Sun, 06 Feb 2005 13:08:01 -0800 Date: Sun, 6 Feb 2005 13:08:00 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-Id: <20050206130800.7b775e1a.davem@davemloft.net> In-Reply-To: <20050206185417.GU31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050206185417.GU31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 188 Lines: 7 On Sun, 6 Feb 2005 19:54:17 +0100 Thomas Graf wrote: > Dave, did you get this one? Yes I did. I'm just busy with all the memory barrier stuff this past few days, sorry. From mh+kernel-bugzilla@zugschlus.de Sun Feb 6 13:25:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:25:11 -0800 (PST) Received: from torres.int.l21.ma.zugschlus.de (Debian-exim@5301d.unt0.torres.l21.ma.zugschlus.de [217.151.83.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LP7xY021833 for ; Sun, 6 Feb 2005 13:25:08 -0800 Received: from mh by torres.int.l21.ma.zugschlus.de with local (Exim 4.44) id 1Cxtts-0006UD-9z; Sun, 06 Feb 2005 22:25:00 +0100 Date: Sun, 6 Feb 2005 22:25:00 +0100 From: Marc Haber To: jamal Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Message-ID: <20050206212500.GF17682@torres.l21.ma.zugschlus.de> References: <20050206122604.74a41796.akpm@osdl.org> <1107723057.1055.28.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107723057.1055.28.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mh+kernel-bugzilla@zugschlus.de Precedence: bulk X-list: netdev Content-Length: 806 Lines: 21 On Sun, Feb 06, 2005 at 03:50:57PM -0500, jamal wrote: > Does that patch help at all? It helps with the user space pppoed, yes. > Seems to me all it enables is session setup, but after that what > happens? Do packets go out with the MAC address you just spoofed > for the data as well? With user space pppoed, yes. When applied to the normal pppd, using kernel pppoe, only session setup goes out with the fake MAC, and this doesn't lead to a useable pppoe session, of course. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From tgraf@suug.ch Sun Feb 6 13:29:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:29:13 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LT8le022419 for ; Sun, 6 Feb 2005 13:29:09 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id CF956F; Sun, 6 Feb 2005 22:28:45 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8AA6E1C0EA; Sun, 6 Feb 2005 22:29:28 +0100 (CET) Date: Sun, 6 Feb 2005 22:29:28 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-ID: <20050206212928.GV31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 724 Lines: 13 * jamal <1107719343.1055.22.camel@jzny.localdomain> 2005-02-06 14:49 > > bug is around since 2.1.x; never cared about chasing it until now > because it is affecting someone i know. Good catch, I've put a workaround for this into libnl a while back. I wasn't sure whether it's supposed to be a feature or not. ;-> Another quite anoying detail is the fact that cbq uses the same handle for both the root qdisc and root class which makes it impossible to uniquely assign filters attached to it, i.e. listing filters based on parent == XX: && dev == %DEV will result in the filters being listed for both the qdisc and the class. I haven't found a fix that wouldn't break many scripts so if you have a good idea, go ahead. ;-> From kaber@trash.net Sun Feb 6 13:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:40:32 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LePBe023114 for ; Sun, 6 Feb 2005 13:40:26 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1Cxu8A-00027r-D6; Sun, 06 Feb 2005 22:39:46 +0100 Message-ID: <42068EA2.6030507@trash.net> Date: Sun, 06 Feb 2005 22:39:46 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------060009020002090402080907" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2700 Lines: 89 This is a multi-part message in MIME format. --------------060009020002090402080907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit jamal wrote: >bug is around since 2.1.x; never cared about chasing it until now >because it is affecting someone i know. >Dave, please apply. I will prepare a 2.4.x version. > The patch is wrong. The "divisor"-lines are missing in the output with your patch and it only hides the real error. ->walk is supposed to walk all filters of the given priority/protocol, but u32 walks all filters. This patch fixes it. Output with new patch: filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 0 success 0) match 0a0000d2/ffffffff at 12 (success 0 ) filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801: ht divisor 1 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 (rule hit 0 success 0) match 0a000090/ffffffff at 12 (success 0 ) Signed-off-by: Patrick McHardy BTW: u32_walk seems to have another bug, it uses tcf_walker->count and tcf_walker->skip for skipping over both hnodes and knodes and doesn't skip hnodes properly at all. I'll have a look at this now. Regards Patrick >AFTER FIX: >--------- > >root@jdev:/usr/src# tc -s filter show parent ffff: dev eth0 >filter protocol ip pref 6 u32 >filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 >flowid 1:16 > match 0a0000d2/ffffffff at 12 > filter protocol ip pref 7 u32 > filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 >flowid 1:15 > match 0a000090/ffffffff at 12 > > > --------------060009020002090402080907 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/sched/cls_u32.c 1.25 vs edited ===== --- 1.25/net/sched/cls_u32.c 2005-01-11 20:25:16 +01:00 +++ edited/net/sched/cls_u32.c 2005-02-06 22:20:33 +01:00 @@ -91,6 +91,7 @@ { struct tc_u_hnode *next; u32 handle; + u32 prio; struct tc_u_common *tp_c; int refcnt; unsigned divisor; @@ -323,6 +324,7 @@ root_ht->divisor = 0; root_ht->refcnt++; root_ht->handle = tp_c ? gen_new_htid(tp_c) : 0x80000000; + root_ht->prio = tp->prio; if (tp_c == NULL) { tp_c = kmalloc(sizeof(*tp_c), GFP_KERNEL); @@ -703,6 +705,8 @@ return; for (ht = tp_c->hlist; ht; ht = ht->next) { + if (ht->prio != tp->prio) + continue; if (arg->count >= arg->skip) { if (arg->fn(tp, (unsigned long)ht, arg) < 0) { arg->stop = 1; --------------060009020002090402080907-- From hadi@cyberus.ca Sun Feb 6 13:42:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:42:25 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LgLcN023554 for ; Sun, 6 Feb 2005 13:42:21 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxuAd-00031k-2N for netdev@oss.sgi.com; Sun, 06 Feb 2005 16:42:19 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxuAa-0002Cq-Nw; Sun, 06 Feb 2005 16:42:17 -0500 Subject: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050206212928.GV31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107726133.1055.34.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 16:42:13 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1354 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: 754 Lines: 20 On Sun, 2005-02-06 at 16:29, Thomas Graf wrote: > assign filters attached to it, i.e. listing filters based on > parent == XX: && dev == %DEV will result in the filters being listed > for both the qdisc and the class. I haven't found a fix that wouldn't > break many scripts so if you have a good idea, go ahead. ;-> I cant say ive run into this one - mostly i attach filters to root. Example script? BTW, cycles allow me to work on the eaction stuff today. So far ive come to the conclusion that whats really needed to simplify writting some actions is to just provide generic methods they can use without them necessarily knowing details. I hope to test later on, maybe write a simple action and its user apce piece, and post patch. cheers, jamal From hadi@cyberus.ca Sun Feb 6 13:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:45:20 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LjGRf024161 for ; Sun, 6 Feb 2005 13:45:16 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxuDS-0004Pj-Er for netdev@oss.sgi.com; Sun, 06 Feb 2005 16:45:14 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxuDP-0002Tv-3q; Sun, 06 Feb 2005 16:45:11 -0500 Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses From: jamal Reply-To: hadi@cyberus.ca To: Marc Haber Cc: Andrew Morton , netdev@oss.sgi.com In-Reply-To: <20050206212500.GF17682@torres.l21.ma.zugschlus.de> References: <20050206122604.74a41796.akpm@osdl.org> <1107723057.1055.28.camel@jzny.localdomain> <20050206212500.GF17682@torres.l21.ma.zugschlus.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107726307.1054.38.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 16:45:08 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1355 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: 442 Lines: 15 On Sun, 2005-02-06 at 16:25, Marc Haber wrote: > On Sun, Feb 06, 2005 at 03:50:57PM -0500, jamal wrote: > > Does that patch help at all? > > It helps with the user space pppoed, yes. Remind me again: With user space pppoe if you have a web server that people access from outside world, all packets go to user space and then back to the kernel before hitting user space again? Only in such a case can i see this working ... cheers, jamal From kaber@trash.net Sun Feb 6 13:48:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:48:05 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Lm1dq024733 for ; Sun, 6 Feb 2005 13:48:01 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CxuFX-00029N-0C; Sun, 06 Feb 2005 22:47:23 +0100 Message-ID: <4206906A.2060501@trash.net> Date: Sun, 06 Feb 2005 22:47:22 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> In-Reply-To: <20050206212928.GV31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 495 Lines: 15 Thomas Graf wrote: >Another >quite anoying detail is the fact that cbq uses the same handle for >both the root qdisc and root class which makes it impossible to uniquely >assign filters attached to it, i.e. listing filters based on >parent == XX: && dev == %DEV will result in the filters being listed >for both the qdisc and the class. > CBQ and HFSC only support filters attached to classes for exactly this reason :) Shouldn't make any difference from a users perspective. Regards Patrick From kaber@trash.net Sun Feb 6 13:55:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:55:54 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LtnEa025506 for ; Sun, 6 Feb 2005 13:55:50 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CxuNa-0006Cv-QS; Sun, 06 Feb 2005 22:55:42 +0100 Message-ID: <4206925E.8030107@trash.net> Date: Sun, 06 Feb 2005 22:55:42 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> In-Reply-To: <42068EA2.6030507@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1207 Lines: 46 Patrick McHardy wrote: > The patch is wrong. The "divisor"-lines are missing in the output with > your patch and it only hides the real error. ->walk is supposed to walk > all filters of the given priority/protocol, but u32 walks all filters. > This patch fixes it. Output with new patch: The patch also applies to 2.4. Regards Patrick > >------------------------------------------------------------------------ > >===== net/sched/cls_u32.c 1.25 vs edited ===== >--- 1.25/net/sched/cls_u32.c 2005-01-11 20:25:16 +01:00 >+++ edited/net/sched/cls_u32.c 2005-02-06 22:20:33 +01:00 >@@ -91,6 +91,7 @@ > { > struct tc_u_hnode *next; > u32 handle; >+ u32 prio; > struct tc_u_common *tp_c; > int refcnt; > unsigned divisor; >@@ -323,6 +324,7 @@ > root_ht->divisor = 0; > root_ht->refcnt++; > root_ht->handle = tp_c ? gen_new_htid(tp_c) : 0x80000000; >+ root_ht->prio = tp->prio; > > if (tp_c == NULL) { > tp_c = kmalloc(sizeof(*tp_c), GFP_KERNEL); >@@ -703,6 +705,8 @@ > return; > > for (ht = tp_c->hlist; ht; ht = ht->next) { >+ if (ht->prio != tp->prio) >+ continue; > if (arg->count >= arg->skip) { > if (arg->fn(tp, (unsigned long)ht, arg) < 0) { > arg->stop = 1; > > From hadi@cyberus.ca Sun Feb 6 14:02:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:02:22 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16M2Hxi026105 for ; Sun, 6 Feb 2005 14:02:18 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CxuTx-0002Tx-M8 for netdev@oss.sgi.com; Sun, 06 Feb 2005 17:02:17 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxuTt-0004BI-C6; Sun, 06 Feb 2005 17:02:13 -0500 Subject: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <42068EA2.6030507@trash.net> References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107727330.1053.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 17:02:10 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1358 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: 468 Lines: 16 On Sun, 2005-02-06 at 16:39, Patrick McHardy wrote: > jamal wrote: > > >bug is around since 2.1.x; never cared about chasing it until now > >because it is affecting someone i know. > >Dave, please apply. I will prepare a 2.4.x version. > > > The patch is wrong. The "divisor"-lines are missing in the output with I should have caught that output missing divisor ;-> Dave please apply Patricks version. Should probably apply cleanly on 2.4.x as well. cheers, jamal From tgraf@suug.ch Sun Feb 6 14:11:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:12:01 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16MBtfB026957 for ; Sun, 6 Feb 2005 14:11:55 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id A583384; Sun, 6 Feb 2005 23:11:32 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4FF2A1C0EA; Sun, 6 Feb 2005 23:12:15 +0100 (CET) Date: Sun, 6 Feb 2005 23:12:15 +0100 From: Thomas Graf To: Patrick McHardy Cc: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-ID: <20050206221215.GW31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> <4206906A.2060501@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4206906A.2060501@trash.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 916 Lines: 19 * Patrick McHardy <4206906A.2060501@trash.net> 2005-02-06 22:47 > Thomas Graf wrote: > > >Another > >quite anoying detail is the fact that cbq uses the same handle for > >both the root qdisc and root class which makes it impossible to uniquely > >assign filters attached to it, i.e. listing filters based on > >parent == XX: && dev == %DEV will result in the filters being listed > >for both the qdisc and the class. > > > CBQ and HFSC only support filters attached to classes for exactly this > reason :) Shouldn't make any difference from a users perspective. I'm aware of it and that's not the problem. The problem is that if the user requests the filters attached to parent XX: he can't tell whether the qdisc or class parent is meant without checking for hardcoded qdisc kinds which makes it pretty much impossible to generate qdisc/class/filter trees in a generic way. It's just something anoying not a bug. From hadi@cyberus.ca Sun Feb 6 14:13:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:13:55 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16MDme6027383 for ; Sun, 6 Feb 2005 14:13:49 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Cxuf4-0001wv-Ig for netdev@oss.sgi.com; Sun, 06 Feb 2005 17:13:46 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cxuf2-0005Ji-9g; Sun, 06 Feb 2005 17:13:44 -0500 Subject: instead of eaction From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-ib5mRFwAOsTDqQaOBM5K" Organization: jamalopolous Message-Id: <1107728020.1055.50.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 17:13:41 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1360 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: 7877 Lines: 320 --=-ib5mRFwAOsTDqQaOBM5K Content-Type: text/plain Content-Transfer-Encoding: 7bit I think i am going to throw out the idea of eaction; instead just provide some defaults. First patch adds some defaults and second a quick simple example. I have to take off; but maybe i will get time to work on meta action as well as csum action when i get back. Comments welcome cheers, jamal --=-ib5mRFwAOsTDqQaOBM5K Content-Disposition: attachment; filename=p15 Content-Type: text/plain; name=p15; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/net/act_generic.h 2005-02-06 15:55:36.000000000 -0500 @@ -0,0 +1,135 @@ +/* +*/ +static inline int tcf_defact_release(struct tcf_defact *p, int bind) +{ + int ret = 0; + if (p) { + if (bind) { + p->bindcnt--; + } + p->refcnt--; + if (p->bindcnt <= 0 && p->refcnt <= 0) { + kfree(p->defdata); + tcf_hash_destroy(p); + ret = 1; + } + } + return ret; +} + +static inline int +alloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + p->defdata = kmalloc(datalen, GFP_KERNEL); + if (p->defdata == NULL) + return -ENOMEM; + p->datalen = datalen; + memcpy(p->defdata, defdata, datalen); + return 0; +} + +static inline int +realloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + /* safer to be just brute force for now */ + kfree(p->defdata); + return alloc_defdata(p, datalen, defdata); +} + +static inline int +tcf_defact_init(struct rtattr *rta, struct rtattr *est, + struct tc_action *a, int ovr, int bind) +{ + struct rtattr *tb[TCA_DEF_MAX]; + struct tc_defact *parm; + struct tcf_defact *p; + void *defdata; + u32 datalen = 0; + int ret = 0; + + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) + return -EINVAL; + + if (tb[TCA_DEF_PARMS - 1] == NULL) + return -EINVAL; + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); + defdata = RTA_DATA(tb[TCA_DEF_DATA - 1]); + if (defdata == NULL) + return -EINVAL; + + datalen = RTA_PAYLOAD(tb[TCA_DEF_DATA - 1]); + if (datalen <= 0) + return -EINVAL; + + p = tcf_hash_check(parm->index, a, ovr, bind); + if (p == NULL) { + p = tcf_hash_create(parm->index, est, a, sizeof(*p), ovr, bind); + if (p == NULL) + return -ENOMEM; + + ret = alloc_defdata(p, datalen, defdata); + if (ret < 0) { + kfree(p); + return ret; + } + ret = ACT_P_CREATED; + } else { + if (!ovr) { + tcf_defact_release(p, bind); + return -EEXIST; + } + realloc_defdata(p, datalen, defdata); + } + + spin_lock_bh(&p->lock); + p->action = parm->action; + spin_unlock_bh(&p->lock); + if (ret == ACT_P_CREATED) + tcf_hash_insert(p); + return ret; +} + +static inline int tcf_defact_cleanup(struct tc_action *a, int bind) +{ + struct tcf_defact *p = PRIV(a, defact); + + if (p != NULL) + return tcf_defact_release(p, bind); + return 0; +} + +static inline int +tcf_defact_dump(struct sk_buff *skb, struct tc_action *a, int bind, int ref) +{ + unsigned char *b = skb->tail; + struct tc_defact opt; + struct tcf_defact *p = PRIV(a, defact); + struct tcf_t t; + + opt.index = p->index; + opt.refcnt = p->refcnt - ref; + opt.bindcnt = p->bindcnt - bind; + opt.action = p->action; + RTA_PUT(skb, TCA_DEF_PARMS, sizeof(opt), &opt); + RTA_PUT(skb, TCA_DEF_DATA, p->datalen, p->defdata); + t.install = jiffies_to_clock_t(jiffies - p->tm.install); + t.lastuse = jiffies_to_clock_t(jiffies - p->tm.lastuse); + t.expires = jiffies_to_clock_t(p->tm.expires); + RTA_PUT(skb, TCA_DEF_TM, sizeof(t), &t); + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +#define tca_use_default_ops \ + .dump = tcf_defact_dump, \ + .cleanup = tcf_defact_cleanup, \ + .init = tcf_defact_init, \ + .walk = tcf_generic_walker, \ + +#define tca_use_default_defines(name) \ + static u32 idx_gen; \ + static struct tcf_defact *tcf_##name_ht[MY_TAB_SIZE]; \ + static DEFINE_RWLOCK(##name_lock); --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/net/tc_act/tc_defact.h 2005-02-06 15:03:05.000000000 -0500 @@ -0,0 +1,13 @@ +#ifndef __NET_TC_DEF_H +#define __NET_TC_DEF_H + +#include + +struct tcf_defact +{ + tca_gen(defact); + u32 datalen; + void *defdata; +}; + +#endif --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/linux/tc_act/tc_defact.h 2005-02-06 16:47:20.039209336 -0500 @@ -0,0 +1,21 @@ +#ifndef __LINUX_TC_DEF_H +#define __LINUX_TC_DEF_H + +#include + +struct tc_defact +{ + tc_gen; +}; + +enum +{ + TCA_DEF_UNSPEC, + TCA_DEF_TM, + TCA_DEF_PARMS, + TCA_DEF_DATA, + __TCA_DEF_MAX +}; +#define TCA_DEF_MAX (__TCA_DEF_MAX - 1) + +#endif --=-ib5mRFwAOsTDqQaOBM5K Content-Disposition: attachment; filename=p16 Content-Type: text/plain; name=p16; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/net/sched/simple.c 2005-02-06 15:55:57.000000000 -0500 @@ -0,0 +1,107 @@ +/* + * net/sched/simp.c Simple example of an action + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Jamal Hadi Salim (2005) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TCA_ACT_SIMP 22 + +/* XXX: Hide all these common elements under some macro + * probably +*/ +#include +#include + +/* use generic hash table with 8 buckets */ +#define MY_TAB_SIZE 8 +#define MY_TAB_MASK (MY_TAB_SIZE - 1) +static u32 idx_gen; +static struct tcf_defact *tcf_simp_ht[MY_TAB_SIZE]; +static DEFINE_RWLOCK(simp_lock); + +/* override the defaults */ +#define tcf_st tcf_defact +#define tc_st tc_defact +#define tcf_t_lock simp_lock +#define tcf_ht tcf_simp_ht + +#define CONFIG_NET_ACT_INIT 1 +#include +#include + +static int tcf_simp(struct sk_buff **pskb, struct tc_action *a) +{ + struct sk_buff *skb = *pskb; + struct tcf_defact *p = PRIV(a, defact); + + spin_lock(&p->lock); + p->tm.lastuse = jiffies; + p->bstats.bytes += skb->len; + p->bstats.packets++; + + /* print policy string followed by _ then packet count + * Example if this was the 3rd packet and the string was "hello" + * then it would look like "hello_3" (without quotes) + **/ + printk("simple: %s_%d\n", (char *)p->defdata, p->bstats.packets); + spin_unlock(&p->lock); + return p->action; +} + +static struct tc_action_ops act_simp_ops = { + .kind = "simple", + .type = TCA_ACT_SIMP, + .capab = TCA_CAP_NONE, + .owner = THIS_MODULE, + .act = tcf_simp, + tca_use_default_ops +}; + +MODULE_AUTHOR("Jamal Hadi Salim(2005)"); +MODULE_DESCRIPTION("Simple example action"); +MODULE_LICENSE("GPL"); + +static int __init simp_init_module(void) +{ + int ret = tcf_register_action(&act_simp_ops); + if (!ret) + printk("Simple TC action Loaded\n"); + return ret; +} + +static void __exit simp_cleanup_module(void) +{ + tcf_unregister_action(&act_simp_ops); +} + +module_init(simp_init_module); +module_exit(simp_cleanup_module); --=-ib5mRFwAOsTDqQaOBM5K-- From tgraf@suug.ch Sun Feb 6 14:24:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:24:34 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16MOUVR028339 for ; Sun, 6 Feb 2005 14:24:30 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6462FF; Sun, 6 Feb 2005 23:24:07 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id C709A1C0EA; Sun, 6 Feb 2005 23:24:50 +0100 (CET) Date: Sun, 6 Feb 2005 23:24:50 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-ID: <20050206222450.GX31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> <1107726133.1055.34.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107726133.1055.34.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1817 Lines: 35 * jamal <1107726133.1055.34.camel@jzny.localdomain> 2005-02-06 16:42 > On Sun, 2005-02-06 at 16:29, Thomas Graf wrote: > > > assign filters attached to it, i.e. listing filters based on > > parent == XX: && dev == %DEV will result in the filters being listed > > for both the qdisc and the class. I haven't found a fix that wouldn't > > break many scripts so if you have a good idea, go ahead. ;-> > > I cant say ive run into this one - mostly i attach filters to root. > Example script? See the post as reply to Patick's comment. You won't notice it in tc because it doesn't output complete trees. > BTW, cycles allow me to work on the eaction stuff today. So far > ive come to the conclusion that whats really needed to simplify > writting some actions is to just provide generic methods they > can use without them necessarily knowing details. I hope to test > later on, maybe write a simple action and its user apce piece, and post > patch. Sounds good, I've been mostly occupied by writing a API documentation to libnl and clean it up which almost doubled its usefulnes. There is still some effort to go into the core to make it easier to use for applications needing non blocking sockets or weird multiplexing. The traffic control part is slowly evoling but it take some more time to implement all the remaining qdiscs and classifiers. A bit of luck allowed me to provide a XML based external interface to other applications. It should be easy to extend it to make it bidirectional and get distributed configuration via some kind of existing or new protocol. The most problematic issue remaining is byte ordering. I guess I will end up having all the modules define their part of the grammar specifying the required byte order of every field and have a generic parser to do transformations as necessary. From tgraf@suug.ch Sun Feb 6 15:08:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 15:08:44 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16N8dfT030926 for ; Sun, 6 Feb 2005 15:08:40 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id EF922F; Mon, 7 Feb 2005 00:08:16 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id B52A81C0EA; Mon, 7 Feb 2005 00:08:59 +0100 (CET) Date: Mon, 7 Feb 2005 00:08:59 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: instead of eaction Message-ID: <20050206230859.GY31837@postel.suug.ch> References: <1107728020.1055.50.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107728020.1055.50.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1485 Lines: 47 * jamal <1107728020.1055.50.camel@jzny.localdomain> 2005-02-06 17:13 > > I think i am going to throw out the idea of eaction; instead > just provide some defaults. > First patch adds some defaults and second a quick simple example. > > I have to take off; but maybe i will get time to work on meta action as > well as csum action when i get back. > > Comments welcome > > cheers, > jamal > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > +++ 2611-rc3+bk3/include/net/act_generic.h 2005-02-06 15:55:36.000000000 -0500 > + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) > + return -EINVAL; > + > + if (tb[TCA_DEF_PARMS - 1] == NULL) > + return -EINVAL; Maybe check for tb[TCA_DEF_DATA - 1] == NULL here as well? > + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); RTA_PAYLOAD check for TCA_DEF_PARMS? > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > +++ 2611-rc3+bk3/net/sched/simple.c 2005-02-06 15:55:57.000000000 -0500 > @@ -0,0 +1,107 @@ > +#include > +#include > + > +/* use generic hash table with 8 buckets */ > +#define MY_TAB_SIZE 8 > +#define MY_TAB_MASK (MY_TAB_SIZE - 1) > +static u32 idx_gen; > +static struct tcf_defact *tcf_simp_ht[MY_TAB_SIZE]; > +static DEFINE_RWLOCK(simp_lock); I guess this is supposed to be tca_use_default_defines and move MY_TAB_SIZE before the includes? It looks pretty simple to use and makes up ematches quite well. Any userspace code alreay written? From kaber@trash.net Sun Feb 6 15:18:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 15:18:15 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16NIA62031739 for ; Sun, 6 Feb 2005 15:18:10 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1Cxvek-0004yA-RL; Mon, 07 Feb 2005 00:17:30 +0100 Message-ID: <4206A58A.9050909@trash.net> Date: Mon, 07 Feb 2005 00:17:30 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> <1107727330.1053.44.camel@jzny.localdomain> In-Reply-To: <1107727330.1053.44.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------070706000209020107090804" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2064 Lines: 78 This is a multi-part message in MIME format. --------------070706000209020107090804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit jamal wrote: >I should have caught that output missing divisor ;-> >Dave please apply Patricks version. Should probably apply cleanly on >2.4.x as well. > My last patch has a similar problem, new hash tables added with "u32 divisor .." are skipped while walking. This patch is better tested and should be fine. Applies to 2.4 and 2.6. Regards Patrick --------------070706000209020107090804 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/07 00:16:17+01:00 kaber@coreworks.de # [PKT_SCHED]: Fix u32 double listing # # Signed-off-by: Patrick McHardy # # net/sched/cls_u32.c # 2005/02/07 00:16:08+01:00 kaber@coreworks.de +5 -0 # [PKT_SCHED]: Fix u32 double listing # # Signed-off-by: Patrick McHardy # diff -Nru a/net/sched/cls_u32.c b/net/sched/cls_u32.c --- a/net/sched/cls_u32.c 2005-02-07 00:16:37 +01:00 +++ b/net/sched/cls_u32.c 2005-02-07 00:16:37 +01:00 @@ -91,6 +91,7 @@ { struct tc_u_hnode *next; u32 handle; + u32 prio; struct tc_u_common *tp_c; int refcnt; unsigned divisor; @@ -323,6 +324,7 @@ root_ht->divisor = 0; root_ht->refcnt++; root_ht->handle = tp_c ? gen_new_htid(tp_c) : 0x80000000; + root_ht->prio = tp->prio; if (tp_c == NULL) { tp_c = kmalloc(sizeof(*tp_c), GFP_KERNEL); @@ -587,6 +589,7 @@ ht->refcnt = 0; ht->divisor = divisor; ht->handle = handle; + ht->prio = tp->prio; ht->next = tp_c->hlist; tp_c->hlist = ht; *arg = (unsigned long)ht; @@ -703,6 +706,8 @@ return; for (ht = tp_c->hlist; ht; ht = ht->next) { + if (ht->prio != tp->prio) + continue; if (arg->count >= arg->skip) { if (arg->fn(tp, (unsigned long)ht, arg) < 0) { arg->stop = 1; --------------070706000209020107090804-- From davem@davemloft.net Sun Feb 6 22:12:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:12:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176Bxmq017939 for ; Sun, 6 Feb 2005 22:12:00 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy20J-0003uo-00; Sun, 06 Feb 2005 22:04:11 -0800 Date: Sun, 6 Feb 2005 22:04:11 -0800 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 PKT_SCHED]: ipt action: add back pskb_expand_head call Message-Id: <20050206220411.643e6afe.davem@davemloft.net> In-Reply-To: <4202E7BE.6050606@trash.net> References: <4202E7BE.6050606@trash.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 331 Lines: 9 On Fri, 04 Feb 2005 04:10:54 +0100 Patrick McHardy wrote: > Jamal asked me to add back the call to pskb_expand_head before 2.6.11. > This fixes a regression caused by my tc action cleanup patches, the > tc actions most not replace packets, so it must prevent netfilter from > doing so. Applied, thanks Patrick. From davem@davemloft.net Sun Feb 6 22:13:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:13:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176DVGo018177 for ; Sun, 6 Feb 2005 22:13:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy21m-0003v9-00; Sun, 06 Feb 2005 22:05:42 -0800 Date: Sun, 6 Feb 2005 22:05:42 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [IPV6]: Fix tunnel list locking in ip6_tunnel.c. Message-Id: <20050206220542.54fc6848.davem@davemloft.net> In-Reply-To: <20050205.015633.45798306.yoshfuji@linux-ipv6.org> References: <20050205.015633.45798306.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j176DVGo018177 X-archive-position: 1365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 348 Lines: 10 On Sat, 05 Feb 2005 01:56:33 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > We need to fix tunnel list locking in ip6_tunnel.c as well. > Noticed by jean-mickael guerin . > > Signed-off-by: Hideaki YOSHIFUJI Applied. Arigato gozaimasu, Yoshifuji-san. From davem@davemloft.net Sun Feb 6 22:17:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:17:09 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176H4t6018926 for ; Sun, 6 Feb 2005 22:17:04 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy25D-0003vd-00; Sun, 06 Feb 2005 22:09:15 -0800 Date: Sun, 6 Feb 2005 22:09:14 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: nistnet_user@yahoo.com, netem@lists.osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] netem: memory leak Message-Id: <20050206220914.457727db.davem@davemloft.net> In-Reply-To: <20050204153108.703ea71b@dxpl.pdx.osdl.net> References: <20050204231103.33325.qmail@web41510.mail.yahoo.com> <20050204153108.703ea71b@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 225 Lines: 7 On Fri, 4 Feb 2005 15:31:08 -0800 Stephen Hemminger wrote: > Good catch.. netem needs to free skb's that are dropped due to loss > simulation. Applied to 2.6.x and backported to 2.4.x, thanks Stephen. From davem@davemloft.net Sun Feb 6 22:33:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:33:30 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176XOVc019723 for ; Sun, 6 Feb 2005 22:33:25 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2Ko-000404-00; Sun, 06 Feb 2005 22:25:22 -0800 Date: Sun, 6 Feb 2005 22:25:22 -0800 From: "David S. Miller" To: Thomas Graf Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-Id: <20050206222522.21492f5c.davem@davemloft.net> In-Reply-To: <20050128230327.GV31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 863 Lines: 21 On Sat, 29 Jan 2005 00:03:27 +0100 Thomas Graf wrote: > NLMSG_GOODSIZE specifies a good default size for the skb tailroom > used in netlink messages when the size is unknown at the time of > the allocation. > > The current value doesn't make much sense anymore because > skb_shared_info isn't taken into account which means that > depending on the architecture NLMSG_GOOSIZE can exceed PAGE_SIZE > resulting in a waste of almost a complete page. > > Using SKB_MAXORDER solves this potential leak at the cost of > slightly smaller but safer sizes for some architectures. Applied, to 2.4.x and 2.6.x, thanks Thomas. This issue comes up again and again. In the most recent discussion I remember partaking in, I was trying to get it so that all the code paths would calculate the size they actually needed. Most, if not all, are able to do so. From davem@davemloft.net Sun Feb 6 22:35:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:35:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176Zldj020239 for ; Sun, 6 Feb 2005 22:35:48 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2Mb-00042a-00; Sun, 06 Feb 2005 22:27:13 -0800 Date: Sun, 6 Feb 2005 22:27:12 -0800 From: "David S. Miller" To: Thomas Graf Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-Id: <20050206222712.5519bc22.davem@davemloft.net> In-Reply-To: <20050128234022.GW31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050128234022.GW31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 892 Lines: 19 On Sat, 29 Jan 2005 00:40:22 +0100 Thomas Graf wrote: > > > Using SKB_MAXORDER solves this potential leak at the cost of > > > slightly smaller but safer sizes for some architectures. > > > > At first glance it's not clear which of sk_buff or skb_shared_info > > is bigger. So it might even end up being bigger :) > > skb_shared_info is 160 bytes and sk_buff is 196 bytes on my box (x86) > but that's not the point. We need to take SMP_CACHE_BYTES alignment into > account which tends to be quite big. The original NLMSG_GOODSIZE > results in 3908 on my box and gets pumped up to 4128 by skb_alloc > (ALIGN(...,SMP_CACHE_BYTES) + sizeof(struct skb_shared_info)) having > SMP_CACHE_BYTES at 128. Furthermore, it's not sk_buff that's ever the issue. The SKB data area size is where the skb_shared_info gets tacked onto, sk_buff's size is never added to this calculation. From mh+kernel-bugzilla@zugschlus.de Sun Feb 6 22:36:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:36:56 -0800 (PST) Received: from torres.int.l21.ma.zugschlus.de (Debian-exim@5301d.unt0.torres.l21.ma.zugschlus.de [217.151.83.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176apWd020602 for ; Sun, 6 Feb 2005 22:36:52 -0800 Received: from mh by torres.int.l21.ma.zugschlus.de with local (Exim 4.44) id 1Cy2Vo-0001Dh-3R; Mon, 07 Feb 2005 07:36:44 +0100 Date: Mon, 7 Feb 2005 07:36:44 +0100 From: Marc Haber To: jamal Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Message-ID: <20050207063644.GB4130@torres.l21.ma.zugschlus.de> References: <20050206122604.74a41796.akpm@osdl.org> <1107723057.1055.28.camel@jzny.localdomain> <20050206212500.GF17682@torres.l21.ma.zugschlus.de> <1107726307.1054.38.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107726307.1054.38.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mh+kernel-bugzilla@zugschlus.de Precedence: bulk X-list: netdev Content-Length: 630 Lines: 15 On Sun, Feb 06, 2005 at 04:45:08PM -0500, jamal wrote: > Remind me again: With user space pppoe if you have a web server that > people access from outside world, all packets go to user space and then > back to the kernel before hitting user space again? Yes, that's why it is called user space pppoed. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From davem@davemloft.net Sun Feb 6 22:40:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:41:00 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176euMI021331 for ; Sun, 6 Feb 2005 22:40:56 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2Rr-00042r-00; Sun, 06 Feb 2005 22:32:39 -0800 Date: Sun, 6 Feb 2005 22:32:39 -0800 From: "David S. Miller" To: Thomas Graf Cc: kuznet@ms2.inr.ac.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-Id: <20050206223239.5dc4e325.davem@davemloft.net> In-Reply-To: <20050129002701.GY31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050128234828.GA24868@yakov.inr.ac.ru> <20050129002128.GX31837@postel.suug.ch> <20050129002701.GY31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1097 Lines: 27 On Sat, 29 Jan 2005 01:27:01 +0100 Thomas Graf wrote: > * Thomas Graf <20050129002128.GX31837@postel.suug.ch> 2005-01-29 01:21 > > --- linux-2.6.11-rc2-bk4.orig/net/ipv4/tcp_input.c 2005-01-26 18:19:42.000000000 +0100 > > +++ linux-2.6.11-rc2-bk4/net/ipv4/tcp_input.c 2005-01-29 01:12:30.000000000 +0100 > > @@ -3760,8 +3760,7 @@ > > while (before(start, end)) { > > struct sk_buff *nskb; > > int header = skb_headroom(skb); > > - int copy = (PAGE_SIZE - sizeof(struct sk_buff) - > > - sizeof(struct skb_shared_info) - header - 31)&~15; > > + int copy = SKB_MAX_ORDER(header + 31, 0); > > > > /* Too big header? This can happen with IPv6. */ > > if (copy < 0) > > Sorry, this is incomplete, we should refetch copy via (skb->end - skb->head) after > allocating it. I have to think some more about this first. ;-) I don't understand, if we alloc_skb(copy) we are guarenteed to have "copy" bytes available in the SKB data area. This transformation to SKB_MAX_ORDER() (with the "+ 31" removed as per Alexey's reply), seems perfectly fine to me. Isn't it? From davem@davemloft.net Sun Feb 6 22:44:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:44:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176ibGL021849 for ; Sun, 6 Feb 2005 22:44:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2Vq-00043L-00; Sun, 06 Feb 2005 22:36:46 -0800 Date: Sun, 6 Feb 2005 22:36:46 -0800 From: "David S. Miller" To: Patrick McHardy Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-Id: <20050206223646.239c0d77.davem@davemloft.net> In-Reply-To: <4206A58A.9050909@trash.net> References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> <1107727330.1053.44.camel@jzny.localdomain> <4206A58A.9050909@trash.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 578 Lines: 16 On Mon, 07 Feb 2005 00:17:30 +0100 Patrick McHardy wrote: > jamal wrote: > > >I should have caught that output missing divisor ;-> > >Dave please apply Patricks version. Should probably apply cleanly on > >2.4.x as well. > > > My last patch has a similar problem, new hash tables added with > "u32 divisor .." are skipped while walking. This patch is better > tested and should be fine. Applies to 2.4 and 2.6. After seeing 4+ revisions of the same bug fix on the same day, let's let this sink for another day to make sure it's really the final version :-) From davem@davemloft.net Sun Feb 6 22:51:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:51:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176pVTI022436 for ; Sun, 6 Feb 2005 22:51:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2cK-00046R-00; Sun, 06 Feb 2005 22:43:28 -0800 Date: Sun, 6 Feb 2005 22:43:27 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3 of 3][ATM]: [zatm] replace sleep_on() with wait_event() Message-Id: <20050206224327.5639c502.davem@davemloft.net> In-Reply-To: <200502041823.j14INqY4020685@ginger.cmf.nrl.navy.mil> References: <200502041823.j14INqY4020685@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 37 Lines: 2 All 3 patches applied, thanks Chas. From davem@davemloft.net Sun Feb 6 22:53:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 22:53:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j176rWj6022951 for ; Sun, 6 Feb 2005 22:53:32 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cy2eS-00047A-00; Sun, 06 Feb 2005 22:45:40 -0800 Date: Sun, 6 Feb 2005 22:45:40 -0800 From: "David S. Miller" To: Matthew Wilcox Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ipconfig invokes undefined behaviour Message-Id: <20050206224540.5b5dc590.davem@davemloft.net> In-Reply-To: <20050206044744.GO20386@parcelfarce.linux.theplanet.co.uk> References: <20050206044744.GO20386@parcelfarce.linux.theplanet.co.uk> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 327 Lines: 9 On Sun, 6 Feb 2005 04:47:44 +0000 Matthew Wilcox wrote: > strcpy is undefined if src and dest overlap. That's clearly possible > here with a sufficiently deep path on the server. Use memmove instead. > > Signed-off-by: Matthew Wilcox Thanks a lot Matthew, applied to both 2.4.x and 2.6.x From duncan.sands@math.u-psud.fr Mon Feb 7 01:03:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 01:03:18 -0800 (PST) Received: from pbaldrick.hd.free.fr (massena-4-82-67-197-146.fbx.proxad.net [82.67.197.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1793BDB030217 for ; Mon, 7 Feb 2005 01:03:12 -0800 Received: by pbaldrick.hd.free.fr (Postfix, from userid 500) id 0CC46355D1A; Mon, 7 Feb 2005 10:03:09 +0100 (CET) From: Duncan Sands To: usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Date: Mon, 7 Feb 2005 10:03:08 +0100 User-Agent: KMail/1.7.1 Cc: Roman Kagan , chas williams - CONTRACTOR , netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net References: <20050121085123.GA2471@katya> <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> <20050204201327.GA2439@katya> In-Reply-To: <20050204201327.GA2439@katya> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502071003.09211.duncan.sands@math.u-psud.fr> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: duncan.sands@math.u-psud.fr Precedence: bulk X-list: netdev Content-Length: 1726 Lines: 31 Hi Roman, > Besides, I've encountered a problem with hotplug being called from > atm_dev_register: the device actually becomes usable only when the > driver sets .dev_data, which may happen after hotplug has been called. > E.g. if I call br2684ctl in my hotplug script, and it happens to attempt > to open a socket on the device before .dev_data is set, br2684ctl fails > (rather disgracefully BTW, forgetting to cleanup nasX). I had to work > around it by adding a sleep for a couple of seconds to the hotplug > script, and hoping that was enough for the driver to complete > initializing atm_dev. I suspect the only way to fix it is to split the > atm_dev initialization into two stages, allocation and registration, as > it is done for net_device. this is a long-standing problem with ATM device initialisation: the device becomes available before the struct atm_dev is initialised! In theory a driver's ATM methods could be called the moment atm_dev_register returns, and before the driver has had a chance to fill in any fields. That's why all the ATM methods in the speedtouch driver check atm_dev->dev_data, and return without doing anything if it is NULL: atm_dev->dev_data is only set to a non-NULL value when the struct atm_dev has been fully initialised (this is the reason for the memory barrier by the way). When you say "the device actually becomes usable only when the driver sets .dev_data", I think that's a property of the speedtouch driver only. With other drivers it is probably worse: you get to open a connection even though the structure is not initialized, and boom! In the past, this race was only a theoretical problem for SMP machines; but with your patch it hits everyone. Ciao, Duncan. From didier@barvaux.org Mon Feb 7 01:26:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 01:26:37 -0800 (PST) Received: from mail.b2i-toulouse.com (host.97.67.23.62.rev.coltfrance.com [62.23.67.97]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j179QTPl031299 for ; Mon, 7 Feb 2005 01:26:30 -0800 Received: from catherine.b2i-toulouse.com ([62.23.67.99]) by mail.b2i-toulouse.com (8.12.5/8.12.5) with SMTP id j179QQI2023329 for ; Mon, 7 Feb 2005 10:26:26 +0100 Date: Mon, 7 Feb 2005 10:26:32 +0100 From: Didier Barvaux To: netdev@oss.sgi.com Subject: TAHI Conformance Test Message-Id: <20050207102632.5bdffee0.didier@barvaux.org> X-Mailer: Sylpheed version 0.9.99 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: didier@barvaux.org Precedence: bulk X-list: netdev Content-Length: 840 Lines: 19 Hello, I'm searching for information about the current status of IPv6 in the Linux 2.6/2.4 vanilla kernels. Unfortunately, I have not found up-to-date data. I have found Peter Bieringer's 'IPv6 & Linux' page [1] and some quite old TAHI Conformance Test's results on kernel 2.6.1 [2] from the USAGI project. As you can see, information I have found are quite outdated. So, have someone more up-to-date data ? I would be very interested in reading some TAHI Conformance Test against the latest 2.6/2.4 vanilla kernels, or in reading some other document like Peter Bieringer's page. Thank you in advance. Regards, Didier Barvaux [1] "IPv6 & Linux - Current Status" http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html [2] "TAHI Conformance Test Report" http://www.linux-ipv6.org/tahitest/200401/summary-index.html From rkagan@mail.ru Mon Feb 7 01:45:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 01:45:26 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j179jLWl032440 for ; Mon, 7 Feb 2005 01:45:21 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id D6E954DFB1E; Mon, 7 Feb 2005 12:45:10 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.220.74] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 398395675; Mon, 07 Feb 2005 12:45:10 +0300 Date: Mon, 7 Feb 2005 12:45:18 +0300 From: Roman Kagan To: usbatm@lists.infradead.org, netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050207094517.GC2360@katya> Mail-Followup-To: Roman Kagan , usbatm@lists.infradead.org, netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net References: <20050121085123.GA2471@katya> <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> <20050204201327.GA2439@katya> <200502071003.09211.duncan.sands@math.u-psud.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502071003.09211.duncan.sands@math.u-psud.fr> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 629 Lines: 16 On Mon, Feb 07, 2005 at 10:03:08AM +0100, Duncan Sands wrote: > this is a long-standing problem with ATM device initialisation: the device > becomes available before the struct atm_dev is initialised! > [...] > In the past, this race was only a theoretical > problem for SMP machines; but with your patch it hits everyone. Indeed. OTOH at a first glance splitting the ATM device initialisation API into allocation and registration doesn't look a terribly difficult thing, it would require fairly local changes in the drivers. Unless Chas' move to struct net_device is alredy knocking on the door, of course. Cheers, Roman. From yoshfuji@linux-ipv6.org Mon Feb 7 02:40:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 02:40:41 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17AeZtv003790 for ; Mon, 7 Feb 2005 02:40:35 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CFD1533CC2; Mon, 7 Feb 2005 19:41:36 +0900 (JST) Date: Mon, 07 Feb 2005 19:41:36 +0900 (JST) Message-Id: <20050207.194136.130656563.yoshfuji@linux-ipv6.org> To: didier@barvaux.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: TAHI Conformance Test From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050207102553.28a46fcd.didier@barvaux.org> References: <20050207102553.28a46fcd.didier@barvaux.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1377 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: 1312 Lines: 32 Please do not multipost... In article <20050207102553.28a46fcd.didier@barvaux.org> (at Mon, 7 Feb 2005 10:25:53 +0100), Didier Barvaux says: > I'm searching for information about the current status of IPv6 in the Linux 2.6/2.4 vanilla kernels. Unfortunately, I have not found up-to-date data. > > I have found Peter Bieringer's 'IPv6 & Linux' page [1] and some quite old TAHI Conformance Test's results on kernel 2.6.1 [2] from the USAGI project. As you can see, information I have found are quite outdated. > > So, have someone more up-to-date data ? Well, we haven't tested vanilla linux-2.4.x recently. However, linux-2.6.11-rc2 w/ usagi-tools (userspace daemon etc.), acting as host and/or router, passed IPv6 Ready Logo [1] Phase 1 Self-Test, which is similar to CT. (Note: usagi-linux24 and usagi-linux26 passed it, too.) And, we are trying passing Phase 2 Self-Test as well. My private tree already passed it, and patches will soon be available (in linux-2.6.12 timeframe). I think linux-2.6.11-rc2 w/ usagi-tools can pass TAHI CT; we will test later. We may try to backport changes to 2.4.x. I hope this helps. Thanks. [1] http://www.ipv6ready.org -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From tgraf@suug.ch Mon Feb 7 05:28:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 05:28:21 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17DSAdc020023 for ; Mon, 7 Feb 2005 05:28:12 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 33A80F; Mon, 7 Feb 2005 14:27:47 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 55F3D1C0EA; Mon, 7 Feb 2005 14:28:30 +0100 (CET) Date: Mon, 7 Feb 2005 14:28:30 +0100 From: Thomas Graf To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-ID: <20050207132830.GZ31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050128234828.GA24868@yakov.inr.ac.ru> <20050129002128.GX31837@postel.suug.ch> <20050129002701.GY31837@postel.suug.ch> <20050206223239.5dc4e325.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206223239.5dc4e325.davem@davemloft.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 796 Lines: 19 > > > struct sk_buff *nskb; > > > int header = skb_headroom(skb); > > > - int copy = (PAGE_SIZE - sizeof(struct sk_buff) - > > > - sizeof(struct skb_shared_info) - header - 31)&~15; > > > + int copy = SKB_MAX_ORDER(header + 31, 0); > > > > > > /* Too big header? This can happen with IPv6. */ > > > if (copy < 0) > > > > Sorry, this is incomplete, we should refetch copy via (skb->end - skb->head) after > > allocating it. I have to think some more about this first. ;-) > > I don't understand, if we alloc_skb(copy) we are guarenteed to have > "copy" bytes available in the SKB data area. Yes but don't we waste space in the headroom of the new skb iff the headroom of the original skb is no aligned to SKB_DATA_ALIGN? I'll post a new patch without the anyway though. From hadi@cyberus.ca Mon Feb 7 05:49:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 05:49:44 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17Dnbi8021343 for ; Mon, 7 Feb 2005 05:49:38 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1Cy9Gc-0001uS-Rv for netdev@oss.sgi.com; Mon, 07 Feb 2005 06:49:30 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cy9Gd-0007Ic-AK; Mon, 07 Feb 2005 08:49:31 -0500 Subject: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Patrick McHardy , netdev@oss.sgi.com In-Reply-To: <20050206223646.239c0d77.davem@davemloft.net> References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> <1107727330.1053.44.camel@jzny.localdomain> <4206A58A.9050909@trash.net> <20050206223646.239c0d77.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107784168.1054.58.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Feb 2005 08:49:29 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1379 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: 1161 Lines: 32 I believe the last patch is correct. I can explain the many patches ;-> Call it the excitement to fix it if you may. Its a problem that has existed for many years and many users have complained about it but noone has really zoned on the cause fatale. The 90% of it was really the patch i posted which zoned on it - for years theory was the fix was in tc(user space). Patricks reincarnation got it to 95% and his second one got it to 100%. IMO: Push it in, let some user whine. cheers, jamal On Mon, 2005-02-07 at 01:36, David S. Miller wrote: > On Mon, 07 Feb 2005 00:17:30 +0100 > Patrick McHardy wrote: > > > jamal wrote: > > > > >I should have caught that output missing divisor ;-> > > >Dave please apply Patricks version. Should probably apply cleanly on > > >2.4.x as well. > > > > > My last patch has a similar problem, new hash tables added with > > "u32 divisor .." are skipped while walking. This patch is better > > tested and should be fine. Applies to 2.4 and 2.6. > > After seeing 4+ revisions of the same bug fix on the same day, > let's let this sink for another day to make sure it's really > the final version :-) > From hadi@cyberus.ca Mon Feb 7 05:57:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 05:57:16 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17Dv971022005 for ; Mon, 7 Feb 2005 05:57:09 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1Cy9Nu-0005Si-Qe for netdev@oss.sgi.com; Mon, 07 Feb 2005 06:57:02 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cy9Nv-0000B1-K9; Mon, 07 Feb 2005 08:57:03 -0500 Subject: Re: instead of eaction From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050206230859.GY31837@postel.suug.ch> References: <1107728020.1055.50.camel@jzny.localdomain> <20050206230859.GY31837@postel.suug.ch> Content-Type: multipart/mixed; boundary="=-IRTkFurCO5W8ODvYvTMn" Organization: jamalopolous Message-Id: <1107784621.1053.66.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Feb 2005 08:57:01 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1380 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: 4737 Lines: 198 --=-IRTkFurCO5W8ODvYvTMn Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-02-06 at 18:08, Thomas Graf wrote: > > > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > > +++ 2611-rc3+bk3/include/net/act_generic.h 2005-02-06 15:55:36.000000000 -0500 > > + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) > > + return -EINVAL; > > + > > + if (tb[TCA_DEF_PARMS - 1] == NULL) > > + return -EINVAL; > > Maybe check for tb[TCA_DEF_DATA - 1] == NULL here as well? > Good point; i will check for all > > + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); > > RTA_PAYLOAD check for TCA_DEF_PARMS? > sure > > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > > +++ 2611-rc3+bk3/net/sched/simple.c 2005-02-06 15:55:57.000000000 -0500 > > @@ -0,0 +1,107 @@ > > > +#include > > +#include > > + > > +/* use generic hash table with 8 buckets */ > > +#define MY_TAB_SIZE 8 > > +#define MY_TAB_MASK (MY_TAB_SIZE - 1) > > +static u32 idx_gen; > > +static struct tcf_defact *tcf_simp_ht[MY_TAB_SIZE]; > > +static DEFINE_RWLOCK(simp_lock); > > I guess this is supposed to be tca_use_default_defines > and move MY_TAB_SIZE before the includes? This is a tricky one; maybe i am playing too many macro tricks ;-> Theres some dependencies - need to think a little > It looks pretty simple to use and makes up ematches quite well. Any > userspace code alreay written? User space could be simplified as well; attached is what i used to test simple action. Theres a _lot_ of common code there as well. I am also bgining to work on the checksum action; i will then do the meta action. cheers, jamal --=-IRTkFurCO5W8ODvYvTMn Content-Disposition: attachment; filename=m_simple.c Content-Type: text/x-c; name=m_simple.c; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit /* * m_defact.c simple example action module * * This program is free software; you can distribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. * * Authors: J Hadi Salim (hadi@cyberus.ca) * */ #include #include #include #include #include #include #include #include #include #include "utils.h" #include "tc_util.h" #include static void explain(void) { fprintf(stderr, "Usage: ... simp index [INDEX]\n"); fprintf(stderr, "Where: ACT_STRING := a simple string (not exceeding 16 chars" "INDEX := index value used\n"); } #define usage() return(-1) #ifndef ANAMSIZ #define ANAMSIZ 16 #endif int parse_simple(struct action_util *a, int *argc_p, char ***argv_p, int tca_id, struct nlmsghdr *n) { int argc = *argc_p; char **argv = *argv_p; struct tc_defact *p; char k[ANAMSIZ]; struct rtattr *tail; if (argc < 2) return -1; p = malloc(sizeof(*p)); memset(p, 0, sizeof(*p)); memset (&k,0,ANAMSIZ); NEXT_ARG(); strncpy(k, *argv, sizeof(k)-1); argc--; argv++; if (argc && matches(*argv, "index") == 0) { NEXT_ARG(); if (get_u32(&p->index, *argv, 10)) { fprintf(stderr, "Illegal \"index\"\n"); return -1; } argc--; argv++; } p->action = TC_ACT_PIPE; tail = (struct rtattr *) (((void *) n) + NLMSG_ALIGN(n->nlmsg_len)); addattr_l(n, MAX_MSG, tca_id, NULL, 0); addattr_l(n, MAX_MSG, TCA_DEF_PARMS, p, sizeof(*p)); addattr_l(n, MAX_MSG, TCA_DEF_DATA, k, strlen(k)+1); tail->rta_len = (((void *) n) + NLMSG_ALIGN(n->nlmsg_len)) - (void *) tail; *argc_p = argc; *argv_p = argv; return 0; } int print_simple(struct action_util *au,FILE * f, struct rtattr *arg) { SPRINT_BUF(b1); struct tc_defact *p = NULL; struct rtattr *tb[TCA_DEF_MAX + 1]; char *str; if (arg == NULL) return -1; memset(tb, 0, sizeof (tb)); parse_rtattr(tb, TCA_DEF_MAX, RTA_DATA(arg), RTA_PAYLOAD(arg)); if (tb[TCA_DEF_PARMS] == NULL) { fprintf(f, "[NULL simple parameters]"); return -1; } p = RTA_DATA(tb[TCA_DEF_PARMS]); fprintf(f, "simple action %s", action_n2a(p->action, b1, sizeof (b1))); fprintf(f, "\n\t index %d ref %d bind %d",p->index, p->refcnt, p->bindcnt); if (show_stats) { if (tb[TCA_DEF_TM]) { struct tcf_t *tm = RTA_DATA(tb[TCA_DEF_TM]); print_tm(f,tm); } } str = RTA_DATA(tb[TCA_DEF_DATA]); if (!strlen(str)) { fprintf(f, "\n\t EMPTY string!!!\n"); } else { fprintf(f, "\n\t DATA: <%s>\n",str); } fprintf(f, "\n "); return 0; } struct action_util simple_action_util = { .id = "simple", .parse_aopt = parse_simple, .print_aopt = print_simple, }; --=-IRTkFurCO5W8ODvYvTMn-- From hadi@cyberus.ca Mon Feb 7 06:18:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 06:18:40 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17EIYKs023266 for ; Mon, 7 Feb 2005 06:18:35 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1Cy9id-000746-VW for netdev@oss.sgi.com; Mon, 07 Feb 2005 07:18:27 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cy9if-0003Is-4C; Mon, 07 Feb 2005 09:18:29 -0500 Subject: Re: instead of eaction From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <1107784621.1053.66.camel@jzny.localdomain> References: <1107728020.1055.50.camel@jzny.localdomain> <20050206230859.GY31837@postel.suug.ch> <1107784621.1053.66.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-dP9GzXAqk/odGNwnK08+" Organization: jamalopolous Message-Id: <1107785906.1054.81.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Feb 2005 09:18:27 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1381 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: 7063 Lines: 269 --=-dP9GzXAqk/odGNwnK08+ Content-Type: text/plain Content-Transfer-Encoding: 7bit I havent finished this and wont touch it for a few days, but should give you a general view of the csum action. It is slightly more complex in that it needs to at least check for the data passed from user space to avoid doing it in the fast/data path and and so overwrittes the default ->init(). Only thing ive done so far is to compile this. Still a lot of validation, cleanup and meat to be added. Theres a lot that could be done such as incremental checksums, for now this is simple and should work albeit a little perfomance squeak here and there. cheers, jamal --=-dP9GzXAqk/odGNwnK08+ Content-Disposition: attachment; filename=p1 Content-Type: text/plain; name=p1; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- /dev/null 2005-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/net/tc_act/tc_csuma.h 2005-02-07 08:39:52.594700248 -0500 @@ -0,0 +1,28 @@ +#ifndef __NET_TCA_CSUMA_H +#define __NET_TCA_CSUMA_H + +#include +#include + +struct tcf_csum { + u16 ctype; + u16 atype; + u32 vldact; + u32 invact; +}; + +enum +{ + CSUMA_INVALID = -1, + CSUMA_IPVLD, + CSUMA_IPSET, + CSUMA_TCPVLD, + CSUMA_TCPSET, + CSUMA_UDPVLD, + CSUMA_UDPSET, + __CSUMA_MAX +}; +#define CSUMA_MAX (__CSUMA_MAX - 1) + + +#endif --- /dev/null 2005-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/net/sched/csumact.c 2005-02-07 08:37:33.000000000 -0500 @@ -0,0 +1,208 @@ +/* + * net/sched/csumact.c Checksum validate+recompute action + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Jamal Hadi Salim (2005) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define TCA_ACT_CSUMA 23 + +#define MY_TAB_SIZE 8 +#define MY_TAB_MASK (MY_TAB_SIZE - 1) +#include +#include +#include + +static u32 idx_gen; +static struct tcf_defact *tcf_csuma_ht[MY_TAB_SIZE]; +static DEFINE_RWLOCK(csuma_lock); + +/* override the defaults */ +#define tcf_st tcf_defact +#define tc_st tc_defact +#define tcf_t_lock csuma_lock +#define tcf_ht tcf_csuma_ht + +#define CONFIG_NET_ACT_INIT 1 +#include +#include + +/* the diffferent csum computers and validators */ +/* + * XXXX: There is a lot of optimizations that could be + * done here. each valid and set could share code and + * all the tcp/udp really should be sharing the same code + * base +*/ +static int ipvalid(struct tcf_csum *p, struct sk_buff *skb) +{ + struct iphdr *iph = skb->nh.iph; + if (ip_fast_csum((unsigned char *)iph, iph->ihl)) + return p->invact; + return p->vldact; +} + +/* XXXX: the usual rules for trampling on pkts must be followed */ +static int ipset(struct tcf_csum *p, struct sk_buff *skb) +{ + struct iphdr *iph = skb->nh.iph; + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + return p->vldact; +} + +static int tcpvalid(struct tcf_csum *p, struct sk_buff *skb) +{ + struct iphdr *iph = skb->nh.iph; + unsigned int tcphoff = skb->nh.iph->ihl * 4; + unsigned int tcplen = skb->len - tcphoff; + + skb->csum = skb_checksum(skb, tcphoff, tcplen, 0); + + if (csum_tcpudp_magic(iph->saddr, iph->daddr, tcplen, IPPROTO_TCP, skb->csum)) + return p->invact; + + return p->vldact; +} + +/* XXXX: the usual rules for trampling on pkts must be followed */ +static int tcpset(struct tcf_csum *p, struct sk_buff *skb) +{ + struct tcphdr *tcph = skb->h.th; + struct iphdr *iph = skb->nh.iph; + unsigned int tcphoff = skb->nh.iph->ihl * 4; + unsigned int tcplen = skb->len - tcphoff; + + tcph->check = 0; + skb->csum = skb_checksum(skb, tcphoff, tcplen, 0); + + tcph->check = csum_tcpudp_magic(iph->saddr, iph->daddr, + tcplen, IPPROTO_TCP, skb->csum); + + return p->vldact; +} + +static int udpvalid(struct tcf_csum *p, struct sk_buff *skb) +{ + struct iphdr *iph = skb->nh.iph; + unsigned int udphoff = skb->nh.iph->ihl * 4; + unsigned int udplen = skb->len - udphoff; + + skb->csum = skb_checksum(skb, udphoff, udplen, 0); + + if (csum_tcpudp_magic(iph->saddr, iph->daddr, udplen, IPPROTO_UDP, skb->csum)) + return p->invact; + + return p->vldact; +} + +/* XXXX: the usual rules for trampling on pkts must be followed */ +static int udpset(struct tcf_csum *p, struct sk_buff *skb) +{ + struct udphdr *udph = skb->h.uh; + struct iphdr *iph = skb->nh.iph; + unsigned int udphoff = skb->nh.iph->ihl * 4; + unsigned int udplen = skb->len - udphoff; + + udph->check = 0; + skb->csum = skb_checksum(skb, udphoff, udplen, 0); + + udph->check = csum_tcpudp_magic(iph->saddr, iph->daddr, + udplen, IPPROTO_UDP, skb->csum); + + return p->vldact; +} + +typedef int (*f_csum)(struct tcf_csum *p, struct sk_buff *skb); +static f_csum csumfuncs[CSUMA_MAX + 1] = {ipvalid,ipset,tcpvalid,tcpset,udpvalid,udpset }; + +static int tcf_csuma(struct sk_buff **pskb, struct tc_action *a) +{ + int ret; + struct sk_buff *skb = *pskb; + struct tcf_defact *p = PRIV(a, defact); + struct tcf_csum *c = p->defdata; + + spin_lock(&p->lock); + p->tm.lastuse = jiffies; + p->bstats.bytes += skb->len; + p->bstats.packets++; + ret = csumfuncs[c->ctype](c, skb); + spin_unlock(&p->lock); + return ret; +} + +static inline int +tcf_csuma_init(struct rtattr *rta, struct rtattr *est, + struct tc_action *a, int ovr, int bind) +{ + /* cutnpaste tcf_defact_init and check that + * the ctype passed is valid */ + return 0; +} + +static struct tc_action_ops act_csuma_ops = { + .kind = "csumact", + .type = TCA_ACT_CSUMA, + .capab = TCA_CAP_NONE, + .owner = THIS_MODULE, + .act = tcf_csuma, + tca_use_default_ops +}; + +MODULE_AUTHOR("Jamal Hadi Salim(2005)"); +MODULE_DESCRIPTION("checksum action"); +MODULE_LICENSE("GPL"); + +static int __init csuma_init_module(void) +{ + int ret = tcf_register_action(&act_csuma_ops); + if (!ret) { + printk("Simple TC action Loaded\n"); + /* overwrite the init */ + act_csuma_ops.init = tcf_csuma_init; + } + return ret; +} + +static void __exit csuma_cleanup_module(void) +{ + tcf_unregister_action(&act_csuma_ops); +} + +module_init(csuma_init_module); +module_exit(csuma_cleanup_module); --=-dP9GzXAqk/odGNwnK08+-- From tgraf@suug.ch Mon Feb 7 06:27:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 06:27:29 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17ERM8Z023984 for ; Mon, 7 Feb 2005 06:27:22 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 01E78F; Mon, 7 Feb 2005 15:26:58 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 212331C0EA; Mon, 7 Feb 2005 15:27:42 +0100 (CET) Date: Mon, 7 Feb 2005 15:27:42 +0100 From: Thomas Graf To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: [PATCH] NET: Fix calculation for collapsed skb size Message-ID: <20050207142742.GA31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050128234828.GA24868@yakov.inr.ac.ru> <20050129002128.GX31837@postel.suug.ch> <20050129002701.GY31837@postel.suug.ch> <20050206223239.5dc4e325.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206223239.5dc4e325.davem@davemloft.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 636 Lines: 18 patch also applies to 2.4 with some fuzz. Noticed by Denis V. Lunev Signed-off-by: Thomas Graf --- linux-2.6.11-rc3-bk3.orig/net/ipv4/tcp_input.c 2005-02-07 09:47:02.000000000 -0500 +++ linux-2.6.11-rc3-bk3/net/ipv4/tcp_input.c 2005-02-07 09:50:20.000000000 -0500 @@ -3760,8 +3760,7 @@ while (before(start, end)) { struct sk_buff *nskb; int header = skb_headroom(skb); - int copy = (PAGE_SIZE - sizeof(struct sk_buff) - - sizeof(struct skb_shared_info) - header - 31)&~15; + int copy = SKB_MAX_ORDER(header, 0); /* Too big header? This can happen with IPv6. */ if (copy < 0) From mostrows@speakeasy.net Mon Feb 7 08:18:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 08:18:30 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17GINDE028846 for ; Mon, 7 Feb 2005 08:18:24 -0800 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j17GI4a411794; Mon, 7 Feb 2005 11:18:04 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j17GI3f52384; Mon, 7 Feb 2005 11:18:03 -0500 Received: from brick (brick.watson.ibm.com [9.2.216.48]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j17GI1s33112; Mon, 7 Feb 2005 11:18:02 -0500 Subject: Re: [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses From: Michal Ostrowski To: Arnaldo Carvalho de Melo Cc: Networking Team , mh+kernel-bugzilla@zugschlus.de In-Reply-To: <420683CB.2010205@conectiva.com.br> References: <200502061207.j16C7UOB009882@fire-1.osdl.org> <420683CB.2010205@conectiva.com.br> Content-Type: text/plain Date: Mon, 07 Feb 2005 11:18:32 -0500 Message-Id: <1107793112.15984.238.camel@brick.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mostrows@speakeasy.net Precedence: bulk X-list: netdev Content-Length: 3409 Lines: 85 I'm very hesitant to put something like this into the PPPoE code, though I could if the demand for it is strong enough. I think the proper solution is something that should be implemented primarily in the generic networking code. The right approach IMO is to do something similar to IP-aliasing; that is to permit an alternate instance of the interface to exist with the desired MAC address. Currently one can use IP-aliasing to do this at the IP level: ifconfig eth0 10.10.10.10 up .... ifconfig eth0:1 10.10.10.11 up .... Likewise, I'd propose ethernet aliasing ifconfig eth0 10.10.10.10 up .... #Use native address ifconfig eth0.A hw ether AA:BB:CC:DD:EE:FF # Create mac-addr alias dev Given something like this, PPPoE over eth0.A would just work using the MAC address bound to eth0.A. The virtues of such a scheme are that it eliminates the need for management code in PPPoE as PPPoE is not responsible for implementing the binding of the new MAC address. The PPPoE code should not be in the business of putting devices into promiscuous mode, and then tracking whether or not they should be taken out of promiscuous mode. This scheme also allows for the possibility that hardware devices themselves may support multiple MAC addresses (if they can be programmed to do so). -- Michal Ostrowski On Sun, 2005-02-06 at 18:53 -0200, Arnaldo Carvalho de Melo wrote: > bugme-daemon@osdl.org escreveu: > > http://bugme.osdl.org/show_bug.cgi?id=4177 > > > > Summary: Please consider adding possibility to have multiple > > PPPoE sessions with different MAC addresses > > Kernel Version: 2.6.current, 2.4.current > > Status: NEW > > Severity: low > > Owner: acme@conectiva.com.br > > Submitter: mh+kernel-bugzilla@zugschlus.de > > > > > > This wishlist item is mostly relevant to German users. In > > Germany, Deutsche Telekom has a near monopoly regarding DSL > > connections to residential homes. They are, however, required, to > > resell their network to other ISPs which has led to a rather > > interesting combination of Internet tariffs and feature sets available > > via Deutsche Telekom T-DSL connections. > > > > Technical Basis for the T-DSL customer interface is PPPoE over a > > bridged ATM session, so it is technically possible to have multiple > > PPPoE sessions on the same line, allowing concurrent use of more than > > a single ISP which might be interesting with special interest services > > like streaming, fixed IP address and/or flat rate. > > > > However, Deutsche Telekom technically forbids multiple PPPoE sessions > > originating from a single MAC address, so one needs multiple network > > interfaces to originate the PPPoE sessions from. > > > > Sven Geggus has a patch against rp-pppoed, which allows to fake the > > sending MAC address for additional PPPoE sessions, circumventing the > > artificially introduced limitation of the T-DSL connection. The patch > > is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > > > > Please consider adding that possibility to the kernel PPPoE code as well. > > > > Greetings > > Marc > > > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > > > > > -- Michal Ostrowski From greearb@candelatech.com Mon Feb 7 08:49:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 08:50:02 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17GntPp001094 for ; Mon, 7 Feb 2005 08:49:55 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j17H9QLH003988; Mon, 7 Feb 2005 09:09:26 -0800 Message-ID: <42079C2A.4010006@candelatech.com> Date: Mon, 07 Feb 2005 08:49:46 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Ostrowski CC: Arnaldo Carvalho de Melo , Networking Team , mh+kernel-bugzilla@zugschlus.de Subject: Re: [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses References: <200502061207.j16C7UOB009882@fire-1.osdl.org> <420683CB.2010205@conectiva.com.br> <1107793112.15984.238.camel@brick.watson.ibm.com> In-Reply-To: <1107793112.15984.238.camel@brick.watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1384 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: 2135 Lines: 52 Michal Ostrowski wrote: > I'm very hesitant to put something like this into the PPPoE code, though > I could if the demand for it is strong enough. I think the proper > solution is something that should be implemented primarily in the > generic networking code. > > The right approach IMO is to do something similar to IP-aliasing; that > is to permit an alternate instance of the interface to exist with the > desired MAC address. > > Currently one can use IP-aliasing to do this at the IP level: > > ifconfig eth0 10.10.10.10 up .... > ifconfig eth0:1 10.10.10.11 up .... > > Likewise, I'd propose ethernet aliasing > > ifconfig eth0 10.10.10.10 up .... #Use native address > ifconfig eth0.A hw ether AA:BB:CC:DD:EE:FF # Create mac-addr alias dev > > > Given something like this, PPPoE over eth0.A would just work using the > MAC address bound to eth0.A. > > The virtues of such a scheme are that it eliminates the need for > management code in PPPoE as PPPoE is not responsible for implementing > the binding of the new MAC address. The PPPoE code should not be in the > business of putting devices into promiscuous mode, and then tracking > whether or not they should be taken out of promiscuous mode. > > This scheme also allows for the possibility that hardware devices > themselves may support multiple MAC addresses (if they can be programmed > to do so). I have a MAC-VLAN patch that already does this. It's based on work by Alex Zeffertt, but has been considerably hacked by me so he no should get no blame for what I have done :) MAC-VLANs allow one to create a virtual ethernet interface and packets are routed to it based on the source (or destination) MAC address. To user-space, each MAC-VLAN looks just like an ethernet interface. It is all glommed into my big networking patch, but if there is serious interest, then I will split it out. It does require a hook near the bridging hook in dev.c, and in the past, DaveM has not liked me putting hooks there, so he may not accept this anyway... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From mgalgoci@redhat.com Mon Feb 7 10:25:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 10:25:30 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17IPQbd007259 for ; Mon, 7 Feb 2005 10:25:26 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j17IPP5T007489 for ; Mon, 7 Feb 2005 13:25:25 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j17IPPO10778 for ; Mon, 7 Feb 2005 13:25:25 -0500 Received: from localhost (mgalgoci@localhost) by lacrosse.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j17IPPX27312 for ; Mon, 7 Feb 2005 13:25:25 -0500 X-Authentication-Warning: lacrosse.corp.redhat.com: mgalgoci owned process doing -bs Date: Mon, 7 Feb 2005 13:25:25 -0500 From: Matthew Galgoci X-X-Sender: mgalgoci@lacrosse.corp.redhat.com To: netdev@oss.sgi.com Subject: ipsec (ipv4 tunnel mode) is broken Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mgalgoci@redhat.com Precedence: bulk X-list: netdev Content-Length: 712 Lines: 25 I noticed as recenly as 2.6.11-rc3-bk3 that ipv4 ipsec is broken. I'm currently using openswan as my ike daemon. This was working with the same ike daemon and config as (I think) recenrly as 2.6.11-rc2. Before I go binary searching for the change that broke it, I was wondering if anyone knows offhand what the issue might be from these error messages in my kernel log: NET: Registered protocol family 15 ESP: md5 digestsize 16 != 0 ESP: md5 digestsize 16 != 0 ESP: md5 digestsize 16 != 0 ESP: md5 digestsize 16 != 0 openswan dies somewhere between phase 1 and phase 2 negotiation with an internal error. Regards, Matthew Galgoci -- Matthew Galgoci System Administrator Red Hat, Inc 919.754.3700 x44155 From shemminger@osdl.org Mon Feb 7 10:24:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 10:24:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17IOPHD006986 for ; Mon, 7 Feb 2005 10:24:28 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j17IOHl03957; Mon, 7 Feb 2005 10:24:17 -0800 Date: Mon, 7 Feb 2005 10:24:28 -0800 From: Stephen Hemminger To: maxer , Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: skge from 2.6.11-rc3-mm1 no workee either Message-ID: <20050207102428.5df9e529@dxpl.pdx.osdl.net> In-Reply-To: <42064462.8060306@xmission.com> References: <42064462.8060306@xmission.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1385 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: 2031 Lines: 57 On Sun, 06 Feb 2005 09:22:58 -0700 maxer wrote: > This nic is on the mobo. sk98lin from kernel 2.6.9 works great. However: > > If I go into Fedora Core's Network Device Control applet, it shows eth0 > inactive. If I try to activate it I get: > skge device eth0:1 does not seem to be present, delaying initialization. The applet is good, but when there are problems will need to diagnose with more direct commands. > Jeff Garzik suggested that I send this to you. > > Under Network Configuration tool trying to probe under "Bind to MAC > address gives the result as [Errno 19] No such device. > > So while the driver clearly loads, it can't find the device nor activate > it. The questions are: * does 'skge' get loaded? # lsmod * what is system log show related to skge # dmesg | grep skge > What should I do to remedy this. I can bring up the device under kernel > 2.6.9, but no kernel beyond this 2.6.10 or 2.6.11-xx works. Does it work with 'sk98lin' driver? # rmmod skge # modprobe sk98lin > 04:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit > Ethernet Controller (rev 17) > Subsystem: Intel Corp.: Unknown device 3065 > Flags: bus master, fast devsel, latency 0, IRQ 3 > Memory at ff720000 (64-bit, non-prefetchable) [size=16K] > I/O ports at a800 [size=256] > Expansion ROM at ff700000 [disabled] [size=128K] > Capabilities: [48] Power Management version 2 > Capabilities: [50] Vital Product Data > Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 > Enable- > Capabilities: [e0] Express Legacy Endpoint IRQ 0 > Capabilities: [100] Advanced Error Reporting Most likely this is a Marvell Yukon 2 chipset, which requires different driver support. I infer this because it is the PCI-express version. The only driver that handles Yukon2 on Linux is the version from Syskonnect's web site, but don't think it still works with 2.6.10 -- Stephen Hemminger From uucp@ganesha.gnumonks.org Mon Feb 7 11:07:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 11:07:31 -0800 (PST) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17J7Mn3009181 for ; Mon, 7 Feb 2005 11:07:23 -0800 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.34) id 1CyEEC-0000Fl-D2 for netdev@oss.sgi.com; Mon, 07 Feb 2005 20:07:20 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1CyDfR-0006pA-00; Mon, 07 Feb 2005 19:31:25 +0100 Date: Mon, 7 Feb 2005 19:31:25 +0100 From: Harald Welte To: Andi Kleen Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050207183125.GJ10011@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , Andi Kleen , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org References: <20050204140900.GD2518@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: <20050204140900.GD2518@wotan.suse.de> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.11-rc2-bk4gm1 X-Date: Today is Boomtime, the 37th day of Chaos in the YOLD 3171 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1564 Lines: 43 --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2005 at 03:09:00PM +0100, Andi Kleen wrote: >=20 > On kernels compiled with a big NR_CPUS netfilter rules would=20 > eat a lot of memory because all counters would be duplicated > for all NR_CPUs CPUs. With NR_CPUS=3D256 this would add up > to many MBs of memory. Thanks, Andi. I think the NR_CPUS is actually a remnescant of 2.3.x times when we didn't have num_possible_cpus() yet. Also wrt. your vmalloc issues, I think there are floating around some patches which replace our vmalloc use by __get_free_pages() anyway. --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCB7P9XaXGVTD0i/8RAmIqAJwJtMIpX7En5Aviun9GlUNlYgwlEACfW9aJ imO65JN9lU62h80CgsPfO2s= =V8jP -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v-- From ak@suse.de Mon Feb 7 11:10:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 11:10:47 -0800 (PST) Received: from Cantor.suse.de (news.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17JAfuS009970 for ; Mon, 7 Feb 2005 11:10:42 -0800 Received: from hermes.suse.de (hermes-ext.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 4DBAE142AB6A; Mon, 7 Feb 2005 20:10:30 +0100 (CET) Date: Mon, 7 Feb 2005 20:10:28 +0100 From: Andi Kleen To: Harald Welte , Andi Kleen , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050207191028.GF31482@wotan.suse.de> References: <20050204140900.GD2518@wotan.suse.de> <20050207183125.GJ10011@obroa-skai.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050207183125.GJ10011@obroa-skai.de.gnumonks.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1388 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: 289 Lines: 7 > Also wrt. your vmalloc issues, I think there are floating around some > patches which replace our vmalloc use by __get_free_pages() anyway. Don't think they're needed (unless you want it for other reasons). The vmalloc limit is clearly a bug in itself and will be surely fixed. -Andi From akpm@osdl.org Mon Feb 7 11:18:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 11:18:56 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17JInpj010709 for ; Mon, 7 Feb 2005 11:18:49 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j17JIRl13781; Mon, 7 Feb 2005 11:18:27 -0800 Date: Mon, 7 Feb 2005 11:18:22 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: spied@yandex.ru Subject: Fw: [Bugme-new] [Bug 4180] New: masquarade and source ip Message-Id: <20050207111822.65038881.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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1389 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: 979 Lines: 36 Begin forwarded message: Date: Mon, 7 Feb 2005 10:16:56 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4180] New: masquarade and source ip http://bugme.osdl.org/show_bug.cgi?id=4180 Summary: masquarade and source ip Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: laforge@gnumonks.org Submitter: spied@yandex.ru i try next on router (eth0 - inernet, eth1 - localnet): ip addr add eth0 1.2.3.4 ip addr add eth0 2.3.4.5 ip route add default via 2.3.4.6 src 2.3.4.5 iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -d ! 10.0.0.0/8 -j MASQUERADE if i do ping www.google.com from router source ip is 2.3.4.5, but if i do ping from local network source ip is 1.2.3.4 (i think it's wrong) with older kernel source ip is always set to 2.3.4.5 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jmorris@redhat.com Mon Feb 7 11:30:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 11:30:43 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17JUaEI011464 for ; Mon, 7 Feb 2005 11:30:36 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j17JUZPW031635 for ; Mon, 7 Feb 2005 14:30:35 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j17JUZO07671; Mon, 7 Feb 2005 14:30:35 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j17JUZZr003829; Mon, 7 Feb 2005 14:30:35 -0500 Date: Mon, 7 Feb 2005 14:30:35 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Matthew Galgoci cc: netdev@oss.sgi.com Subject: Re: ipsec (ipv4 tunnel mode) is broken In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1390 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: 846 Lines: 29 On Mon, 7 Feb 2005, Matthew Galgoci wrote: > > I noticed as recenly as 2.6.11-rc3-bk3 that ipv4 ipsec is broken. I'm currently using > openswan as my ike daemon. This was working with the same ike daemon and config as > (I think) recenrly as 2.6.11-rc2. > > Before I go binary searching for the change that broke it, I was wondering if anyone > knows offhand what the issue might be from these error messages in my kernel log: > > NET: Registered protocol family 15 > ESP: md5 digestsize 16 != 0 > ESP: md5 digestsize 16 != 0 > ESP: md5 digestsize 16 != 0 > ESP: md5 digestsize 16 != 0 > > openswan dies somewhere between phase 1 and phase 2 negotiation with an internal error. This patch should fix it (now in bk iirc): http://marc.theaimsgroup.com/?l=linux-netdev&m=110746335402355&w=2 - James -- James Morris From herbert@gondor.apana.org.au Mon Feb 7 12:36:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 12:36:19 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17KaBkq017640 for ; Mon, 7 Feb 2005 12:36:12 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CyFbr-0006UJ-00; Tue, 08 Feb 2005 07:35:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CyFbO-0005cI-00; Tue, 08 Feb 2005 07:35:22 +1100 From: Herbert Xu To: spied@yandex.ru Subject: Re: Fw: [Bugme-new] [Bug 4180] New: masquarade and source ip Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050207111822.65038881.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 08 Feb 2005 07:35:22 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 575 Lines: 16 > ip addr add eth0 1.2.3.4 > ip addr add eth0 2.3.4.5 Unless you put netmasks on the addresses, e.g., 2.3.4.5/30, the kernel won't know that 2.3.4.5 is a better address to use than 1.2.3.4 when trying to reach 2.3.4.6. > ip route add default via 2.3.4.6 src 2.3.4.5 This src setting does not survive through to the MASQUERADE target and therefore has no effect. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From megh.bhatt@gmail.com Mon Feb 7 12:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 12:42:40 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17Kgaov018264 for ; Mon, 7 Feb 2005 12:42:36 -0800 Received: by wproxy.gmail.com with SMTP id 71so961947wra for ; Mon, 07 Feb 2005 12:42:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=c0aofedvjQEyNBT42kDKpOx8dkkr+eUC+JT09JlDyrOXcuSl8oPP9K58swf/WRppFUDUuUJFpINzqghE/WBCrVk2+UwO36bKPmQLlOZ10nPrXaSAb0PTCg0xmZmpaEAMDatkARB4EfYBACb71LmJ1pStvSrHDmL8RpcvoX2qPzo= Received: by 10.54.51.11 with SMTP id y11mr32911wry; Mon, 07 Feb 2005 12:42:30 -0800 (PST) Received: by 10.54.41.7 with HTTP; Mon, 7 Feb 2005 12:42:30 -0800 (PST) Message-ID: <5d1f895705020712423d0a2a54@mail.gmail.com> Date: Mon, 7 Feb 2005 15:42:30 -0500 From: Megh Bhatt Reply-To: Megh Bhatt To: netdev@oss.sgi.com Subject: Linux Kernel Routing APIs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: megh.bhatt@gmail.com Precedence: bulk X-list: netdev Content-Length: 255 Lines: 7 Hi, Could some one point out the Linux kernel (2.6) routing api's to use for route lookups - both ipv4 and ipv6 - e.g. if a kernel loadable module needs to do route lookups to say find the interface for the route to a particular ip address? Thanks. Megh From herbert@gondor.apana.org.au Mon Feb 7 17:32:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 17:32:17 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j181W9Ki000324 for ; Mon, 7 Feb 2005 17:32:09 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CyKEJ-0000DS-00; Tue, 08 Feb 2005 12:31:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CyKE8-0007zT-00; Tue, 08 Feb 2005 12:31:40 +1100 Date: Tue, 8 Feb 2005 12:31:40 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: [IPSEC] Move dst->child loop from dst_ifdown to xfrm_dst_ifdown Message-ID: <20050208013140.GB30659@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206065117.GC16057@gondor.apana.org.au> <20050208012929.GA30659@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <20050208012929.GA30659@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5080 Lines: 147 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 08, 2005 at 12:29:29PM +1100, herbert wrote: > > This one moves the dst->child processing from dst_ifdown into > xfrm_dst_ifdown. This patch adds a net_device argument to ifdown. After all, it's a bit silly to notify someone of an ifdown event without telling them what which device it was for :) Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dst-patch-2 ===== include/net/dst.h 1.25 vs edited ===== --- 1.25/include/net/dst.h 2005-02-06 14:23:59 +11:00 +++ edited/include/net/dst.h 2005-02-08 12:14:10 +11:00 @@ -89,7 +89,8 @@ int (*gc)(void); struct dst_entry * (*check)(struct dst_entry *, __u32 cookie); void (*destroy)(struct dst_entry *); - void (*ifdown)(struct dst_entry *, int how); + void (*ifdown)(struct dst_entry *, + struct net_device *dev, int how); struct dst_entry * (*negative_advice)(struct dst_entry *); void (*link_failure)(struct sk_buff *); void (*update_pmtu)(struct dst_entry *dst, u32 mtu); ===== net/core/dst.c 1.27 vs edited ===== --- 1.27/net/core/dst.c 2005-02-08 12:12:21 +11:00 +++ edited/net/core/dst.c 2005-02-08 12:15:03 +11:00 @@ -220,12 +220,14 @@ * * Commented and originally written by Alexey. */ -static inline void dst_ifdown(struct dst_entry *dst, int unregister) +static inline void dst_ifdown(struct dst_entry *dst, struct net_device *dev, + int unregister) { - struct net_device *dev = dst->dev; - if (dst->ops->ifdown) - dst->ops->ifdown(dst, unregister); + dst->ops->ifdown(dst, dev, unregister); + + if (dev != dst->dev) + return; if (!unregister) { dst->input = dst_discard_in; @@ -252,8 +254,7 @@ case NETDEV_DOWN: spin_lock_bh(&dst_lock); for (dst = dst_garbage_list; dst; dst = dst->next) { - if (dst->dev == dev) - dst_ifdown(dst, event != NETDEV_DOWN); + dst_ifdown(dst, dev, event != NETDEV_DOWN); } spin_unlock_bh(&dst_lock); break; ===== net/ipv4/route.c 1.101 vs edited ===== --- 1.101/net/ipv4/route.c 2005-02-03 07:43:48 +11:00 +++ edited/net/ipv4/route.c 2005-02-08 12:14:11 +11:00 @@ -138,7 +138,8 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie); static void ipv4_dst_destroy(struct dst_entry *dst); -static void ipv4_dst_ifdown(struct dst_entry *dst, int how); +static void ipv4_dst_ifdown(struct dst_entry *dst, + struct net_device *dev, int how); static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst); static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); @@ -1342,11 +1343,12 @@ } } -static void ipv4_dst_ifdown(struct dst_entry *dst, int how) +static void ipv4_dst_ifdown(struct dst_entry *dst, struct net_device *dev, + int how) { struct rtable *rt = (struct rtable *) dst; struct in_device *idev = rt->idev; - if (idev && idev->dev != &loopback_dev) { + if (dev != &loopback_dev && idev && idev->dev == dev) { struct in_device *loopback_idev = in_dev_get(&loopback_dev); if (loopback_idev) { rt->idev = loopback_idev; ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00 +++ edited/net/ipv6/route.c 2005-02-08 12:14:11 +11:00 @@ -84,7 +84,8 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie); static struct dst_entry *ip6_negative_advice(struct dst_entry *); static void ip6_dst_destroy(struct dst_entry *); -static void ip6_dst_ifdown(struct dst_entry *, int how); +static void ip6_dst_ifdown(struct dst_entry *, + struct net_device *dev, int how); static int ip6_dst_gc(void); static int ip6_pkt_discard(struct sk_buff *skb); @@ -153,12 +154,13 @@ } } -static void ip6_dst_ifdown(struct dst_entry *dst, int how) +static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev, + int how) { struct rt6_info *rt = (struct rt6_info *)dst; struct inet6_dev *idev = rt->rt6i_idev; - if (idev != NULL && idev->dev != &loopback_dev) { + if (dev != &loopback_dev && idev != NULL && idev->dev == dev) { struct inet6_dev *loopback_idev = in6_dev_get(&loopback_dev); if (loopback_idev != NULL) { rt->rt6i_idev = loopback_idev; ===== net/xfrm/xfrm_policy.c 1.64 vs edited ===== --- 1.64/net/xfrm/xfrm_policy.c 2005-02-08 12:12:21 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-08 12:15:35 +11:00 @@ -1027,10 +1027,9 @@ dst->xfrm = NULL; } -static void xfrm_dst_ifdown(struct dst_entry *dst, int unregister) +static void xfrm_dst_ifdown(struct dst_entry *dst, struct net_device *dev, + int unregister) { - struct net_device *dev = dst->dev; - if (!unregister) return; --8GpibOaaTibBMecb-- From herbert@gondor.apana.org.au Mon Feb 7 17:30:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 17:30:58 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j181UnPW032282 for ; Mon, 7 Feb 2005 17:30:50 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CyKCk-0000D4-00; Tue, 08 Feb 2005 12:30:14 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CyKC1-0007yt-00; Tue, 08 Feb 2005 12:29:29 +1100 Date: Tue, 8 Feb 2005 12:29:29 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: [IPSEC] Move dst->child loop from dst_ifdown to xfrm_dst_ifdown Message-ID: <20050208012929.GA30659@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206065117.GC16057@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20050206065117.GC16057@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3373 Lines: 119 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 06, 2005 at 05:51:17PM +1100, herbert wrote: > > The idea is to move the check into dst->ops->ifdown. By definition > ipv6_dst_ifdown will only see rt6_info entries. So dst_dev_event > will become Here are the patches to do this. Do they look sane? This one moves the dst->child processing from dst_ifdown into xfrm_dst_ifdown. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dst-patch-1 ===== net/core/dst.c 1.26 vs edited ===== --- 1.26/net/core/dst.c 2005-02-06 14:23:59 +11:00 +++ edited/net/core/dst.c 2005-02-08 12:11:39 +11:00 @@ -220,31 +220,26 @@ * * Commented and originally written by Alexey. */ -static void dst_ifdown(struct dst_entry *dst, int unregister) +static inline void dst_ifdown(struct dst_entry *dst, int unregister) { struct net_device *dev = dst->dev; + if (dst->ops->ifdown) + dst->ops->ifdown(dst, unregister); + if (!unregister) { dst->input = dst_discard_in; dst->output = dst_discard_out; - } - - do { - if (unregister) { - dst->dev = &loopback_dev; - dev_hold(&loopback_dev); + } else { + dst->dev = &loopback_dev; + dev_hold(&loopback_dev); + dev_put(dev); + if (dst->neighbour && dst->neighbour->dev == dev) { + dst->neighbour->dev = &loopback_dev; dev_put(dev); - if (dst->neighbour && dst->neighbour->dev == dev) { - dst->neighbour->dev = &loopback_dev; - dev_put(dev); - dev_hold(&loopback_dev); - } + dev_hold(&loopback_dev); } - - if (dst->ops->ifdown) - dst->ops->ifdown(dst, unregister); - } while ((dst = dst->child) && dst->flags & DST_NOHASH && - dst->dev == dev); + } } static int dst_dev_event(struct notifier_block *this, unsigned long event, void *ptr) ===== net/xfrm/xfrm_policy.c 1.63 vs edited ===== --- 1.63/net/xfrm/xfrm_policy.c 2005-01-19 07:08:19 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-08 12:10:47 +11:00 @@ -1027,6 +1027,20 @@ dst->xfrm = NULL; } +static void xfrm_dst_ifdown(struct dst_entry *dst, int unregister) +{ + struct net_device *dev = dst->dev; + + if (!unregister) + return; + + while ((dst = dst->child) && dst->xfrm && dst->dev == dev) { + dst->dev = &loopback_dev; + dev_hold(&loopback_dev); + dev_put(dev); + } +} + static void xfrm_link_failure(struct sk_buff *skb) { /* Impossible. Such dst must be popped before reaches point of failure. */ @@ -1150,6 +1164,8 @@ dst_ops->check = xfrm_dst_check; if (likely(dst_ops->destroy == NULL)) dst_ops->destroy = xfrm_dst_destroy; + if (likely(dst_ops->ifdown == NULL)) + dst_ops->ifdown = xfrm_dst_ifdown; if (likely(dst_ops->negative_advice == NULL)) dst_ops->negative_advice = xfrm_negative_advice; if (likely(dst_ops->link_failure == NULL)) @@ -1181,6 +1197,7 @@ dst_ops->kmem_cachep = NULL; dst_ops->check = NULL; dst_ops->destroy = NULL; + dst_ops->ifdown = NULL; dst_ops->negative_advice = NULL; dst_ops->link_failure = NULL; dst_ops->get_mss = NULL; --nFreZHaLTZJo0R7j-- From rddunlap@osdl.org Mon Feb 7 18:58:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 18:58:45 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j182wfQS002859 for ; Mon, 7 Feb 2005 18:58:41 -0800 Received: from [192.168.1.103] (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j182wXuM031076 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Feb 2005 18:58:34 -0800 Message-ID: <420828A9.7060306@osdl.org> Date: Mon, 07 Feb 2005 18:49:13 -0800 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1395 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: 2575 Lines: 67 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) > > Support for HW/FW crypto and fragmentation offload, in a HW independent > fashion, is also on the short-term list. > > When you look through the patch you'll likely notice the #ifdef > NOTYET/#endif sequences surrounding portions of code from the hostap > project. Portions of this subsystem were based on an earlier version of > the hostap project. Those areas that weren't directly supported by the > ipw* projects weren't ported to be completely hardware independent > (since I don't have the hardware to test it), and so are still wrapped > in the ifdefs. These sections mainly cover support for MASTER and WDS > modes. > > Anyway, please let me know what you think. Hopefully I built the patch > right... James, Can you post a patch that will build? or did you just want feedback on the current state of the patch? Thanks, -- ~Randy a. in ieee80211/Makefile, there is nothing for ieee80211_module.o: ieee80211-objs := \ ieee80211_module.o \ b. in wireless/Makefile, it needs to pull in ieee80211, e.g.: --- Makefile~80211_netstack 2004-12-24 13:35:50.000000000 -0800 +++ Makefile 2005-02-07 18:37:49.000000000 -0800 @@ -2,6 +2,8 @@ # Makefile for the Linux Wireless network device drivers. # +obj-$(CONFIG_IEEE80211) += ieee80211/ + obj-$(CONFIG_STRIP) += strip.o obj-$(CONFIG_ARLAN) += arlan.o From jm@jm.kir.nu Mon Feb 7 19:59:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 19:59:33 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j183xPgH005384 for ; Mon, 7 Feb 2005 19:59:28 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CyMVU-0002Uh-0t; Mon, 07 Feb 2005 19:57:44 -0800 Date: Mon, 7 Feb 2005 19:57:44 -0800 From: Jouni Malinen To: "Randy.Dunlap" Cc: James Ketrenos , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050208035744.GC8366@jm.kir.nu> References: <4203C32A.70402@linux.intel.com> <420462BC.6010903@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420462BC.6010903@osdl.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1396 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: 1318 Lines: 34 On Fri, Feb 04, 2005 at 10:07:56PM -0800, Randy.Dunlap wrote: > 6. +struct ieee80211_ccmp_data { > > + u32 dot11RSNAStatsCCMPFormatErrors; > + u32 dot11RSNAStatsCCMPReplays; > + u32 dot11RSNAStatsCCMPDecryptErrors; > > Are these MIB-mandated names? otherwise the studlyCaps should go. Well, I don't know whether it would be fair to say these are mandated as variable names here, but yes, these are indeed the exact names used in IEEE 802.11i MIB definition which is the reason for the variable names here. > 8. What calls the .print_stats functions? > static char * ieee80211_ccmp_print_stats() > > Is it possible to use seq_file there instead of sprintf(), > or is this in /sysfs (so seq_file is not possible)? I used these for getting key information into procfs files. Conversion to seq_file should be possible for procfs. This is of course assuming that someone else has not used these for something else than procfs. > Are there any overflow possibilities? Should not be, these are used to create a procfs file of less than 500 bytes and the available buffer is at least a page. I did not yet look how these are used in this patch or ipw2100/ipw2200 drivers, so this is based on how I implemented this with Host AP driver. -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Mon Feb 7 20:31:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 20:31:35 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j184VTgA009935 for ; Mon, 7 Feb 2005 20:31:29 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CyN0Y-0002Wf-H2; Mon, 07 Feb 2005 20:29:50 -0800 Date: Mon, 7 Feb 2005 20:29:50 -0800 From: Jouni Malinen To: James Ketrenos Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050208042950.GD8366@jm.kir.nu> References: <4203C32A.70402@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203C32A.70402@linux.intel.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1397 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: 5095 Lines: 125 On Fri, Feb 04, 2005 at 12:47:06PM -0600, James Ketrenos wrote: > Support for HW/FW crypto and fragmentation offload, in a HW independent > fashion, is also on the short-term list. Do you already have some detailed plans on how to implement this? There are number of different implementations of TKIP hardware acceleration and it would be nice to support all of them. For example, some cards expect to get Ethernet 802.3 frames and take care of everything, others take IEEE 802.11 frames with possible padding between header and payload, some can take care of TKIP encryption part, but leave Michael MIC to software, some can take care of both for some packets, but not all (e.g., fragmentented frames), and so on.. > When you look through the patch you'll likely notice the #ifdef > NOTYET/#endif sequences surrounding portions of code from the hostap > project. Portions of this subsystem were based on an earlier version of > the hostap project. Those areas that weren't directly supported by the > ipw* projects weren't ported to be completely hardware independent > (since I don't have the hardware to test it), and so are still wrapped > in the ifdefs. These sections mainly cover support for MASTER and WDS > modes. We will need to take care of these areas in order to be able to call this "generic IEEE 802.11 networking stack".. I would like to be able to test replacing the upper level code in Host AP driver with this and verify that all functionality is still available. Another useful test case would be to go through what needs to be done to make this work with the madwifi driver (i.e., merge some parts of net80211 code with this and make the low-level parts of the driver use the combination for IEEE 802.11 processing). > diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/Kconfig netdev-2.6-ipw/drivers/net/wireless/Kconfig > --- netdev-2.6/drivers/net/wireless/Kconfig 2005-02-04 10:10:44 -06:00 > +++ netdev-2.6-ipw/drivers/net/wireless/Kconfig 2005-02-04 10:20:02 -06:00 > @@ -28,6 +28,8 @@ > special kernel support are available from > . > > +source "drivers/net/wireless/ieee80211/Kconfig" The generic IEEE 802.11 implementatio should go to net/ieee80211 or net/80211 etc. like mentioned before. > +config IEEE80211_DEBUG > + This option will enable debug tracing output for the > + ieee80211 network stack. > + % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level Generic IEEE 802.11 code should not refer to specific driver.. Should there be a per network device option for setting debug level or is a global one enough? > + For a list of values you can assign to debug_level, simply > + perform: > + > + % . idvals > + > + From within drivers/net/wireless/ipw2200 > + > + If you are not trying to debug or develop the IPW2200 driver, > + you > + most likely want to say N here. This sounds like something that should be moved to ipw2200 specific configuration option. > +config IEEE80211_WPA > + tristate "IEEE 802.11 WPA" > + depends on IEEE80211_CRYPT > + ---help--- > + Software implementation of IEEE 802.11 WPA. You will need > + to select the WPA algorithms you wish to use. Software implementation? Is there a hardware implementation of WPA? ;-) "WPA algorithms" should be replaced with cipher suites or something like that since WPA uses number of algorithms for key management and authentication and those are not included in the kernel code. Is this configuration option needed or should WPA support be included by default? If this remains, we should at least included WPA2 and IEEE 802.11i in the description, since this code is not only for WPA. > +config IEEE80211_CRYPT_CCMP > + tristate "IEEE 802.11 CCMP encryption" > + depends on IEEE80211_WPA > + select CRYPTO_AES_586 Is CRYPTO_AES_586 the proper way of selecting this? 586 sounds like x86-specific optimization, but I would like to use this on, say, xscale. > +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c 2005-02-04 10:20:03 -06:00 > +#include "../ieee80211.h" Should that be moved to include/net/ieee80211.h? I.e., this would be #include . > +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 2005-02-04 10:20:03 -06:00 > +#ifndef CONFIG_CRYPTO > +#error CONFIG_CRYPTO is required to build this module. > +#endif This can be removed, IEEE80211_CRYPT had "select CRYPTO" in Kconfig. > +static void * ieee80211_ccmp_init(int key_idx) > +{ > + struct ieee80211_ccmp_data *priv; > + > + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); You do not seem to include try_module_get(THIS_MODULE) here (and matching module_put in deinit) like the version in Host AP driver is using. What is protecting the CCMP/TKIP modules from being unloaded when they are still used? That's for the first 1840 lines of the patch and enough for today.. I'll try to continue later this week. -- Jouni Malinen PGP id EFC895FA From rddunlap@osdl.org Mon Feb 7 20:54:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 20:54:37 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j184sWF1011310 for ; Mon, 7 Feb 2005 20:54:32 -0800 Received: from [192.168.1.103] (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j184sPuM010055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Feb 2005 20:54:25 -0800 Message-ID: <420843CF.7060303@osdl.org> Date: Mon, 07 Feb 2005 20:45:03 -0800 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1398 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: 2642 Lines: 66 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) > > Support for HW/FW crypto and fragmentation offload, in a HW independent > fashion, is also on the short-term list. > > When you look through the patch you'll likely notice the #ifdef > NOTYET/#endif sequences surrounding portions of code from the hostap > project. Portions of this subsystem were based on an earlier version of > the hostap project. Those areas that weren't directly supported by the > ipw* projects weren't ported to be completely hardware independent > (since I don't have the hardware to test it), and so are still wrapped > in the ifdefs. These sections mainly cover support for MASTER and WDS > modes. > > Anyway, please let me know what you think. Hopefully I built the patch > right... Here are a few more comments. 1. No need to check ptr for NULL before kfree(ptr), so several places like this can be simplified: +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } 2. drivers/net/wireless/ieee80211/ieee80211_rx.c includes: +#include "ieee80211.h" Should that be ../ieee80211.h (which I dislike), or should the Makefile specify -I to the parent directory, or what? IOW, I don't see how it finds the header file, but the "able to build request" will fix this one. 3. +static inline int ieee80211_network_init() is more than 200 lines. Somebody likes huge inline functions. (wow, 1/2 thru a 4900 line patch :) -- ~Randy From kaber@trash.net Mon Feb 7 22:04:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 22:04:29 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1864Isf013586 for ; Mon, 7 Feb 2005 22:04:19 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CyOTt-0008U2-Fc; Tue, 08 Feb 2005 07:04:13 +0100 Date: Tue, 8 Feb 2005 07:04:13 +0100 (CET) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: "Serge E. Hallyn" cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru, linux-audit@redhat.com Subject: Re: [PATCH] Add audit uid to netlink credentials In-Reply-To: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> Message-ID: References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 474 Lines: 12 On Fri, 4 Feb 2005, Serge E. Hallyn wrote: > Most audit control messages are sent over netlink. In order to properly > log the identity of the sender of audit control messages, we would like > to add the loginuid to the netlink_creds structure, as per the attached > patch. Reception of netlink messages in the kernel happens in the context of the sending process, so you can simply call audit_get_loginuid(current->audit_context) in audit_receive_msg(). Regards Patrick From kaber@trash.net Mon Feb 7 22:25:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Feb 2005 22:25:45 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j186Pc5u014698 for ; Mon, 7 Feb 2005 22:25:39 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CyOoZ-0008Vx-1o; Tue, 08 Feb 2005 07:25:35 +0100 Date: Tue, 8 Feb 2005 07:25:35 +0100 (CET) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: Andrew Morton cc: netdev@oss.sgi.com, spied@yandex.ru Subject: Re: Fw: [Bugme-new] [Bug 4180] New: masquarade and source ip In-Reply-To: <20050207111822.65038881.akpm@osdl.org> Message-ID: References: <20050207111822.65038881.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1565 Lines: 51 The masquerading code got simplified and uses inet_select_addr() instead of querying routing for the source address now. This means it will usually pick the first address on the device, except for gatewayed routes, in which case it will try to find an address in the network of the gateway. Users should use SNAT for setups with multiple IPs, in this case it is also possible to specify a netmask in "ip addr add 2.3.4.5" so it will be prefered for the gateway 2.3.4.6. Regards Patrick On Mon, 7 Feb 2005, Andrew Morton wrote: > > > Begin forwarded message: > > Date: Mon, 7 Feb 2005 10:16:56 -0800 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4180] New: masquarade and source ip > > > http://bugme.osdl.org/show_bug.cgi?id=4180 > > Summary: masquarade and source ip > Kernel Version: 2.6.10 > Status: NEW > Severity: normal > Owner: laforge@gnumonks.org > Submitter: spied@yandex.ru > > > i try next on router (eth0 - inernet, eth1 - localnet): > > ip addr add eth0 1.2.3.4 > ip addr add eth0 2.3.4.5 > > ip route add default via 2.3.4.6 src 2.3.4.5 > > iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -d ! 10.0.0.0/8 -j MASQUERADE > > if i do ping www.google.com from router source ip is 2.3.4.5, but if i do ping > from local network source ip is 1.2.3.4 (i think it's wrong) > > with older kernel source ip is always set to 2.3.4.5 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > From spied@yandex.ru Tue Feb 8 01:12:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 01:12:22 -0800 (PST) Received: from pantene.yandex.ru (pantene.yandex.ru [213.180.200.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j189CGOV023114 for ; Tue, 8 Feb 2005 01:12:17 -0800 Received: from YAMAIL (pantene.yandex.ru) by mail.yandex.ru id ; Tue, 8 Feb 2005 12:11:53 +0300 Date: Tue, 8 Feb 2005 12:11:53 +0300 (MSK) From: "spied" Reply-To: spied@yandex.ru Message-Id: <42088259.000022.13502@pantene.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] To: kaber@trash.net Cc: netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4180] New: masquarade and source ip In-Reply-To: References: <20050207111822.65038881.akpm@osdl.org> X-source-ip: 62.32.54.90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: spied@yandex.ru Precedence: bulk X-list: netdev Content-Length: 129 Lines: 4 >The masquerading code got simplified and uses inet_select_addr() instead >of querying routing for the source address now. why? From herbert@gondor.apana.org.au Tue Feb 8 02:37:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 02:37:25 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18Aat5H026686 for ; Tue, 8 Feb 2005 02:37:13 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CyShv-0002qC-00; Tue, 08 Feb 2005 21:34:59 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CyShZ-0003AO-00; Tue, 08 Feb 2005 21:34:37 +1100 From: Herbert Xu To: spied@yandex.ru Subject: Re: Fw: [Bugme-new] [Bug 4180] New: masquarade and source ip Cc: kaber@trash.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <42088259.000022.13502@pantene.yandex.ru> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 08 Feb 2005 21:34:37 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 615 Lines: 15 spied wrote: >>The masquerading code got simplified and uses inet_select_addr() instead >>of querying routing for the source address now. > > why? Because the previous approach of looking up the route again was prone to failure with multi-path routing. More importantly it doesn't always return the correct route (that is the route the packet received before it entered POSTROUTING). -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From didier@barvaux.org Tue Feb 8 04:22:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 04:22:17 -0800 (PST) Received: from mail.b2i-toulouse.com (host.97.67.23.62.rev.coltfrance.com [62.23.67.97]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18CMARd004852 for ; Tue, 8 Feb 2005 04:22:12 -0800 Received: from catherine.b2i-toulouse.com ([62.23.67.99]) by mail.b2i-toulouse.com (8.12.5/8.12.5) with SMTP id j18CM0I2003691; Tue, 8 Feb 2005 13:22:01 +0100 Date: Tue, 8 Feb 2005 13:21:54 +0100 From: Didier Barvaux To: usagi-users@linux-ipv6.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: (usagi-users 03197) Re: TAHI Conformance Test Message-Id: <20050208132154.21176283.didier@barvaux.org> In-Reply-To: <20050207.194136.130656563.yoshfuji@linux-ipv6.org> References: <20050207102553.28a46fcd.didier@barvaux.org> <20050207.194136.130656563.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.99 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: didier@barvaux.org Precedence: bulk X-list: netdev Content-Length: 849 Lines: 37 Hello, > Please do not multipost... Sorry about that. > Well, we haven't tested vanilla linux-2.4.x recently. > However, linux-2.6.11-rc2 w/ usagi-tools (userspace daemon etc.), > acting as host and/or router, passed IPv6 Ready Logo [1] > Phase 1 Self-Test, which is similar to CT. > (Note: usagi-linux24 and usagi-linux26 passed it, too.) Ok. > And, we are trying passing Phase 2 Self-Test as well. > My private tree already passed it, and patches will soon be available > (in linux-2.6.12 timeframe). Good news. > I think linux-2.6.11-rc2 w/ usagi-tools can pass TAHI CT; > we will test later. > > We may try to backport changes to 2.4.x. > > I hope this helps. Thanks. Thank you a lot for these information. Sorry for the multipost. Thank you for your job on the Linux kernel and on the USAGI project. Regards, Didier Barvaux From okir@suse.de Tue Feb 8 06:18:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 06:19:01 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18EIthG010171 for ; Tue, 8 Feb 2005 06:18:56 -0800 Received: from hermes.suse.de (hermes-ext.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 472991432B07 for ; Tue, 8 Feb 2005 15:18:49 +0100 (CET) Date: Tue, 8 Feb 2005 15:18:49 +0100 From: Olaf Kirch To: netdev@oss.sgi.com Subject: [PATCH] natsemi: long cable, short cable Message-ID: <20050208141849.GC23971@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1404 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: 2239 Lines: 62 The current version of the natsemi driver comes with a workaround for a hardware problem that causes link failures on short cables. Unfortunately, this workaround causes massive link failures on _long_ cables (270-300ft). This patch adds a module parameter to disable the workaround if required. Signed-off-by: Olaf Kirch Index: linux-2.6.10/drivers/net/natsemi.c =================================================================== --- linux-2.6.10.orig/drivers/net/natsemi.c +++ linux-2.6.10/drivers/net/natsemi.c @@ -186,6 +186,7 @@ static int debug = -1; /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static int max_interrupt_work = 20; static int mtu; +static int no_cable_magic = 0; /* Maximum number of multicast addresses to filter (vs. rx-all-multicast). This chip uses a 512 element hash table based on the Ethernet CRC. */ @@ -257,6 +258,7 @@ module_param(debug, int, 0); module_param(rx_copybreak, int, 0); module_param_array(options, int, NULL, 0); module_param_array(full_duplex, int, NULL, 0); +module_param(no_cable_magic, int, 0); MODULE_PARM_DESC(max_interrupt_work, "DP8381x maximum events handled per interrupt"); MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)"); @@ -266,6 +268,9 @@ MODULE_PARM_DESC(rx_copybreak, MODULE_PARM_DESC(options, "DP8381x: Bits 0-3: media type, bit 17: full duplex"); MODULE_PARM_DESC(full_duplex, "DP8381x full duplex setting(s) (1)"); +MODULE_PARM_DESC(no_cable_magic, + "DP8381x: set no_cable_magic=1 to disable magic workaround for short cables " + "(may help with long cables:-)"); /* Theory of Operation @@ -1578,6 +1583,9 @@ static void do_cable_magic(struct net_de struct netdev_private *np = netdev_priv(dev); void __iomem *ioaddr = ns_ioaddr(dev); + if (no_cable_magic) + return; + if (dev->if_port != PORT_TP) return; @@ -1623,6 +1631,9 @@ static void undo_cable_magic(struct net_ struct netdev_private *np = netdev_priv(dev); void __iomem * ioaddr = ns_ioaddr(dev); + if (no_cable_magic) + return; + if (dev->if_port != PORT_TP) return; -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From jketreno@linux.intel.com Tue Feb 8 06:24:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 06:24:50 -0800 (PST) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18EOgf7010813 for ; Tue, 8 Feb 2005 06:24:43 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j18EOSMA028075; Tue, 8 Feb 2005 14:24:28 GMT Received: from [127.0.0.1] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j18EOPSa013985; Tue, 8 Feb 2005 14:24:26 GMT Message-ID: <42087751.3040806@linux.intel.com> Date: Tue, 08 Feb 2005 02:24:49 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <420828A9.7060306@osdl.org> In-Reply-To: <420828A9.7060306@osdl.org> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------010107000504060601000604" X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 9990 Lines: 353 This is a multi-part message in MIME format. --------------010107000504060601000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Randy.Dunlap wrote: > James Ketrenos wrote: > >> Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 >> subsystem used by the ipw2100 and ipw2200 projects. >> >> I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 >> that use thist stack to the list on Monday. >> >> In terms of what the stack currently does: >> >> * HW independent -- it only knows about 802.11 data and structures >> * Performs an 802.3 <-> 802.11 transform for data Tx/Rx >> * Host based support for fragmentation, WEP, and WPA using the >> kernel's crypto functions >> * Beacon and probe response collection and parsing >> * Default implementation of some of the WE handlers that can be >> managed without hardware knowledge >> >> We are working to merge in Dave Miller's p80211 code into the >> ieee80211 subsystem so that it hooks into the kernel as a true >> network layer as opposed to a mutated offspring of ethernet. >> Once that is done, hopefully the skb to txb code can be reworked and >> 802.11 fragments can be treated either as normal skbs, or skbs can be >> modified to directly support them (ideally so that encrypted 802.11 >> frames in support of IP packets can be cached by the stack instead of >> having to be re-encrypted on TCP retries) >> >> Support for HW/FW crypto and fragmentation offload, in a HW >> independent fashion, is also on the short-term list. >> >> When you look through the patch you'll likely notice the #ifdef >> NOTYET/#endif sequences surrounding portions of code from the hostap >> project. Portions of this subsystem were based on an earlier version >> of the hostap project. Those areas that weren't directly supported >> by the ipw* projects weren't ported to be completely hardware >> independent (since I don't have the hardware to test it), and so are >> still wrapped in the ifdefs. These sections mainly cover support for >> MASTER and WDS modes. >> >> Anyway, please let me know what you think. Hopefully I built the >> patch right... > > > James, > Can you post a patch that will build? or did you just want > feedback on the current state of the patch? Ah; I see my tree that I did the diff on was missing the wireless/Makefile and the ieee80211/ieee80211_module.c to create the patch against... sigh. Attached is ieee80211_module.c; you have the change for the Makefile to include ieee80211. Later {hopefully today} I'll send a full patch that includes several of the corrections you called out in your prior patch. Thanks, James > > Thanks, --------------010107000504060601000604 Content-Type: text/x-csrc; name="ieee80211_module.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ieee80211_module.c" /******************************************************************************* Copyright(c) 2004 Intel Corporation. All rights reserved. Portions of this file are based on the WEP enablement code provided by the Host AP project hostap-drivers v0.1.3 Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen Copyright (c) 2002-2003, Jouni Malinen This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. The full GNU General Public License is included in this distribution in the file called LICENSE. Contact Information: James P. Ketrenos Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 *******************************************************************************/ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "ieee80211.h" MODULE_DESCRIPTION("802.11 data/management/control stack"); MODULE_AUTHOR("Copyright (C) 2004 Intel Corporation "); MODULE_LICENSE("GPL"); #define DRV_NAME "ieee80211" static inline int ieee80211_networks_allocate(struct ieee80211_device *ieee) { if (ieee->networks) return 0; ieee->networks = kmalloc( MAX_NETWORK_COUNT * sizeof(struct ieee80211_network), GFP_KERNEL); if (!ieee->networks) { printk(KERN_WARNING "%s: Out of memory allocating beacons\n", ieee->dev->name); return -ENOMEM; } memset(ieee->networks, 0, MAX_NETWORK_COUNT * sizeof(struct ieee80211_network)); return 0; } static inline void ieee80211_networks_free(struct ieee80211_device *ieee) { if (!ieee->networks) return; kfree(ieee->networks); ieee->networks = NULL; } static inline void ieee80211_networks_initialize(struct ieee80211_device *ieee) { int i; INIT_LIST_HEAD(&ieee->network_free_list); INIT_LIST_HEAD(&ieee->network_list); for (i = 0; i < MAX_NETWORK_COUNT; i++) list_add_tail(&ieee->networks[i].list, &ieee->network_free_list); } struct net_device *alloc_ieee80211(int sizeof_priv) { struct ieee80211_device *ieee; struct net_device *dev; int err; IEEE80211_DEBUG_INFO("Initializing...\n"); dev = alloc_etherdev(sizeof(struct ieee80211_device) + sizeof_priv); if (!dev) { IEEE80211_ERROR("Unable to network device.\n"); goto failed; } ieee = netdev_priv(dev); dev->hard_start_xmit = ieee80211_xmit; ieee->dev = dev; err = ieee80211_networks_allocate(ieee); if (err) { IEEE80211_ERROR("Unable to allocate beacon storage: %d\n", err); goto failed; } ieee80211_networks_initialize(ieee); /* Default fragmentation threshold is maximum payload size */ ieee->fts = DEFAULT_FTS; ieee->scan_age = DEFAULT_MAX_SCAN_AGE; ieee->open_wep = 1; #ifdef CONFIG_IEEE80211_CRYPT /* Default to enabling full open WEP with host based encrypt/decrypt */ ieee->host_encrypt = 1; ieee->host_decrypt = 1; ieee->ieee802_1x = 1; /* Default to supporting 802.1x */ INIT_LIST_HEAD(&ieee->crypt_deinit_list); init_timer(&ieee->crypt_deinit_timer); ieee->crypt_deinit_timer.data = (unsigned long)ieee; ieee->crypt_deinit_timer.function = ieee80211_crypt_deinit_handler; #endif spin_lock_init(&ieee->lock); #ifdef CONFIG_IEEE80211_WPA ieee->wpa_enabled = 0; ieee->tkip_countermeasures = 0; ieee->drop_unencrypted = 0; ieee->privacy_invoked = 0; ieee->ieee802_1x = 1; #endif /* CONFIG_IEEE80211_WPA */ return dev; failed: if (dev) free_netdev(dev); return NULL; } void free_ieee80211(struct net_device *dev) { struct ieee80211_device *ieee = netdev_priv(dev); #ifdef CONFIG_IEEE80211_CRYPT int i; del_timer_sync(&ieee->crypt_deinit_timer); ieee80211_crypt_deinit_entries(ieee, 1); for (i = 0; i < WEP_KEYS; i++) { struct ieee80211_crypt_data *crypt = ieee->crypt[i]; if (crypt) { if (crypt->ops) { crypt->ops->deinit(crypt->priv); module_put(crypt->ops->owner); } kfree(crypt); ieee->crypt[i] = NULL; } } #endif ieee80211_networks_free(ieee); free_netdev(dev); } #ifdef CONFIG_IEEE80211_DEBUG static int debug = 0; u32 ieee80211_debug_level = 0; struct proc_dir_entry *ieee80211_proc = NULL; static int show_debug_level(char *page, char **start, off_t offset, int count, int *eof, void *data) { return snprintf(page, count, "0x%08X\n", ieee80211_debug_level); } static int store_debug_level(struct file *file, const char *buffer, unsigned long count, void *data) { char buf[] = "0x00000000"; unsigned long len = min(sizeof(buf) - 1, (u32)count); char *p = (char *)buf; unsigned long val; if (copy_from_user(buf, buffer, len)) return count; buf[len] = 0; if (p[1] == 'x' || p[1] == 'X' || p[0] == 'x' || p[0] == 'X') { p++; if (p[0] == 'x' || p[0] == 'X') p++; val = simple_strtoul(p, &p, 16); } else val = simple_strtoul(p, &p, 10); if (p == buf) printk(KERN_INFO DRV_NAME ": %s is not in hex or decimal form.\n", buf); else ieee80211_debug_level = val; return strnlen(buf, count); } static int __init ieee80211_init(void) { struct proc_dir_entry *e; ieee80211_debug_level = debug; ieee80211_proc = create_proc_entry(DRV_NAME, S_IFDIR, proc_net); if (ieee80211_proc == NULL) { IEEE80211_ERROR("Unable to create " DRV_NAME " proc directory\n"); return -EIO; } e = create_proc_entry("debug_level", S_IFREG | S_IRUGO | S_IWUSR, ieee80211_proc); if (!e) { remove_proc_entry(DRV_NAME, proc_net); ieee80211_proc = NULL; return -EIO; } e->read_proc = show_debug_level; e->write_proc = store_debug_level; e->data = NULL; return 0; } static void __exit ieee80211_exit(void) { if (ieee80211_proc) { remove_proc_entry("debug_level", ieee80211_proc); remove_proc_entry(DRV_NAME, proc_net); ieee80211_proc = NULL; } } #include module_param(debug, int, 0444); MODULE_PARM_DESC(debug, "debug output mask"); module_exit(ieee80211_exit); module_init(ieee80211_init); #endif EXPORT_SYMBOL(alloc_ieee80211); EXPORT_SYMBOL(free_ieee80211); --------------010107000504060601000604-- From chas@cmf.nrl.navy.mil Tue Feb 8 07:02:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 07:02:59 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18F2sou012842 for ; Tue, 8 Feb 2005 07:02:55 -0800 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 j18F2ITI010672; Tue, 8 Feb 2005 10:02:19 -0500 (EST) Message-Id: <200502081502.j18F2ITI010672@ginger.cmf.nrl.navy.mil> To: Roman Kagan , netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-Reply-To: Message from Roman Kagan of "Sun, 06 Feb 2005 22:19:18 +0300." <20050206191918.GA2369@katya> Date: Tue, 08 Feb 2005 10:02:19 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1406 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: 757 Lines: 16 In message <20050206191918.GA2369@katya>,Roman Kagan writes: >Is it publically available? Linux-ATM CVS appears to contain no >kernelspace code. I'm just curious how atm_dev attributes are mapped to >net_device's, which doesn't look easy with the current atm_dev and >net_device. not really. i just stuck attached the atm_dev to the netdevice's priv. the only thing that really bothered me about this was that the atm devices would show in an ifconfig. this might confuse some people. >it is, maybe we shouldn't create an atm-specific user-visible interface >in sysfs and hotplug which is going to be obsoleted by the net generic >one in the near future? with sysfs support the only thing left to 'fix' would be splitting of allocation/registration. From jketreno@linux.intel.com Tue Feb 8 07:26:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 07:26:07 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18FQ1tS016728 for ; Tue, 8 Feb 2005 07:26:01 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j18FPrw7007148; Tue, 8 Feb 2005 15:25:53 GMT Received: from [127.0.0.1] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j18FPoSa019911; Tue, 8 Feb 2005 15:25:52 GMT Message-ID: <420885B6.7090606@linux.intel.com> Date: Tue, 08 Feb 2005 03:26:14 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <20050208042950.GD8366@jm.kir.nu> In-Reply-To: <20050208042950.GD8366@jm.kir.nu> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 9505 Lines: 283 Jouni Malinen wrote: >On Fri, Feb 04, 2005 at 12:47:06PM -0600, James Ketrenos wrote: > > > >>Support for HW/FW crypto and fragmentation offload, in a HW independent >>fashion, is also on the short-term list. >> >> > >Do you already have some detailed plans on how to implement this? There >are number of different implementations of TKIP hardware acceleration >and it would be nice to support all of them. For example, some cards >expect to get Ethernet 802.3 frames and take care of everything, others >take IEEE 802.11 frames with possible padding between header and >payload, some can take care of TKIP encryption part, but leave Michael >MIC to software, some can take care of both for some packets, but not >all (e.g., fragmentented frames), and so on.. > > I don't have any detailed planning on this currently. I agree it should be done in a way to support as much hardware as possible -- the most difficult will likely be support of adapters that require 802.3 frames since all thinking to this point has been to make the stack such that wireless drivers never need to know about 802.3. Is it only for the data Tx/Rx that the 802.11/802.3 transform is handled by the device? Or does the device internalize all 802.11 features such that 802.11 frames are never exposed externally? The ipw2100 is similar in some regard to this -- although it doesn't take either 802.3 or 802.11; it takes a raw data payload and a data structure that contains the dest addr, etc. >>When you look through the patch you'll likely notice the #ifdef >>NOTYET/#endif sequences surrounding portions of code from the hostap >>project. Portions of this subsystem were based on an earlier version of >>the hostap project. Those areas that weren't directly supported by the >>ipw* projects weren't ported to be completely hardware independent >>(since I don't have the hardware to test it), and so are still wrapped >>in the ifdefs. These sections mainly cover support for MASTER and WDS >>modes. >> >> > >We will need to take care of these areas in order to be able to call >this "generic IEEE 802.11 networking stack".. I would like to be able to >test replacing the upper level code in Host AP driver with this and >verify that all functionality is still available. Another useful test >case would be to go through what needs to be done to make this work with >the madwifi driver (i.e., merge some parts of net80211 code with this >and make the low-level parts of the driver use the combination for IEEE >802.11 processing). > > Agreed. Hopefully as more folks start seeing these patches others will be encouraged to try and help out, pulling the best of all the existing drivers together. >>diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/Kconfig netdev-2.6-ipw/drivers/net/wireless/Kconfig >>--- netdev-2.6/drivers/net/wireless/Kconfig 2005-02-04 10:10:44 -06:00 >>+++ netdev-2.6-ipw/drivers/net/wireless/Kconfig 2005-02-04 10:20:02 -06:00 >>@@ -28,6 +28,8 @@ >> special kernel support are available from >> . >> >>+source "drivers/net/wireless/ieee80211/Kconfig" >> >> > >The generic IEEE 802.11 implementatio should go to net/ieee80211 or >net/80211 etc. like mentioned before. > > I'll rework it into net/ieee80211. >>+config IEEE80211_DEBUG >>+ This option will enable debug tracing output for the >>+ ieee80211 network stack. >> >> > > > >>+ % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level >> >> > >Generic IEEE 802.11 code should not refer to specific driver.. Should >there be a per network device option for setting debug level or is a >global one enough? > > This was an oversite when last I updated the Kconfig for the ieee80211 components. The debug level for ieee80211 is configured in /proc/net/ieee80211/debug_level. Currently there is a script provided in the ipw2100 and ipw2200 projects that greps the various debug levels supported for ieee80211 and dumps them to the console so the user doesn't have to manually look in ieee80211.h to try and figure out what bit masks in the debug_level correspond to what aspects. That script should be provided in a utility pacakge for the ieee80211 stack -- a question is if it should simply grep on the running kernel's ieee80211.h to find the debug levels, or if the ieee80211 subsystem should contain in it the strings to export to the utility its internal debug levels via sysfs. Having the debug flexibility in the module has been extremely useful in tracking issues and resolving bugs, while not flooding everyone's kernel logs with unneeded messages. >>+ For a list of values you can assign to debug_level, simply >>+ perform: >>+ >>+ % . idvals >>+ >>+ From within drivers/net/wireless/ipw2200 >>+ >>+ If you are not trying to debug or develop the IPW2200 driver, >>+ you >>+ most likely want to say N here. >> >> > >This sounds like something that should be moved to ipw2200 specific >configuration option. > > Same oversite as above -- it should change to: ---- For a list of values you can assign to debug_level, you can need to use the ieee80211 utility package available at . Once installed, you can then run: % ieee80211_dvals To obtain a list of supported debug masks. You can also read/write the debug mask via /proc/net/ieee80211/debug_level If you are not trying to debug or develop the ieee80211 subsystem, you most likely want to say N here. --- and then I need to put up an ieee80211 utility package somewhere... >>+config IEEE80211_WPA >>+ tristate "IEEE 802.11 WPA" >>+ depends on IEEE80211_CRYPT >>+ ---help--- >>+ Software implementation of IEEE 802.11 WPA. You will need >>+ to select the WPA algorithms you wish to use. >> >> > >Software implementation? Is there a hardware implementation of WPA? ;-) >"WPA algorithms" should be replaced with cipher suites or something like >that since WPA uses number of algorithms for key management and >authentication and those are not included in the kernel code. > > >Is this configuration option needed or should WPA support be included by >default? If this remains, we should at least included WPA2 and IEEE >802.11i in the description, since this code is not only for WPA. > > 802.11i should be provided by default (it currently isn't). If we provide the option for selecting the cipher suites, any issues with this text?: CONFIG_IEEE80211_WEP Include software based cipher suites in support of IEEE 802.11's WEP. This is needed for WEP as well as 802.1x. This selects ARC4 under kernel crypto libraries, and CRC32 under kernel libraries. CONFIG_IEEE80211_CCMP Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. This selects AES support under kernel crypto libraries. CONFIG_IEEE80211_TKIP Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled networks. This selects Michael Mic support under kernel crypto libraries. ... All of the above should default to 'Y'. >>+config IEEE80211_CRYPT_CCMP >>+ tristate "IEEE 802.11 CCMP encryption" >>+ depends on IEEE80211_WPA >>+ select CRYPTO_AES_586 >> >> > >Is CRYPTO_AES_586 the proper way of selecting this? 586 sounds like >x86-specific optimization, but I would like to use this on, say, xscale. > > How do you set up a dependency to be "one of"? depends on CRYPTO_AES or CRYPTO_AES_586 ? >>+++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c 2005-02-04 10:20:03 -06:00 >> >> > > > >>+#include "../ieee80211.h" >> >> > >Should that be moved to include/net/ieee80211.h? I.e., this would be >#include . > > Will do. >>+++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 2005-02-04 10:20:03 -06:00 >> >> > > > >>+#ifndef CONFIG_CRYPTO >>+#error CONFIG_CRYPTO is required to build this module. >>+#endif >> >> > >This can be removed, IEEE80211_CRYPT had "select CRYPTO" in Kconfig. > > Removed. >>+static void * ieee80211_ccmp_init(int key_idx) >>+{ >>+ struct ieee80211_ccmp_data *priv; >>+ >>+ priv = kmalloc(sizeof(*priv), GFP_ATOMIC); >> >> > >You do not seem to include try_module_get(THIS_MODULE) here (and >matching module_put in deinit) like the version in Host AP driver is >using. What is protecting the CCMP/TKIP modules from being unloaded when >they are still used? > > The handler that loads the crypto module performs a try_module_get(). Currently that code isn't contained in ieee80211_wx.c and is in drivers loading the ciphers for WPA -- it needs to be moved to the ieee80211_wx. Which raises the question -- should we continue to support dynamically loading cipher suite handlers, or just statically compile them in if the user has requested them to be included? Originally, the cipher suites contained all the crypto code within them, which increased their size and complexity. Now, however, the suites are essentially shims that wrap the kernel crypto libraries. There is the obvious aspect of flexibility that arises from supporting arbitrary and dynamic loading of crypto shims, but it does complicate the code somewhat. Thoughts? >That's for the first 1840 lines of the patch and enough for today.. I'll >try to continue later this week. > > Thanks, James From jketreno@linux.intel.com Tue Feb 8 07:41:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 07:42:00 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18FfuBe019997 for ; Tue, 8 Feb 2005 07:41:56 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j18Ffgw7013552; Tue, 8 Feb 2005 15:41:42 GMT Received: from [127.0.0.1] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j18FfaSa030559; Tue, 8 Feb 2005 15:41:40 GMT Message-ID: <42088967.2020901@linux.intel.com> Date: Tue, 08 Feb 2005 03:41:59 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: "Randy.Dunlap" , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <420462BC.6010903@osdl.org> <20050208035744.GC8366@jm.kir.nu> In-Reply-To: <20050208035744.GC8366@jm.kir.nu> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 1823 Lines: 58 Jouni Malinen wrote: >On Fri, Feb 04, 2005 at 10:07:56PM -0800, Randy.Dunlap wrote: > > > >>6. +struct ieee80211_ccmp_data { >> >>+ u32 dot11RSNAStatsCCMPFormatErrors; >>+ u32 dot11RSNAStatsCCMPReplays; >>+ u32 dot11RSNAStatsCCMPDecryptErrors; >> >>Are these MIB-mandated names? otherwise the studlyCaps should go. >> >> > >Well, I don't know whether it would be fair to say these are mandated as >variable names here, but yes, these are indeed the exact names used in >IEEE 802.11i MIB definition which is the reason for the variable names >here. > > A thought that has been at the back of my mind is if we will ever want to fully export the MIBs for 802.11, and if so, are there any minimal overhead ways of doing so from kernel drivers? >>8. What calls the .print_stats functions? >>static char * ieee80211_ccmp_print_stats() >> >>Is it possible to use seq_file there instead of sprintf(), >>or is this in /sysfs (so seq_file is not possible)? >> >> > >I used these for getting key information into procfs files. Conversion >to seq_file should be possible for procfs. This is of course assuming >that someone else has not used these for something else than procfs. > > >>Are there any overflow possibilities? >> >> >Should not be, these are used to create a procfs file of less than 500 >bytes and the available buffer is at least a page. I did not yet look >how these are used in this patch or ipw2100/ipw2200 drivers, so this is >based on how I implemented this with Host AP driver. > > The ipw* drivers currently don't use the print_stats callbacks. Do we want to maintain this capability of the ciphers to be able to output freeform data, or should this be incorporated into a more defined output structure for use by user space tools and exported by the ieee80211 subsystem? James From rkagan@mail.ru Tue Feb 8 08:46:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 08:46:32 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18GkRYB025421 for ; Tue, 8 Feb 2005 08:46:27 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id 2F1D84DEDAE; Tue, 8 Feb 2005 19:45:44 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.220.52] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 399370899; Tue, 08 Feb 2005 19:45:44 +0300 Date: Tue, 8 Feb 2005 19:45:47 +0300 From: Roman Kagan To: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050208164547.GA2928@katya> Mail-Followup-To: Roman Kagan , netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net References: <20050206191918.GA2369@katya> <200502081502.j18F2ITI010672@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502081502.j18F2ITI010672@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 619 Lines: 14 On Tue, Feb 08, 2005 at 10:02:19AM -0500, chas williams - CONTRACTOR wrote: > >it is, maybe we shouldn't create an atm-specific user-visible interface > >in sysfs and hotplug which is going to be obsoleted by the net generic > >one in the near future? > > with sysfs support the only thing left to 'fix' would be splitting of > allocation/registration. I beg your pardon, but are you saying that you've changed your mind re. moving to net_device? Is your plan now to cast in stone that ATM devices live under class/atm in sysfs, and go ahead with splitting of allocation/registration of the current atm_dev? Roman. From shemminger@osdl.org Tue Feb 8 11:13:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 11:13:24 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18JDJKY031245 for ; Tue, 8 Feb 2005 11:13:20 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j18JDDl09386; Tue, 8 Feb 2005 11:13:13 -0800 Date: Tue, 8 Feb 2005 11:13:25 -0800 From: Stephen Hemminger To: James Ketrenos Cc: "Randy.Dunlap" , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050208111325.45a8a106@dxpl.pdx.osdl.net> In-Reply-To: <420843CF.7060303@osdl.org> References: <4203C32A.70402@linux.intel.com> <420843CF.7060303@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1410 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: 1866 Lines: 53 A couple of observations: 1. You can get rid of the /proc interface altogether since now with sysfs module parameters can be made accessible via module_param 2. Include files need to be moved and factored better: include/linux/ieee80211.h for anything exposed to utilities and general API related include/net/ieee80211.h for interfaces other drivers would use. drivers/net/wireless/iee80211/iee80211_xxx.h for stuff that only gets used internally. 3. Remove the BIT() macro and instead show the shift. My preference would be to change to something like: enum ieee80211_rate { IEEE80211_CCK_RATE_1MB_MASK = 1<<0, IEEE80211_CCK_RATE_2MB_MASK = 1<<1, ... 4. Don't put data in .h files like eap_types[] Maybe just move eap_get_type() to .c fle 5. Use C99 initializers for tags arrays like eap_types[] i.e static const char *eap_types[] = { [EAP_PACKET] = "EAP-Packet", ... 5. Move is_broadcast_addr and is_multicast_addr to etherdevice.h besides is_muliticast_addr(x) has extra uneeded test. 6. Don't put format type stuff in .h file MAC_FMT, MAC_ARG, etc... 7. Don't need () around simple integers in #define's #define IEEE80211_3ADDR_LEN (24) 8. Patch if_ether.h rather than stuff like: #ifndef ETH_P_80211_RAW #define ETH_P_80211_RAW (ETH_P_ECONET + 1) #endif 9. Isn't SNAP generic and not part of just wireless, LLC and other places like ATM have the similar stuff, maybe one set of routines and definitions? 10. Do we really need another set of statistics? Already have ethtool, net_stats, wireless, ...? 11. Does ieee->scans need to be atomic? 12. offset_in_page() shouldn't be here and is defined elsewhere. The basic philosophy changes as this gets incorporated in mailine kernel. You need to feel free to patch in several existing header files rather than standing alone as required in an out of tree driver. From jt@hpl.hp.com Tue Feb 8 13:45:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 13:45:54 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18LjkHf011580 for ; Tue, 8 Feb 2005 13:45:49 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id CE3EF40046A; Tue, 8 Feb 2005 13:45:39 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA00753; Tue, 8 Feb 2005 13:48:06 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CydAx-00016U-00; Tue, 08 Feb 2005 13:45:39 -0800 Date: Tue, 8 Feb 2005 13:45:39 -0800 To: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050208214539.GA3290@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 1147 Lines: 26 Stephen Hemminger wrote : > > 9. Isn't SNAP generic and not part of just wireless, LLC and other places > like ATM have the similar stuff, maybe one set of routines and definitions? > SNAP is totally generic and IMHO should not be tied to the wireless stuff. I thought that SNAP was defined in 802.2, but RFC 1042 seems to be the place (which is older than 802.11 or ATM). First, if you use true IEEE 802.3 (as oppposed to the usual Ethernet II), the IP frames will use SNAP encapsulation (because the 802.3 frames don't have a type field). I don't think there is many networks using 802.3 (mostly admin config error), which is why Linux doesn't seem to support it. More importantly, there is a class of wireless drivers that would only need SNAP but not the rest of the 802.11 framework, because they use 802.3 frames natively. A good example is the Orinoco driver, you will find that the driver has SNAP encapsulation and decapsulation. I can't comment on the ATM stuff... I think IEEE has not changed their policy with respect to 802.2, so IMHO we can expect more standard from them requiring SNAP in the future. Have fun... Jean From rich@phekda.gotadsl.co.uk Tue Feb 8 14:59:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 14:59:37 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18MxTm0013939 for ; Tue, 8 Feb 2005 14:59:30 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (195-112-44-183.dyn.gotadsl.co.uk [195.112.44.183]) by smtp.nildram.co.uk (Postfix) with ESMTP id 75FCB2BDEF7; Tue, 8 Feb 2005 22:59:24 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id E3BA7318; Tue, 8 Feb 2005 23:01:09 +0000 (GMT) Message-ID: <420944AB.5090501@phekda.gotadsl.co.uk> Date: Tue, 08 Feb 2005 23:00:59 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> <20050205204135.GA13986@electric-eye.fr.zoreil.com> In-Reply-To: <20050205204135.GA13986@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1890 Lines: 55 Hello. Francois Romieu wrote: [snip] > If you can do an extra test, I'd like to know if you can safely bring > the r8169 interface down on your computer once the patch below if applied: > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc3/r8169/patches/r8169-380.patch > > (it should apply correctly on top of you current setup) I can, with and without that patch. But I encounter problems bringing the interface back up and down again. If I do the following after a reboot: /etc/init.d/network stop /etc/init.d/network start /etc/init.d/network stop I find that the "ip link set dev eth0 down" command hangs, consuming most of the CPU time (~99%). Note that I issued the "network" commands with about a second's delay between each command. This is with a static IP address. If the IP address is assigned via DHCP, then the DHCP client hangs in the "network start" command. I'm running Fedora Core 3 + all the latest security updates. >>One more thing: >> >>With 1.6LK + my PHY patch, I see the message "eth0: PHY reset until link >>up" every 5 seconds or so, when there is no Ethernet cable plugged in. >>This is annoying. I think it should only log it once. > > > Hmmm... One could argue that 1) syslog will cope and 2) the printk level > of the console can be lowered. Some event kamasutra can probably be done > from userspace too so I am a bit reluctant to special case this code > (read as: I'd welcome more requests/complaints). > > Is it enough for you if I salt the code with a few netif_msg_xxx() here > and there to control the messages ? That sounds good. I'm happy to submit a patch to do this, if you'd like. Note that I'm new to kernel programming, so it might take me a while. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From jgarzik@pobox.com Tue Feb 8 15:26:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 15:26:44 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18NQaOF015567 for ; Tue, 8 Feb 2005 15:26:39 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cyekd-0000HB-1W; Tue, 08 Feb 2005 23:26:35 +0000 Message-ID: <42094A6D.9080508@pobox.com> Date: Tue, 08 Feb 2005 18:25:33 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: Jouni Malinen , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <20050208042950.GD8366@jm.kir.nu> <420885B6.7090606@linux.intel.com> In-Reply-To: <420885B6.7090606@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1413 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: 494 Lines: 15 Just to keep everything moving, my recommendation would be to move the code to net/*, and resend the patch (with whatever changes you have made to date). That way you, and others, can review and work on the tree in parallel. I'm worried that your list of todo items (based on responses so far) is already so long that I won't hear from you for another year ;-) We need to get the wireless-2.6 tree active again, and avoid bottlenecks. We need "release early, release often." Jeff From jketreno@linux.intel.com Tue Feb 8 15:34:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 15:34:21 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18NYFTm016184 for ; Tue, 8 Feb 2005 15:34:18 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j18NY56O022670; Tue, 8 Feb 2005 23:34:05 GMT Received: from [192.168.1.154] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j18NY316023969; Tue, 8 Feb 2005 23:34:04 GMT Message-ID: <42094C46.9040701@linux.intel.com> Date: Tue, 08 Feb 2005 17:33:26 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Jouni Malinen , netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <20050208042950.GD8366@jm.kir.nu> <420885B6.7090606@linux.intel.com> <42094A6D.9080508@pobox.com> In-Reply-To: <42094A6D.9080508@pobox.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 786 Lines: 21 Jeff Garzik wrote: > Just to keep everything moving, my recommendation would be to move the > code to net/*, and resend the patch (with whatever changes you have > made to date). > > That way you, and others, can review and work on the tree in parallel. > > I'm worried that your list of todo items (based on responses so far) > is already so long that I won't hear from you for another year ;-) We > need to get the wireless-2.6 tree active again, and avoid > bottlenecks. We need "release early, release often." I've allocated a couple hours tomorrow to merge in all the comments to date and get them pushed to my bk tree (bk://ipw.bkbits.net/ipw-2.6 is where I've been staging all of the ipw work) So, I'll send a new patch out tomorrow with what I have to date. James From jt@hpl.hp.com Tue Feb 8 16:27:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 16:27:55 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j190Rogu021439 for ; Tue, 8 Feb 2005 16:27:50 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id F21CD40A23A; Tue, 8 Feb 2005 16:27:47 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA05419; Tue, 8 Feb 2005 16:30:14 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Cyfhr-0002YH-00; Tue, 08 Feb 2005 16:27:47 -0800 Date: Tue, 8 Feb 2005 16:27:47 -0800 To: Marcelo Tosatti , netdev@oss.sgi.com, "David S. Miller" , Stephen Hemminger Subject: [PATCH 2.4] SIOCSIFNAME wildcard support (re-resend) Message-ID: <20050209002747.GA9792@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 2859 Lines: 94 Hi all, Just to make sure everybody seen it twice... Jean ----- Forwarded message from jt ----- Subject: [PATCH 2.4] SIOCSIFNAME wildcard support (resend) E-mail: jt@hpl.hp.com Hi Marcelo, I did not receive any feedback on this e-mail, so I assume it was lost on the way. Would you mind pushing that in 2.4.x ? Thanks... Jean ----- Forwarded message from jt ----- Subject: [PATCH 2.4] SIOCSIFNAME wildcard support E-mail: jt@hpl.hp.com Hi Marcelo, This patch adds wildcard support for the SIOCSIFNAME ioctl, like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to change network interface names (such as nameif, ifrename, or ip link), this patch allow those tools to specify a pattern, such as "eth%d" or "wlan%d", and the kernel use the lowest available slot. The reason I'm sending you this patch is that I've got some 2.4.X users who requested the feature... This patch was initially done for 2.4.23, and I rediffed and retested with 2.4.29. It's somewhat different from the patch Stephen and me added to 2.6.1, because the netdev init code is different and also this patch is more conservative. Have fun... Jean ------------------------------------------------------------- diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c --- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003 +++ linux/net/core/dev.c Wed Dec 3 18:55:27 2003 @@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr, case SIOCSIFNAME: if (dev->flags&IFF_UP) return -EBUSY; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - dev->name[IFNAMSIZ-1] = 0; + /* Check if name contains a wildcard */ + if (strchr(ifr->ifr_newname, '%')) { + char format[IFNAMSIZ + 1]; + int ret; + memcpy(format, ifr->ifr_newname, IFNAMSIZ); + format[IFNAMSIZ-1] = 0; + /* Find a free name based on format. + * dev_alloc_name() replaces "%d" with at max + * 2 digits, so no name overflow. - Jean II */ + ret = dev_alloc_name(dev, format); + if (ret < 0) + return ret; + /* Copy the new name back to caller. */ + strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ); + } else { + if (__dev_get_by_name(ifr->ifr_newname)) + return -EEXIST; + memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); + dev->name[IFNAMSIZ-1] = 0; + } notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); return 0; @@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar * - return a value */ + case SIOCSIFNAME: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) @@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: From davem@davemloft.net Tue Feb 8 16:52:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 16:52:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j190qcpW022879 for ; Tue, 8 Feb 2005 16:52:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyg5R-0001Qh-00; Tue, 08 Feb 2005 16:52:09 -0800 Date: Tue, 8 Feb 2005 16:52:09 -0800 From: "David S. Miller" To: Nishanth Aravamudan Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, kernel-janitors@lists.osdl.org Subject: Re: [PATCH 19/39] net/dev: replace schedule_timeout() with msleep() Message-Id: <20050208165209.0481fb9d.davem@davemloft.net> In-Reply-To: <20050120235352.GH2600@us.ibm.com> References: <20050120235352.GH2600@us.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 371 Lines: 10 On Thu, 20 Jan 2005 15:53:52 -0800 Nishanth Aravamudan wrote: > Description: Use msleep() instead of schedule_timeout() to guarantee the task > delays as expected. The current code uses TASK_INTERRUPTIBLE, but does not > respond to signals, so msleep() should be ok. > > Signed-off-by: Nishanth Aravamudan Applied, thanks Nishanth. From davem@davemloft.net Tue Feb 8 16:52:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 16:52:30 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j190qP3u022836 for ; Tue, 8 Feb 2005 16:52:26 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyg2L-0001QX-00; Tue, 08 Feb 2005 16:48:58 -0800 Date: Tue, 8 Feb 2005 16:48:57 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] kill xfrm_export.c Message-Id: <20050208164857.1c51656e.davem@davemloft.net> In-Reply-To: <20050119091715.GQ1841@stusta.de> References: <20050119091715.GQ1841@stusta.de> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 266 Lines: 9 On Wed, 19 Jan 2005 10:17:15 +0100 Adrian Bunk wrote: > This patch removes xfrm_export.c and moves the EXPORT_SYMBOL{,_GPL}'s to > the files where the actual functions are. > > Signed-off-by: Adrian Bunk Applied, thanks Adrian. From davem@davemloft.net Tue Feb 8 20:16:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:16:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194GrNF028239 for ; Tue, 8 Feb 2005 20:16:53 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyjHG-0002ET-00; Tue, 08 Feb 2005 20:16:34 -0800 Date: Tue, 8 Feb 2005 20:16:34 -0800 From: "David S. Miller" To: netdev@oss.sgi.com Cc: mpm@selenic.com Subject: serious netpoll bug w/NAPI Message-Id: <20050208201634.03074349.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 48 Consider a NAPI device currently executing it's poll function, pushing SKBs into the networking stack. Some of these will generate response packets etc. If for some reason a printk() is generated by the packet processing and: 1) the netconsole output device is the same as the NAPI device processing packets 2) netif_queue_stopped() is true because the tx queue is full the netpoll code will recurse back into the driver's poll function. This is incredibly illegal and results in all kinds of driver state corruption. ->poll() must execute only once at a time. This situation is actually quite common, via the ipt_LOG.c packet logging module. What the netpoll code appears to be trying to do is get the TX queue to make forward progress by invoking ->poll() if pending. The trouble is, that ->poll() at the top level will not clear the __LINK_STATE_RX_SCHED bit and delete itself from the poll list until it is done with ->poll() processing. So we get backtraces like: tg3_rx() tg3_poll() poll_napi() netpoll_poll() write_msg() .. printk() ... ip_rcv() ... netif_receive_skb() tg3_rx() tg3_poll() net_rx_action() __do_softirq() do_softirq() resulting in RX queue corruption in the driver and usually NULL skb pointer dereferences. From davem@davemloft.net Tue Feb 8 20:36:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:36:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194aeHW032418 for ; Tue, 8 Feb 2005 20:36:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyjZt-0002J8-00; Tue, 08 Feb 2005 20:35:49 -0800 Date: Tue, 8 Feb 2005 20:35:49 -0800 From: "David S. Miller" To: Nishanth Aravamudan Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH 20/39] net/ip_vs_sync: replace schedule_timeout() with ssleep() Message-Id: <20050208203549.4ede783b.davem@davemloft.net> In-Reply-To: <20050120235634.GI2600@us.ibm.com> References: <20050120235634.GI2600@us.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 416 Lines: 12 On Thu, 20 Jan 2005 15:56:34 -0800 Nishanth Aravamudan wrote: > Please consider applying. > > Description: Use ssleep() instead of schedule_timeout() to guarantee the task > delays as expected. The first two replacements use TASK_INTERRUPTIBLE but do not > check for signals, so ssleep() should be appropriate. > > Signed-off-by: Nishanth Aravamudan Applied, thanks Nishanth. From davem@davemloft.net Tue Feb 8 20:37:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:37:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194bfgn032751 for ; Tue, 8 Feb 2005 20:37:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyjb4-0002JP-00; Tue, 08 Feb 2005 20:37:02 -0800 Date: Tue, 8 Feb 2005 20:37:02 -0800 From: "David S. Miller" To: James Morris Cc: nacc@us.ibm.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH 21/39] net/ipconfig: replace schedule_timeout() with msleep() Message-Id: <20050208203702.7f033fcb.davem@davemloft.net> In-Reply-To: References: <20050120235749.GJ2600@us.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 429 Lines: 16 On Thu, 20 Jan 2005 21:36:42 -0500 (EST) James Morris wrote: > On Thu, 20 Jan 2005, Nishanth Aravamudan wrote: > > > Hi, > > > > Please consider applying. > > > > Description: Use msleep() instead of schedule_timeout() to guarantee the task > > delays as expected. Change the units of the two constants to be msecs and secs > > respectively. > > Looks fine to me. To me too, applied. Thanks Nishanth. From davem@davemloft.net Tue Feb 8 20:39:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:39:11 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194d6G7000880 for ; Tue, 8 Feb 2005 20:39:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyjci-0002Jn-00; Tue, 08 Feb 2005 20:38:44 -0800 Date: Tue, 8 Feb 2005 20:38:44 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] Tcp port selection for IPV6. Message-Id: <20050208203844.779038ca.davem@davemloft.net> In-Reply-To: <20050120164529.6d6a5f0b@dxpl.pdx.osdl.net> References: <20050120164529.6d6a5f0b@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 704 Lines: 16 On Thu, 20 Jan 2005 16:45:29 -0800 Stephen Hemminger wrote: > This patch makes TCP over IPV6 select ports the same way the current > TCPv4 code does. It uses a hash function to provide a starting offset > and a free running counter to provide seed. > > This changes the port selection semantics to match TCPv4 as well. > If the port is in use but to a different remote address, it will get > reused. It looks like the TCPv6 code was not updated when the TCPv4 > code changed. Now the code in ipv4/tcp_ipv4.c and ipv6/tcp_ipv6.c are > almost identical for tcp_hash_connect. > > Signed-off-by: Stephen Hemminger I've tossed this into my 2.6.12-pending tree. From davem@davemloft.net Tue Feb 8 20:55:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:55:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194tc1m001687 for ; Tue, 8 Feb 2005 20:55:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyjrt-0002NY-00; Tue, 08 Feb 2005 20:54:25 -0800 Date: Tue, 8 Feb 2005 20:54:24 -0800 From: "David S. Miller" To: Thomas Graf Cc: kuznet@ms2.inr.ac.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NET: Fix calculation for collapsed skb size Message-Id: <20050208205424.19d421b8.davem@davemloft.net> In-Reply-To: <20050207142742.GA31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050128234828.GA24868@yakov.inr.ac.ru> <20050129002128.GX31837@postel.suug.ch> <20050129002701.GY31837@postel.suug.ch> <20050206223239.5dc4e325.davem@davemloft.net> <20050207142742.GA31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 236 Lines: 10 On Mon, 7 Feb 2005 15:27:42 +0100 Thomas Graf wrote: > patch also applies to 2.4 with some fuzz. > > Noticed by Denis V. Lunev > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue Feb 8 20:56:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:56:59 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194urwQ002038 for ; Tue, 8 Feb 2005 20:56:54 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyjtW-0002Nr-00; Tue, 08 Feb 2005 20:56:06 -0800 Date: Tue, 8 Feb 2005 20:56:05 -0800 From: "David S. Miller" To: Patrick McHardy Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-Id: <20050208205605.0935a77c.davem@davemloft.net> In-Reply-To: <4206A58A.9050909@trash.net> References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> <1107727330.1053.44.camel@jzny.localdomain> <4206A58A.9050909@trash.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 457 Lines: 14 On Mon, 07 Feb 2005 00:17:30 +0100 Patrick McHardy wrote: > jamal wrote: > > >I should have caught that output missing divisor ;-> > >Dave please apply Patricks version. Should probably apply cleanly on > >2.4.x as well. > > > My last patch has a similar problem, new hash tables added with > "u32 divisor .." are skipped while walking. This patch is better > tested and should be fine. Applies to 2.4 and 2.6. Applied, thanks Patrick. From davem@davemloft.net Tue Feb 8 20:58:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 20:59:00 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j194wsjq002690 for ; Tue, 8 Feb 2005 20:58:54 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyjvj-0002Qb-00; Tue, 08 Feb 2005 20:58:23 -0800 Date: Tue, 8 Feb 2005 20:58:23 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Stop using dst->xfrm Message-Id: <20050208205823.0760499e.davem@davemloft.net> In-Reply-To: <20050121102319.GA3160@gondor.apana.org.au> References: <20050121102319.GA3160@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 436 Lines: 12 On Fri, 21 Jan 2005 21:23:19 +1100 Herbert Xu wrote: > Here is a precursor to the xfrm dst consolidation that I talked about. > In order to be able to store multiple SAs in one dst, we need to stop > using dst->xfrm directly. > > The following patch does that for the ->output() functions. > > Signed-off-by: Herbert Xu Queued into my 2.6.12-pending tree, thanks Herbert. From davem@davemloft.net Tue Feb 8 21:04:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 21:04:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1954qK5003204 for ; Tue, 8 Feb 2005 21:04:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyk1b-0002Qt-00; Tue, 08 Feb 2005 21:04:27 -0800 Date: Tue, 8 Feb 2005 21:04:27 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH 0/12] remove sk_protinfo series Message-Id: <20050208210427.1cf77186.davem@davemloft.net> In-Reply-To: <41F07497.4020109@conectiva.com.br> References: <41F07497.4020109@conectiva.com.br> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 195 Lines: 6 On Fri, 21 Jan 2005 01:18:47 -0200 Arnaldo Carvalho de Melo wrote: > bk://kernel.bkbits.net/acme/connection_sock-2.6 Pulled into my 2.6.12-pending tree, thanks Arnaldo. From davem@davemloft.net Tue Feb 8 21:10:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 21:10:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j195A4tP003741 for ; Tue, 8 Feb 2005 21:10:04 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyk6A-0002RG-00; Tue, 08 Feb 2005 21:09:10 -0800 Date: Tue, 8 Feb 2005 21:09:10 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [2/2] [NET] Add skb_header_cloned and use it in e1000/tg3 Message-Id: <20050208210910.0ef6b8b6.davem@davemloft.net> In-Reply-To: <20050129032210.GA7424@gondor.apana.org.au> References: <20050121204024.6f94fc26.davem@davemloft.net> <20050122054346.GA1635@gondor.apana.org.au> <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 594 Lines: 14 On Sat, 29 Jan 2005 14:22:10 +1100 Herbert Xu wrote: > This patch adds skb_header_cloned which tells us whether we need to > copy the data before we can modify the header part of the skb. Again, > what constitutes the header is left up to the users of the skb to define. > > This patch then uses this function in e1000/tg3 to copy the data before > the TCP/IP header is modified. > > Signed-off-by: Herbert Xu These two patches look great. I want to review them some more but I do intend to try and get them into 2.6.11-final. From mmporter@cox.net Tue Feb 8 21:34:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 21:34:44 -0800 (PST) Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j195Ydb2004515 for ; Tue, 8 Feb 2005 21:34:40 -0800 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050209053433.JTGO19250.fed1rmmtao04.cox.net@liberty.homelinux.org>; Wed, 9 Feb 2005 00:34:33 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA12862; Tue, 8 Feb 2005 22:34:33 -0700 Date: Tue, 8 Feb 2005 22:34:33 -0700 From: Matt Porter To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: [PATCH] emac: fix jumbo frame support Message-ID: <20050208223433.A12821@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 1477 Lines: 38 Fixes a bug in RX buffer allocation so that jumbo size skbs are allocated when the MTU size is changed. Also removes the deprecated restore_flags() call. Please apply. Signed-off-by: Matt Porter ===== drivers/net/ibm_emac/ibm_emac_core.c 1.7 vs edited ===== --- 1.7/drivers/net/ibm_emac/ibm_emac_core.c 2004-12-07 10:06:23 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-08 22:25:39 -07:00 @@ -912,7 +912,6 @@ PKT_DEBUG(("emac_start_xmit() stopping queue\n")); netif_stop_queue(dev); spin_unlock_irqrestore(&fep->lock, flags); - restore_flags(flags); return -EBUSY; } @@ -1281,7 +1280,7 @@ /* Format the receive descriptor ring. */ ep->rx_slot = 0; /* Default is MTU=1500 + Ethernet overhead */ - ep->rx_buffer_size = ENET_DEF_BUF_SIZE; + ep->rx_buffer_size = dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE; emac_rx_fill(dev, 0); if (ep->rx_slot != 0) { printk(KERN_ERR ===== drivers/net/ibm_emac/ibm_emac_core.h 1.2 vs edited ===== --- 1.2/drivers/net/ibm_emac/ibm_emac_core.h 2004-08-05 07:26:55 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-08 22:24:52 -07:00 @@ -77,8 +77,6 @@ #define ENET_HEADER_SIZE 14 #define ENET_FCS_SIZE 4 -#define ENET_DEF_MTU_SIZE 1500 -#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE) #define EMAC_MIN_FRAME 64 #define EMAC_MAX_FRAME 9018 #define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE) From mmporter@cox.net Tue Feb 8 21:44:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 21:44:16 -0800 (PST) Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j195i9cr005133 for ; Tue, 8 Feb 2005 21:44:09 -0800 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050209054404.MLBP1747.fed1rmmtao07.cox.net@liberty.homelinux.org>; Wed, 9 Feb 2005 00:44:04 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA12936; Tue, 8 Feb 2005 22:43:45 -0700 Date: Tue, 8 Feb 2005 22:43:45 -0700 From: Matt Porter To: jgarzik@pobox.com Cc: ralphs@netwinder.org, netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: [PATCH] emac: fix mdio delay Message-ID: <20050208224345.B12821@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 658 Lines: 18 Fixes MDIO delay. Please apply. Signed-off-by: Ralph Siemsen Signed-off-by: Matt Porter --- linux-2.6.10-orig/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:45:28.576226303 -0500 +++ linux-2.6.10/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:25:10.430674655 -0500 @@ -475,8 +479,9 @@ out_be32(&emacp->em0stacr, stacr); - while (((stacr = in_be32(&emacp->em0stacr) & EMAC_STACR_OC) == 0) - && (count++ < 5000)) + count = 0; + while ((((stacr = in_be32(&emacp->em0stacr)) & EMAC_STACR_OC) == 0) + && (count++ < MDIO_DELAY)) udelay(1); MDIO_DEBUG((" (count was %d)\n", count)); From herbert@gondor.apana.org.au Tue Feb 8 22:08:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Feb 2005 22:08:25 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1968Hfv006331 for ; Tue, 8 Feb 2005 22:08:18 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cyl0n-0003IY-00; Wed, 09 Feb 2005 17:07:41 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cyl0F-00028L-00; Wed, 09 Feb 2005 17:07:07 +1100 Date: Wed, 9 Feb 2005 17:07:07 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [2/2] [NET] Add skb_header_cloned and use it in e1000/tg3 Message-ID: <20050209060707.GA8180@gondor.apana.org.au> References: <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> <20050208210910.0ef6b8b6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050208210910.0ef6b8b6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 685 Lines: 19 On Tue, Feb 08, 2005 at 09:09:10PM -0800, David S. Miller wrote: > > These two patches look great. I want to review them some more but > I do intend to try and get them into 2.6.11-final. Actually I would've thought that this is the sort of patch that should wait until 2.6.12-pre is open. The bug that it fixes isn't that serious. All I've heard so far are tcpdump showing bogus results. The potential for breakage on the other side is much more significant. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From lkml@einar-lueck.de Wed Feb 9 05:28:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 05:28:43 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19DSZXE025163 for ; Wed, 9 Feb 2005 05:28:36 -0800 Received: (qmail 1052 invoked from network); 9 Feb 2005 13:28:33 -0000 Received: from unknown (HELO [192.168.30.10]) (008508@[217.231.185.147]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 9 Feb 2005 13:28:33 -0000 Message-ID: <420A1011.1030602@einar-lueck.de> Date: Wed, 09 Feb 2005 14:28:49 +0100 From: =?ISO-8859-1?Q?Einar_L=FCck?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> In-Reply-To: <20050202172333.4d0ad5f0.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lkml@einar-lueck.de Precedence: bulk X-list: netdev Content-Length: 600 Lines: 14 David S. Miller wrote: > Can you describe more precisely "the scenerios, that are relevant > to us"? The scenarios we have in mind are setups in which a set of collaborating servers steadly establish connections among each other with a very high rate. This high rate requirement drove us to consider the inclusion of all alternative routes into the routing cache because the corresponding delay for each connection establishment is low and the load is balanced over all available routes. That's why we did not consider a slow lookup in the fib for each connection established. Regards, Einar. From sds@epoch.ncsc.mil Wed Feb 9 05:42:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 05:42:45 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19DgRgI025992 for ; Wed, 9 Feb 2005 05:42:28 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j19DdDQY021900; Wed, 9 Feb 2005 13:39:13 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j19DfhRH017713; Wed, 9 Feb 2005 08:41:43 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Linux Audit Discussion Cc: "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> Content-Type: text/plain Organization: National Security Agency Message-Id: <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 09 Feb 2005 08:34:39 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 666 Lines: 16 On Tue, 2005-02-08 at 01:04, Patrick McHardy wrote: > Reception of netlink messages in the kernel happens in the context > of the sending process, so you can simply call > audit_get_loginuid(current->audit_context) in audit_receive_msg(). Then why does netlink_sendmsg() need to save the effective capability set of the sender in the control buffer (via security_netlink_send) for later checking by other receive functions in the kernel (via security_netlink_recv)? What prevents audit_receive() or other similar receive functions in the kernel from processing messages sent by multiple senders? -- Stephen Smalley National Security Agency From kaber@trash.net Wed Feb 9 06:10:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 06:10:31 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19EAKNw027064 for ; Wed, 9 Feb 2005 06:10:20 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CysXg-0002au-Kr; Wed, 09 Feb 2005 15:10:08 +0100 Message-ID: <420A19C0.4070402@trash.net> Date: Wed, 09 Feb 2005 15:10:08 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Smalley CC: Linux Audit Discussion , "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1029 Lines: 31 Stephen Smalley wrote: >On Tue, 2005-02-08 at 01:04, Patrick McHardy wrote: > > >>Reception of netlink messages in the kernel happens in the context >>of the sending process, so you can simply call >>audit_get_loginuid(current->audit_context) in audit_receive_msg(). >> >> > >Then why does netlink_sendmsg() need to save the effective capability >set of the sender in the control buffer (via security_netlink_send) for >later checking by other receive functions in the kernel (via >security_netlink_recv)? > It looks like it doesn't need to, I guess it was copied from netlink_sendmsg. netlink transmission to userspace is asynchronous, some values need to be saved, but userspace->kernel transmission is synchronous. >What prevents audit_receive() or other similar >receive functions in the kernel from processing messages sent by >multiple senders? > Multiple messages from multiple senders are handled by multiple calls to the input function. Check netlink_kernel_create() and netlink_data_ready(). Regards Patrick From SRS0+82e7ec0dfb2075e7ad12+535+infradead.org+dwmw2@pentafluge.srs.infradead.org Wed Feb 9 06:17:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 06:17:10 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19EH5VB027653 for ; Wed, 9 Feb 2005 06:17:06 -0800 Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1CyseM-00043F-Im; Wed, 09 Feb 2005 14:17:04 +0000 Subject: Re: [PATCH] Add audit uid to netlink credentials From: David Woodhouse To: Linux Audit Discussion Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> Content-Type: text/plain; charset=UTF-8 Date: Wed, 09 Feb 2005 14:17:00 +0000 Message-Id: <1107958621.19262.524.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 1045 Lines: 26 On Fri, 2005-02-04 at 10:58 -0600, Serge E. Hallyn wrote: > Most audit control messages are sent over netlink. In order to properly > log the identity of the sender of audit control messages, we would like > to add the loginuid to the netlink_creds structure, as per the attached > patch. I think it would be better to leave the loginuid in the payload of the audit packets, not put it into generic netlink structures. In the common case where audit messages are being generated by the kernel, the loginuid can be trusted anyway, and doesn't need to be handled by netlink. The only time it's possibly worth verifying it is for the case where userspace is sending AUDIT_USER messages -- for which the process needs CAP_AUDIT_WRITE anyway. And if you're then going to trust the rest of what that process sends, what's wrong with trusting the loginuid which it provides too? Why should it be impossible for a trusted logging dæmon to log actions of another process, running with a loginuid other than the loginuid of the dæmon? -- dwmw2 From kuznet@yakov.inr.ac.ru Wed Feb 9 06:20:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 06:20:24 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j19EKI5O028184 for ; Wed, 9 Feb 2005 06:20:19 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=e2eNsy0m7DMIFDn5T451MTgqFLTsLrUM06Ycc8Q4HV2Rq8MXAZSLcS5dwo+Sl3atI3Y3rUBWjBL3djrK1oTPsK/choKRhdGziHOS33kwCLyEyvnFOTW4osrqGC0tE5aSd+7NrqKbub+EcHYysRjzaIYF0n6AZKlbA6JXgnM8IUU=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id RAA28984; Wed, 9 Feb 2005 17:19:46 +0300 Date: Wed, 9 Feb 2005 17:19:46 +0300 From: Alexey Kuznetsov To: Stephen Smalley Cc: Linux Audit Discussion , "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209141945.GA28864@yakov.inr.ac.ru> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1434 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: 757 Lines: 22 Hello! > > Reception of netlink messages in the kernel happens in the context > > of the sending process, so you can simply call > > audit_get_loginuid(current->audit_context) in audit_receive_msg(). > > Then why does netlink_sendmsg() need to save the effective capability Yes, when kernel receives a message, it can be processed in context of another process. This happens with rtnetlink, which queues messages when someone holds netadmin semaphore and processing of backlog happens in context of process which holds the semaphore. Unfortunately, audit uses the same twisted way. Actually, if people expected synchronous processing, it is better to replace if (down_trylock(&audit_netlink_sem)) return; with plain down(&audit_netlink_sem); Alexey From serue@us.ibm.com Wed Feb 9 06:52:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 06:52:44 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19EqVu8029186 for ; Wed, 9 Feb 2005 06:52:40 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j19EqMGj053712 for ; Wed, 9 Feb 2005 09:52:23 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j19EqMX5251684 for ; Wed, 9 Feb 2005 07:52:22 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j19EqLXO004096 for ; Wed, 9 Feb 2005 07:52:22 -0700 Received: from serge (serge.austin.ibm.com [9.53.94.132]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j19EqLK1004076; Wed, 9 Feb 2005 07:52:21 -0700 Subject: Re: [PATCH] Add audit uid to netlink credentials From: Serge Hallyn To: Linux Audit Discussion Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <1107958621.19262.524.camel@hades.cambridge.redhat.com> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> Content-Type: text/plain Date: Wed, 09 Feb 2005 08:50:59 -0600 Message-Id: <1107960659.4837.9.camel@serge> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: serue@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 650 Lines: 19 On Wed, 2005-02-09 at 14:17 +0000, David Woodhouse wrote: > The only time it's possibly worth verifying it is for the case where > userspace is sending AUDIT_USER messages -- for which the process needs > CAP_AUDIT_WRITE anyway. CAP_AUDIT_WRITE is needed, but not CAP_AUDIT_CONTROL, which is needed to set the loginuid. Of course, an LSM could check at security_netlink_send whether the login_uid in the payload is the same as the real loginuid. Otherwise, we're wasting a (very precious) capability bit. In either case, have we decided we don't want it in the netlink credentials after all? thanks, -serge -- Serge Hallyn From kuznet@yakov.inr.ac.ru Wed Feb 9 08:49:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 08:49:53 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j19Gngqq003158 for ; Wed, 9 Feb 2005 08:49:43 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=qq4IXgwPd3IzlWGhnenAzjGa2ndGcHXvZ8ZQLEmr5EKXCS36ao1pZLdstWMxZZ3WVDyax47a/ZPlFibKm+tV87zqYkwNHnaFSLnzqh3st//2YyqFXzElFfamDn6r+YXl9BcNzQeV86m1EnywvjaEsT8oQHBDd6Yt2SqrhdfPkQo=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id TAA30034; Wed, 9 Feb 2005 19:49:29 +0300 Date: Wed, 9 Feb 2005 19:49:29 +0300 From: Alexey Kuznetsov To: Alexey Kuznetsov Cc: Stephen Smalley , Linux Audit Discussion , "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209164929.GA30007@yakov.inr.ac.ru> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> <20050209141945.GA28864@yakov.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209141945.GA28864@yakov.inr.ac.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1436 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: 196 Lines: 11 Hello! > if (down_trylock(&audit_netlink_sem)) > return; > > with plain down(&audit_netlink_sem); I am sorry, this is wrong. Dequeue may happen in another process context in any case. Alexey From sds@epoch.ncsc.mil Wed Feb 9 10:30:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:30:48 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19IUg5j013453 for ; Wed, 9 Feb 2005 10:30:42 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j19IRZQY022780; Wed, 9 Feb 2005 18:27:35 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j19IU6RH020129; Wed, 9 Feb 2005 13:30:06 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Linux Audit Discussion Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <1107960659.4837.9.camel@serge> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> Content-Type: text/plain Organization: National Security Agency Message-Id: <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 09 Feb 2005 13:23:01 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 950 Lines: 23 On Wed, 2005-02-09 at 09:50, Serge Hallyn wrote: > CAP_AUDIT_WRITE is needed, but not CAP_AUDIT_CONTROL, which is needed to > set the loginuid. Of course, an LSM could check at > security_netlink_send whether the login_uid in the payload is the same > as the real loginuid. Otherwise, we're wasting a (very precious) > capability bit. > > In either case, have we decided we don't want it in the netlink > credentials after all? If the audit subsystem truly needs to include the loginuid in audit messages generated upon processing netlink messages, then I think it belongs in the control buffer as per your patch. Alexey has confirmed that we cannot use the current task's audit context regardless. As a side bar, a similar security field in the control buffer would likewise be very useful so that SELinux could set the SID for use in permission checks by receive functions. -- Stephen Smalley National Security Agency From oxymoron@waste.org Wed Feb 9 10:32:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:32:35 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19IWQCJ013796 for ; Wed, 9 Feb 2005 10:32:30 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j19IWJuo028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Feb 2005 12:32:19 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j19IWJMU028785; Wed, 9 Feb 2005 12:32:19 -0600 Date: Wed, 9 Feb 2005 10:32:19 -0800 From: Matt Mackall To: "David S. Miller" , Jeff Moyer Cc: netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050209183219.GA2366@waste.org> References: <20050208201634.03074349.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050208201634.03074349.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1438 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: 1114 Lines: 30 On Tue, Feb 08, 2005 at 08:16:34PM -0800, David S. Miller wrote: > > Consider a NAPI device currently executing it's poll function, > pushing SKBs into the networking stack. > > Some of these will generate response packets etc. > > If for some reason a printk() is generated by the packet processing > and: > > 1) the netconsole output device is the same as the NAPI device > processing packets > > 2) netif_queue_stopped() is true because the tx queue is full > > the netpoll code will recurse back into the driver's poll function. > This is incredibly illegal and results in all kinds of driver state > corruption. ->poll() must execute only once at a time. On closer inspection, there's a couple other related failure cases with the new ->poll logic in netpoll. I'm afraid it looks like CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock on netpoll-enabled devices. This will mean putting a pointer to struct netpoll in struct net_device (which I should have done in the first place) and will take a few patches to sort out. -- Mathematics is the supreme nostalgia of our time. From chrisw@osdl.org Wed Feb 9 10:38:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:38:19 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19IcDY1014526 for ; Wed, 9 Feb 2005 10:38:13 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j19Ibll19248; Wed, 9 Feb 2005 10:37:47 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j19Iblw21378; Wed, 9 Feb 2005 10:37:47 -0800 Date: Wed, 9 Feb 2005 10:37:47 -0800 From: Chris Wright To: Linux Audit Discussion Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209103747.Y24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil>; from sds@epoch.ncsc.mil on Wed, Feb 09, 2005 at 01:23:01PM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1354 Lines: 30 * Stephen Smalley (sds@epoch.ncsc.mil) wrote: > On Wed, 2005-02-09 at 09:50, Serge Hallyn wrote: > > CAP_AUDIT_WRITE is needed, but not CAP_AUDIT_CONTROL, which is needed to > > set the loginuid. Of course, an LSM could check at > > security_netlink_send whether the login_uid in the payload is the same > > as the real loginuid. Otherwise, we're wasting a (very precious) > > capability bit. > > > > In either case, have we decided we don't want it in the netlink > > credentials after all? > > If the audit subsystem truly needs to include the loginuid in audit > messages generated upon processing netlink messages, then I think it > belongs in the control buffer as per your patch. Alexey has confirmed > that we cannot use the current task's audit context regardless. > > As a side bar, a similar security field in the control buffer would > likewise be very useful so that SELinux could set the SID for use in > permission checks by receive functions. This means sendmsg hook would set the SID? And in that case, you'd stomp on loginuid for audit messages unless they are special cased. The loginuid is special case to audit, it doesn't make sense to me that it is in generic netlink_skb_parms structure unless it's used by more netlink users. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From sds@epoch.ncsc.mil Wed Feb 9 10:48:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:48:32 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19ImRw3015249 for ; Wed, 9 Feb 2005 10:48:28 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j19IjLQY024960; Wed, 9 Feb 2005 18:45:22 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j19IlqRH020218; Wed, 9 Feb 2005 13:47:53 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Linux Audit Discussion Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050209103747.Y24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 09 Feb 2005 13:40:48 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 1234 Lines: 27 On Wed, 2005-02-09 at 13:37, Chris Wright wrote: > This means sendmsg hook would set the SID? And in that case, you'd > stomp on loginuid for audit messages unless they are special cased. I was referring to a separate field for use by security modules, not re-use of the same field being proposed for the loginuid. Yes, it would be set by the security_netlink_send hook. The principal problem with such a security field is that unless we mandate it to be a simple integer value (like a SELinux SID), we have to deal with lifecycle management for it, i.e. a set of hooks that starts to look like the sk_buff security hooks from the old LSM patch. But if we can limit it to a simple value, then it would be useful for such security identifiers, and allow receiver-side permission checks based on the sender SID. > The loginuid is special case to audit, it doesn't make sense to me that > it is in generic netlink_skb_parms structure unless it's used by more > netlink users. So you also think it should be in the payload? That would require security_netlink_send to dig into the payload if we wanted to control who can specify other loginuids, as Serge noted. -- Stephen Smalley National Security Agency From kaber@trash.net Wed Feb 9 10:52:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:52:36 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19IqWmx015782 for ; Wed, 9 Feb 2005 10:52:32 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1Cywwj-00034b-No; Wed, 09 Feb 2005 19:52:17 +0100 Message-ID: <420A5BE1.4000003@trash.net> Date: Wed, 09 Feb 2005 19:52:17 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Alexey Kuznetsov CC: Stephen Smalley , Linux Audit Discussion , "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] Add audit uid to netlink credentials References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> <20050209141945.GA28864@yakov.inr.ac.ru> <20050209164929.GA30007@yakov.inr.ac.ru> In-Reply-To: <20050209164929.GA30007@yakov.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 577 Lines: 24 Alexey Kuznetsov wrote: >Hello! > > > >>if (down_trylock(&audit_netlink_sem)) >> return; >> >>with plain down(&audit_netlink_sem); >> > >I am sorry, this is wrong. Dequeue may happen in another process context >in any case. > Could you explain how this can happen ? From what I can see whenever data is queued to the receive queue the input function is called immediately through sk->sk_data_ready() -> netlink_data_ready() -> nlk->data_ready() and processes all queued packets, except in the case you pointed out, when audit_netlink_sem is already taken. Regards Patrick From shemminger@osdl.org Wed Feb 9 10:59:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 10:59:35 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19IxUJa016338 for ; Wed, 9 Feb 2005 10:59:30 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j19Iwvl22592; Wed, 9 Feb 2005 10:59:00 -0800 Date: Wed, 9 Feb 2005 10:59:09 -0800 From: Stephen Hemminger To: Hubert Tonneau Cc: Francois Romieu , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050209105909.17da40a9@dxpl.pdx.osdl.net> In-Reply-To: <050QTJA12@server5.heliogroup.fr> References: <050QTJA12@server5.heliogroup.fr> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1442 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: 1193 Lines: 36 Please try this patch, based on Alexey's suggestion: > That's one quick and simple idea: set PSH on each tso segment. > Seems, it is always good. Hardware will preserve it only on the last skb and > everyone will be happy. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/09 11:00:57-08:00 shemminger@linux.site # Always set PUSH on TSO multi-segment frames # to workaround bugs in MacOSX # # net/ipv4/tcp_output.c # 2005/02/09 11:00:44-08:00 shemminger@linux.site +8 -0 # Always set PUSH on TSO multi-segment frames # to workaround bugs in MacOSX # diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2005-02-09 11:01:12 -08:00 +++ b/net/ipv4/tcp_output.c 2005-02-09 11:01:12 -08:00 @@ -754,6 +754,14 @@ break; } + /* Force push to be on for any large TSO frames + * to workaround problems with busted implementations + * like MacOSX that hold off delivery of data until + * push. + */ + if (tcp_skb_pcount(skb) > 1) + TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; + TCP_SKB_CB(skb)->when = tcp_time_stamp; if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) break; From sds@epoch.ncsc.mil Wed Feb 9 11:01:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 11:01:24 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19J1KpA016910 for ; Wed, 9 Feb 2005 11:01:20 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j19IwIQY026416; Wed, 9 Feb 2005 18:58:18 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j19J0nRH020334; Wed, 9 Feb 2005 14:00:49 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Patrick McHardy Cc: Alexey Kuznetsov , Linux Audit Discussion , "Serge E. Hallyn" , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <420A5BE1.4000003@trash.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107956079.17568.42.camel@moss-spartans.epoch.ncsc.mil> <20050209141945.GA28864@yakov.inr.ac.ru> <20050209164929.GA30007@yakov.inr.ac.ru> <420A5BE1.4000003@trash.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1107975224.17568.119.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 09 Feb 2005 13:53:44 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 595 Lines: 14 On Wed, 2005-02-09 at 13:52, Patrick McHardy wrote: > Could you explain how this can happen ? From what I can see whenever data > is queued to the receive queue the input function is called immediately > through sk->sk_data_ready() -> netlink_data_ready() -> nlk->data_ready() > and processes all queued packets, except in the case you pointed out, > when audit_netlink_sem is already taken. More packets may be queued by another sender while audit_receive() is still processing the original one, so it will process them too. -- Stephen Smalley National Security Agency From leonid.grossman@neterion.com Wed Feb 9 11:30:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 11:31:01 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19JUutt018468 for ; Wed, 9 Feb 2005 11:30:57 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j19JUodG006116 for ; Wed, 9 Feb 2005 14:30:50 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j19JUmDD002523 for ; Wed, 9 Feb 2005 14:30:49 -0500 (EST) Message-Id: <200502091930.j19JUmDD002523@guinness.s2io.com> From: "Leonid Grossman" To: Subject: RE: [PATCH] net/s2io: replace schedule_timeout() with msleep() Date: Wed, 9 Feb 2005 11:29:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUO3EALlrUlYQfnRZ6iihyJAudFyAAAMFogAAAnY1A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 7686 Lines: 252 Please ignore this, it should not have gone to the list :-) Leonid > -----Original Message----- > From: Leonid Grossman [mailto:leonid.grossman@s2io.com] > Sent: Wednesday, February 09, 2005 11:26 AM > To: 'Ravinandan Arakali'; 'Dmitry Yusupov' > Cc: 'netdev@oss.sgi.com' > Subject: FW: [PATCH] net/s2io: replace schedule_timeout() > with msleep() > > Hi guys, > What is the difference between linux-net@vger.kernel.org and > netdev@oss.sgi.com lists? > How to subscribe for the former? > > Best, Leonid > > -----Original Message----- > From: Nishanth Aravamudan [mailto:nacc@us.ibm.com] > Sent: Wednesday, February 09, 2005 11:19 AM > To: akpm@osdl.org; jgarzik@pobox.com > Cc: linux-net@vger.kernel.org; Ravinandan Arakali; > 'Raghavendra Koushik'; kernel-janitors@lists.osdl.org; > leonid.grossman@neterion.com > Subject: [PATCH] net/s2io: replace schedule_timeout() with msleep() > > On Wed, Feb 09, 2005 at 10:37:59AM -0800, Ravinandan Arakali wrote: > > Nishanth, > > We did some basic testing after applying your patch and it > seems okay. > > Pls submit the patch to maintainer. But I've couple of comments on > > your patch. > > The below code change is incorrect. It should be msleep(500). > > > @@ -3808,8 +3797,7 @@ static int s2io_rldram_test(nic_t * sp, > > > val64 = readq(&bar0->mc_rldram_test_ctrl); > > > if (val64 & MC_RLDRAM_TEST_DONE) > > > break; > > > - set_current_state(TASK_UNINTERRUPTIBLE); > > > - schedule_timeout(HZ / 2); > > > + msleep(200); > > > > In the function s2io_ethtool_idnic(), call to > schedule_timeout() has > > not been replaced with msleep(). I've given below the code change I > > did before testing. > > > > @@ -3284,11 +3277,10 @@ > > sp->id_timer.data = (unsigned long) sp; > > } > > mod_timer(&sp->id_timer, jiffies); > > - set_current_state(TASK_INTERRUPTIBLE); > > if (data) > > - schedule_timeout(data * HZ); > > + msleep(data*1000); > > else > > - schedule_timeout(MAX_SCHEDULE_TIMEOUT); > > + msleep(0xFFFFFFFF); > > del_timer_sync(&sp->id_timer); > > > > if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) { > > Both changes have been committed in the patch below. > > Andrew/Jeff, please consider committing to the networking > stack of patches. > > Thanks, > Nish > > Description: Use msleep() instead of schedule_timeout() to > guarantee the task delays as expected. This makes the code > independent of HZ values (particularly important when HZ > changes or is dynamic). Compile- and boot-tested. > > Signed-off-by: Nishanth Aravamudan > Acked-by: Ravinandan Arakali > > --- 2.6.11-rc3-v/drivers/net/s2io.c 2005-02-08 > 17:08:37.000000000 -0800 > +++ 2.6.11-rc3/drivers/net/s2io.c 2005-02-09 > 11:08:48.000000000 -0800 > @@ -698,8 +698,7 @@ static int init_nic(struct s2io_nic *nic > val64 = 0; > writeq(val64, &bar0->sw_reset); > val64 = readq(&bar0->sw_reset); > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 2); > + msleep(500); > > /* Enable Receiving broadcasts */ > add = &bar0->mac_cfg; > @@ -952,8 +951,7 @@ static int init_nic(struct s2io_nic *nic > dev->name); > return -1; > } > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > time++; > } > > @@ -991,8 +989,7 @@ static int init_nic(struct s2io_nic *nic > return -1; > } > time++; > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > } > > /* > @@ -1421,8 +1418,7 @@ static int start_nic(struct s2io_nic *ni > SPECIAL_REG_WRITE(val64, &bar0->mc_rldram_mrs, UF); > val64 = readq(&bar0->mc_rldram_mrs); > > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 10); /* Delay by around 100 ms. */ > + msleep(100); /* Delay by around 100 ms. */ > > /* Enabling ECC Protection. */ > val64 = readq(&bar0->adapter_control); @@ -2437,8 > +2433,7 @@ int wait_for_cmd_complete(nic_t * sp) > ret = SUCCESS; > break; > } > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > if (cnt++ > 10) > break; > } > @@ -2477,15 +2472,13 @@ void s2io_reset(nic_t * sp) > * As of now I'am just giving a 250ms delay and hoping that the > * PCI write to sw_reset register is done by this time. > */ > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 4); > + msleep(250); > > /* Restore the PCI state saved during initializarion. */ > pci_restore_state(sp->pdev); > s2io_init_pci(sp); > > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 4); > + msleep(250); > > /* SXE-002: Configure link and activity LED to turn it off */ > subid = sp->pdev->subsystem_device; > @@ -3298,11 +3291,10 @@ static int s2io_ethtool_idnic(struct net > sp->id_timer.data = (unsigned long) sp; > } > mod_timer(&sp->id_timer, jiffies); > - set_current_state(TASK_INTERRUPTIBLE); > if (data) > - schedule_timeout(data * HZ); > + msleep(data * 1000); > else > - schedule_timeout(MAX_SCHEDULE_TIMEOUT); > + msleep(0xFFFFFFFF); > del_timer_sync(&sp->id_timer); > > if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) { @@ > -3405,8 +3397,7 @@ static int read_eeprom(nic_t * sp, int o > ret = 0; > break; > } > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > exit_cnt++; > } > > @@ -3446,8 +3437,7 @@ static int write_eeprom(nic_t * sp, int > ret = 0; > break; > } > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > exit_cnt++; > } > > @@ -3703,8 +3693,7 @@ static int s2io_bist_test(nic_t * sp, ui > ret = 0; > break; > } > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 10); > + msleep(100); > cnt++; > } > > @@ -3805,8 +3794,7 @@ static int s2io_rldram_test(nic_t * sp, > val64 = readq(&bar0->mc_rldram_test_ctrl); > if (val64 & MC_RLDRAM_TEST_DONE) > break; > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 5); > + msleep(200); > } > > if (cnt == 5) > @@ -3822,8 +3810,7 @@ static int s2io_rldram_test(nic_t * sp, > val64 = readq(&bar0->mc_rldram_test_ctrl); > if (val64 & MC_RLDRAM_TEST_DONE) > break; > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 2); > + msleep(500); > } > > if (cnt == 5) > @@ -4183,8 +4170,7 @@ static void s2io_set_link(unsigned long > * Allow a small delay for the NICs self initiated > * cleanup to complete. > */ > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 10); > + msleep(100); > > val64 = readq(&bar0->adapter_status); > if (verify_xena_quiescence(val64, > nic->device_enabled_once)) { @@ -4238,10 +4224,8 @@ static > void s2io_card_down(nic_t * sp) > register u64 val64 = 0; > > /* If s2io_set_link task is executing, wait till it > completes. */ > - while (test_and_set_bit(0, &(sp->link_state))) { > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > - } > + while (test_and_set_bit(0, &(sp->link_state))) > + msleep(50); > atomic_set(&sp->card_state, CARD_DOWN); > > /* disable Tx and Rx traffic on the NIC */ @@ -4257,8 > +4241,7 @@ static void s2io_card_down(nic_t * sp) > break; > } > > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(HZ / 20); > + msleep(50); > cnt++; > if (cnt == 10) { > DBG_PRINT(ERR_DBG, > From davem@davemloft.net Wed Feb 9 12:02:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:02:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19K2Xj4019459 for ; Wed, 9 Feb 2005 12:02:36 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cyy29-0005rg-00; Wed, 09 Feb 2005 12:01:57 -0800 Date: Wed, 9 Feb 2005 12:01:57 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Message-Id: <20050209120157.18dc75c1.davem@davemloft.net> In-Reply-To: <420A1011.1030602@einar-lueck.de> References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j19K2Xj4019459 X-archive-position: 1445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1004 Lines: 21 On Wed, 09 Feb 2005 14:28:49 +0100 Einar Lück wrote: > The scenarios we have in mind are setups in which a set of collaborating > servers steadly establish connections among each other with a very high rate. > This high rate requirement drove us to consider the inclusion of all > alternative routes into the routing cache because the corresponding delay > for each connection establishment is low and the load is balanced over all > available routes. That's why we did not consider a slow lookup in the fib > for each connection established. So essentially you want per-flow multipathing. Except that you're implementation is over-optimizing it to the point where it's only per-flow for your specific case where the connections are short lived and high rate. This hurts long lasting connections. So I'm pretty much against this change. Do it right by making it occur per-connection attempt, it's not my problem to figure out how to do that efficiently, it's your's :-) From lkml@einar-lueck.de Wed Feb 9 12:23:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:23:41 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19KNZq4023771 for ; Wed, 9 Feb 2005 12:23:36 -0800 Received: (qmail 14458 invoked from network); 9 Feb 2005 20:23:34 -0000 Received: from unknown (HELO [192.168.30.10]) (008508@[217.231.185.147]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 9 Feb 2005 20:23:34 -0000 Message-ID: <420A715D.7050106@einar-lueck.de> Date: Wed, 09 Feb 2005 21:23:57 +0100 From: =?ISO-8859-1?Q?Einar_L=FCck?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> <20050209120157.18dc75c1.davem@davemloft.net> In-Reply-To: <20050209120157.18dc75c1.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lkml@einar-lueck.de Precedence: bulk X-list: netdev Content-Length: 933 Lines: 18 David S. Miller wrote: > So essentially you want per-flow multipathing. Except that you're implementation > is over-optimizing it to the point where it's only per-flow for your specific > case where the connections are short lived and high rate. > > This hurts long lasting connections. > > So I'm pretty much against this change. Do it right by making it occur > per-connection attempt, it's not my problem to figure out how to do that > efficiently, it's your's :-) We do not want per-flow multipathing. We want per connection multipathing with fast route lookups (that's why we have all routes in the cache). That is exactly what we implemented. Our tests prove that a connection keeps its route as long as it lives (the dstentry remains associated with the socket). That's why I do not really understand why our approach hurts long lasting connections in any way. Can you explain your point more precisely? Regards, Einar. From davem@davemloft.net Wed Feb 9 12:26:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:26:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19KQ2eZ024277 for ; Wed, 9 Feb 2005 12:26:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyyOc-0005zM-00; Wed, 09 Feb 2005 12:25:10 -0800 Date: Wed, 9 Feb 2005 12:25:09 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050209122509.34dcca2c.davem@davemloft.net> In-Reply-To: <20050209105909.17da40a9@dxpl.pdx.osdl.net> References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 159 Lines: 6 On Wed, 9 Feb 2005 10:59:09 -0800 Stephen Hemminger wrote: > Please try this patch, based on Alexey's suggestion: -EBADINDENTATION :-) From davem@davemloft.net Wed Feb 9 12:30:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:30:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19KUeKo024830 for ; Wed, 9 Feb 2005 12:30:40 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyyTM-00060T-00; Wed, 09 Feb 2005 12:30:04 -0800 Date: Wed, 9 Feb 2005 12:30:04 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Message-Id: <20050209123004.2d65e1cf.davem@davemloft.net> In-Reply-To: <420A715D.7050106@einar-lueck.de> References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> <20050209120157.18dc75c1.davem@davemloft.net> <420A715D.7050106@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j19KUeKo024830 X-archive-position: 1448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 911 Lines: 19 On Wed, 09 Feb 2005 21:23:57 +0100 Einar Lück wrote: > We do not want per-flow multipathing. We want per connection > multipathing with fast route lookups (that's why we have all routes in > the cache). That is exactly what we implemented. Our tests prove that > a connection keeps its route as long as it lives (the dstentry remains > associated with the socket). That's why I do not really understand why > our approach hurts long lasting connections in any way. Can you > explain your point more precisely? This was brought up before. It's the case where the system is acting as a router, you have to consider that case and not just the one where the local system is where the connections are originating from. Your trick only works because of how routes are cached per-socket. Once you get into the realm of traffic going through the machine as a router, the trick stops to work. From lkml@einar-lueck.de Wed Feb 9 12:42:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:42:22 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19KgH3N025988 for ; Wed, 9 Feb 2005 12:42:18 -0800 Received: (qmail 17780 invoked from network); 9 Feb 2005 20:42:16 -0000 Received: from unknown (HELO [192.168.30.10]) (008508@[217.231.185.147]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 9 Feb 2005 20:42:16 -0000 Message-ID: <420A75BF.1080106@einar-lueck.de> Date: Wed, 09 Feb 2005 21:42:39 +0100 From: =?ISO-8859-1?Q?Einar_L=FCck?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> <20050209120157.18dc75c1.davem@davemloft.net> <420A715D.7050106@einar-lueck.de> <20050209123004.2d65e1cf.davem@davemloft.net> In-Reply-To: <20050209123004.2d65e1cf.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lkml@einar-lueck.de Precedence: bulk X-list: netdev Content-Length: 713 Lines: 16 David S. Miller wrote: > This was brought up before. It's the case where the system is acting > as a router, you have to consider that case and not just the one where > the local system is where the connections are originating from. > > Your trick only works because of how routes are cached per-socket. > Once you get into the realm of traffic going through the machine as > a router, the trick stops to work. We considered the routing case: in the routing case ip_route_input is called. In this case we just select the first route in the cache which is always the same (we ensure that). Consequently, the routing behaviour is not changed in this case and remains in the way you like it. Regards, Einar. From andre@tomt.net Wed Feb 9 12:45:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 12:45:38 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19KjSq1027284 for ; Wed, 9 Feb 2005 12:45:32 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 6F46B884CF; Wed, 9 Feb 2005 21:45:39 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id C42698853F; Wed, 9 Feb 2005 21:45:35 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 4C38622895; Wed, 9 Feb 2005 21:45:23 +0100 (CET) Message-ID: <420A7663.4060308@tomt.net> Date: Wed, 09 Feb 2005 21:45:23 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> <20050206114145.GA20883@gondor.apana.org.au> <20050206.213018.92031627.yoshfuji@linux-ipv6.org> In-Reply-To: <20050206.213018.92031627.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 388 Lines: 10 YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > Oh, you're right! Thanks. > > How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()? > > Signed-off-by: Hideaki YOSHIFUJI This patch seems to work fine here; cleared out the other patches to be sure. So, herberts first patch fixes it, and so do this one. I have not tried the one in between. From davem@davemloft.net Wed Feb 9 13:17:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 13:17:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19LHoL4028426 for ; Wed, 9 Feb 2005 13:17:50 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CyzCw-0006CF-00; Wed, 09 Feb 2005 13:17:10 -0800 Date: Wed, 9 Feb 2005 13:17:10 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Message-Id: <20050209131710.00315044.davem@davemloft.net> In-Reply-To: <420A75BF.1080106@einar-lueck.de> References: <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> <20050209120157.18dc75c1.davem@davemloft.net> <420A715D.7050106@einar-lueck.de> <20050209123004.2d65e1cf.davem@davemloft.net> <420A75BF.1080106@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j19LHoL4028426 X-archive-position: 1451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 467 Lines: 11 On Wed, 09 Feb 2005 21:42:39 +0100 Einar Lück wrote: > We considered the routing case: in the routing case ip_route_input is called. > In this case we just select the first route in the cache which is always the same > (we ensure that). Consequently, the routing behaviour is not changed in this case and > remains in the way you like it. Indeed. You're right. Let me re-review your second patch with this new understanding in mind :-) From chrisw@osdl.org Wed Feb 9 15:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 15:38:44 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j19NcbjS032562 for ; Wed, 9 Feb 2005 15:38:37 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j19NcHl08235; Wed, 9 Feb 2005 15:38:17 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j19NcGS00391; Wed, 9 Feb 2005 15:38:16 -0800 Date: Wed, 9 Feb 2005 15:38:16 -0800 From: Chris Wright To: Stephen Smalley Cc: Linux Audit Discussion , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209153816.B24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil>; from sds@epoch.ncsc.mil on Wed, Feb 09, 2005 at 01:40:48PM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 2395 Lines: 49 * Stephen Smalley (sds@epoch.ncsc.mil) wrote: > On Wed, 2005-02-09 at 13:37, Chris Wright wrote: > > This means sendmsg hook would set the SID? And in that case, you'd > > stomp on loginuid for audit messages unless they are special cased. > > I was referring to a separate field for use by security modules, not > re-use of the same field being proposed for the loginuid. Yes, it would > be set by the security_netlink_send hook. The principal problem with > such a security field is that unless we mandate it to be a simple > integer value (like a SELinux SID), we have to deal with lifecycle > management for it, i.e. a set of hooks that starts to look like the > sk_buff security hooks from the old LSM patch. But if we can limit it > to a simple value, then it would be useful for such security > identifiers, and allow receiver-side permission checks based on the > sender SID. This makes sense to me. Just an extension of existing eff_cap and would be used by security modules for each netlink packet. > > The loginuid is special case to audit, it doesn't make sense to me that > > it is in generic netlink_skb_parms structure unless it's used by more > > netlink users. > > So you also think it should be in the payload? That would require > security_netlink_send to dig into the payload if we wanted to control > who can specify other loginuids, as Serge noted. I just don't see it making sense to add another credential for a special case. The signal code already peaks into the siginfo struct when queueing a signal to make sure some user isn't trying to send si_code == SI_KERNEL or similar. Perhaps audit could do that with it's own payload during send. No matter how we slice it, it's a special case. Hmm, perhaps we could eliminate the whole asynchronous issue by allowing registration of a netlink link specific security handler. Something like: netlink_kernel_create_sec(unit, rx, sec_handler) Then the check would be done before the packet was ever queued. This would eliminate the if (NETLINK_CREDS(skb)->$cred == bad) on receipt side, and push it to sender side. It would also be link specific so audit could do it's audit payload loginuid check here. I think it would also eliminate SELinux's need to tag the packet for later checking on receipt. Thoughts? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From SRS0+81e737e4e25a4d65e438+536+infradead.org+dwmw2@pentafluge.srs.infradead.org Wed Feb 9 16:01:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 16:01:18 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A0173U000951 for ; Wed, 9 Feb 2005 16:01:12 -0800 Received: from shinybook.infradead.org ([81.187.226.99]) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1Cz1lV-0006c5-3p; Thu, 10 Feb 2005 00:01:03 +0000 Subject: Re: [PATCH] Add audit uid to netlink credentials From: David Woodhouse To: Linux Audit Discussion Cc: Stephen Smalley , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050209153816.B24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> Content-Type: text/plain; charset=UTF-8 Date: Wed, 09 Feb 2005 23:56:09 +0000 Message-Id: <1107993369.9154.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 1006 Lines: 22 On Wed, 2005-02-09 at 15:38 -0800, Chris Wright wrote: >> So you also think it should be in the payload? That would require >> security_netlink_send to dig into the payload if we wanted to control >> who can specify other loginuids, as Serge noted. > >I just don't see it making sense to add another credential for a special >case. The signal code already peaks into the siginfo struct when queueing >a signal to make sure some user isn't trying to send si_code == SI_KERNEL >or similar. Perhaps audit could do that with it's own payload during send. >No matter how we slice it, it's a special case. I'm not entirely sure the check is needed anyway. This is a trusted application sending audit messages. Why shouldn't it be permitted to log auditable events which were triggered by someone _else_? If we want to audit the actions of the userspace logging dæmon itself and see what it sends, then we can quite happily do so within the audit framework. That's a _different_ issue, surely? -- dwmw2 From chrisw@osdl.org Wed Feb 9 16:20:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 16:20:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A0K5Iv005019 for ; Wed, 9 Feb 2005 16:20:05 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1A0Jkl15283; Wed, 9 Feb 2005 16:19:46 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1A0JkR01862; Wed, 9 Feb 2005 16:19:46 -0800 Date: Wed, 9 Feb 2005 16:19:46 -0800 From: Chris Wright To: David Woodhouse Cc: Linux Audit Discussion , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209161946.F24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1107993369.9154.2.camel@localhost.localdomain>; from dwmw2@infradead.org on Wed, Feb 09, 2005 at 11:56:09PM +0000 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 947 Lines: 20 * David Woodhouse (dwmw2@infradead.org) wrote: > On Wed, 2005-02-09 at 15:38 -0800, Chris Wright wrote: > >I just don't see it making sense to add another credential for a special > >case. The signal code already peaks into the siginfo struct when queueing > >a signal to make sure some user isn't trying to send si_code == SI_KERNEL > >or similar. Perhaps audit could do that with it's own payload during send. > >No matter how we slice it, it's a special case. > > I'm not entirely sure the check is needed anyway. This is a trusted > application sending audit messages. Why shouldn't it be permitted to log > auditable events which were triggered by someone _else_? Then it comes back to the question of how to protect loginuid. If it can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be write protected by CAP_AUDIT_CONTROL. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From davem@davemloft.net Wed Feb 9 16:47:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 16:47:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A0lbBc005801 for ; Wed, 9 Feb 2005 16:47:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cz2Tz-00077m-00; Wed, 09 Feb 2005 16:46:59 -0800 Date: Wed, 9 Feb 2005 16:46:58 -0800 From: "David S. Miller" To: Matt Mackall Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-Id: <20050209164658.409f8950.davem@davemloft.net> In-Reply-To: <20050209183219.GA2366@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1366 Lines: 33 On Wed, 9 Feb 2005 10:32:19 -0800 Matt Mackall wrote: > On closer inspection, there's a couple other related failure cases > with the new ->poll logic in netpoll. I'm afraid it looks like > CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock > on netpoll-enabled devices. > > This will mean putting a pointer to struct netpoll in struct > net_device (which I should have done in the first place) and will take > a few patches to sort out. Will this ->poll() guarding lock be acquired only in the netpoll code or system-wide? If the latter, this introduced an incredible performance regression for devices using the LLTX locking scheme (ie. the most important high-performance gigabit drivers in the tree use this). Please detail your fix idea so that I can analyze a concrete idea instead of some guess on my part :-) I know you want to do anything except drop the packet. What you may do instead, therefore, is add the packet to the normal device mid-layer queue and kick NET_TX_ACTION if netif_queue_stopped() is true. Sure, the packet still might get dropped in extreme cases, but this idea seems to eliminate all of this locking complexity netpoll is trying to handle. As an aside, ipt_LOG is a great stress test for netpoll, because 4 incoming packets can generate 8 outgoing packets worth of netconsole traffic :-) From chrisw@osdl.org Wed Feb 9 17:11:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 17:11:51 -0800 (PST) Received: from mail.osdl.org (firewall0.osdl.org [65.172.181.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A1BeSE006876 for ; Wed, 9 Feb 2005 17:11:44 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1A1BFl23769; Wed, 9 Feb 2005 17:11:15 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1A1BFX03536; Wed, 9 Feb 2005 17:11:15 -0800 Date: Wed, 9 Feb 2005 17:11:15 -0800 From: Chris Wright To: Chris Wright Cc: Stephen Smalley , netdev@oss.sgi.com, Linux Audit Discussion , davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209171115.G24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050209153816.B24171@build.pdx.osdl.net>; from chrisw@osdl.org on Wed, Feb 09, 2005 at 03:38:16PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 4510 Lines: 123 * Chris Wright (chrisw@osdl.org) wrote: > Hmm, perhaps we could eliminate the whole asynchronous issue by allowing > registration of a netlink link specific security handler. Something like: > > netlink_kernel_create_sec(unit, rx, sec_handler) > > Then the check would be done before the packet was ever queued. This > would eliminate the if (NETLINK_CREDS(skb)->$cred == bad) on receipt > side, and push it to sender side. It would also be link specific so > audit could do it's audit payload loginuid check here. I think it would > also eliminate SELinux's need to tag the packet for later checking on > receipt. Thoughts? Here's an example of what I mean. It's quite rough, doesn't yet eliminate any of the code that it eventually could, and doesn't deal with broadcast. I gave it a quick test with audit netlink, and it does what I expect. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net ===== kernel/audit.c 1.9 vs edited ===== --- 1.9/kernel/audit.c 2005-01-30 22:33:47 -08:00 +++ edited/kernel/audit.c 2005-02-09 17:07:22 -08:00 @@ -333,6 +333,15 @@ static int audit_netlink_ok(kernel_cap_t return err; } +static int audit_check_sender(struct sk_buff *skb) +{ + struct nlmsghdr *nlh = (struct nlmsghdr *)skb->data; + u16 msg_type = nlh->nlmsg_type; + + return audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type); + +} + static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh) { u32 uid, pid, seq; @@ -551,7 +560,7 @@ int __init audit_init(void) { printk(KERN_INFO "audit: initializing netlink socket (%s)\n", audit_default ? "enabled" : "disabled"); - audit_sock = netlink_kernel_create(NETLINK_AUDIT, audit_receive); + audit_sock = netlink_kernel_create_check(NETLINK_AUDIT, audit_receive, audit_check_sender); if (!audit_sock) audit_panic("cannot initialize netlink socket"); ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00 +++ edited/net/netlink/af_netlink.c 2005-02-09 16:39:15 -08:00 @@ -71,6 +71,7 @@ struct netlink_opt struct netlink_callback *cb; spinlock_t cb_lock; void (*data_ready)(struct sock *sk, int bytes); + int (*send_check)(struct sk_buff *skb); }; #define nlk_sk(__sk) ((struct netlink_opt *)(__sk)->sk_protinfo) @@ -639,6 +640,14 @@ int netlink_sendskb(struct sock *sk, str int len = skb->len; nlk = nlk_sk(sk); + + if (nlk->send_check) + if (nlk->send_check(skb)) { + kfree_skb(skb); + sock_put(sk); + return -EPERM; + } + #ifdef NL_EMULATE_DEV if (nlk->handler) { skb_orphan(skb); @@ -1033,7 +1042,8 @@ static void netlink_data_ready(struct so */ struct sock * -netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) +netlink_kernel_create_check(int unit, void (*input)(struct sock *sk, int len), + int (*check)(struct sk_buff *skb)) { struct socket *sock; struct sock *sk; @@ -1053,8 +1063,10 @@ netlink_kernel_create(int unit, void (*i } sk = sock->sk; sk->sk_data_ready = netlink_data_ready; - if (input) + if (input) { nlk_sk(sk)->data_ready = input; + nlk_sk(sk)->send_check = check; + } if (netlink_insert(sk, 0)) { sock_release(sock); @@ -1459,7 +1471,7 @@ MODULE_ALIAS_NETPROTO(PF_NETLINK); EXPORT_SYMBOL(netlink_ack); EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); -EXPORT_SYMBOL(netlink_kernel_create); +EXPORT_SYMBOL(netlink_kernel_create_check); EXPORT_SYMBOL(netlink_register_notifier); EXPORT_SYMBOL(netlink_set_err); EXPORT_SYMBOL(netlink_set_nonroot); ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-06 21:59:39 -08:00 +++ edited/include/linux/netlink.h 2005-02-09 16:36:45 -08:00 @@ -116,7 +116,11 @@ struct netlink_skb_parms #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) -extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern struct sock *netlink_kernel_create_check(int unit, void (*input)(struct sock *sk, int len), int (*check)(struct sk_buff *skb)); +static inline struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) +{ + return netlink_kernel_create_check(unit, input, NULL); +} extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, From oxymoron@waste.org Wed Feb 9 17:11:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 17:11:17 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A1BB4E006777 for ; Wed, 9 Feb 2005 17:11:11 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1A1B4Lb007051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Feb 2005 19:11:04 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j1A1B4gx007047; Wed, 9 Feb 2005 19:11:04 -0600 Date: Wed, 9 Feb 2005 17:11:04 -0800 From: Matt Mackall To: "David S. Miller" Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050210011104.GF2366@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20050209164658.409f8950.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1456 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: 14176 Lines: 501 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 09, 2005 at 04:46:58PM -0800, David S. Miller wrote: > On Wed, 9 Feb 2005 10:32:19 -0800 > Matt Mackall wrote: > > > On closer inspection, there's a couple other related failure cases > > with the new ->poll logic in netpoll. I'm afraid it looks like > > CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock > > on netpoll-enabled devices. > > > > This will mean putting a pointer to struct netpoll in struct > > net_device (which I should have done in the first place) and will take > > a few patches to sort out. > > Will this ->poll() guarding lock be acquired only in the netpoll > code or system-wide? If the latter, this introduced an incredible > performance regression for devices using the LLTX locking scheme > (ie. the most important high-performance gigabit drivers in the > tree use this). The lock will only be taken in net_rx_action iff netpoll is enabled for the given device. Lock contention should be basically nil. Here's my current patch (on top of -mm), which I'm struggling to find an appropriate test box for (my dual box with NAPI got pressed into service as a web server a couple weeks ago). I've attached the other two patches it relies on as well. -------------- Introduce a per-client poll lock and flag. The lock assures we never have more than one caller in dev->poll(). The flag provides recursion avoidance on UP where the lock disappears. Index: mm1npc/include/linux/netpoll.h =================================================================== --- mm1npc.orig/include/linux/netpoll.h 2005-02-09 14:15:12.471051000 -0800 +++ mm1npc/include/linux/netpoll.h 2005-02-09 14:46:22.374083000 -0800 @@ -21,6 +21,8 @@ u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; + spinlock_t poll_lock; + int poll_flag; }; void netpoll_poll(struct netpoll *np); @@ -37,8 +39,27 @@ { return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } + +static inline void netpoll_poll_lock(struct net_device *dev) +{ + if (dev->np) { + spin_lock(&dev->np->poll_lock); + dev->np->poll_flag = 1; + } +} + +static inline void netpoll_poll_unlock(struct net_device *dev) +{ + if (dev->np) { + dev->np->poll_flag = 0; + spin_unlock(&dev->np->poll_lock); + } +} + #else #define netpoll_rx(a) 0 +#define netpoll_poll_lock(a) +#define netpoll_poll_unlock(a) #endif #endif Index: mm1npc/net/core/dev.c =================================================================== --- mm1npc.orig/net/core/dev.c 2005-02-09 14:15:11.236086000 -0800 +++ mm1npc/net/core/dev.c 2005-02-09 14:15:13.710042000 -0800 @@ -1772,6 +1772,7 @@ dev = list_entry(queue->poll_list.next, struct net_device, poll_list); + netpoll_poll_lock(dev); if (dev->quota <= 0 || dev->poll(dev, &budget)) { local_irq_disable(); @@ -1782,9 +1783,11 @@ else dev->quota = dev->weight; } else { + netpoll_poll_unlock(dev); dev_put(dev); local_irq_disable(); } + netpoll_poll_unlock(dev); #ifdef CONFIG_KGDBOE kgdb_process_breakpoint(); Index: mm1npc/net/core/netpoll.c =================================================================== --- mm1npc.orig/net/core/netpoll.c 2005-02-09 14:15:12.466070000 -0800 +++ mm1npc/net/core/netpoll.c 2005-02-09 14:48:44.506107000 -0800 @@ -36,7 +36,6 @@ static struct sk_buff *skbs; static atomic_t trapped; -static DEFINE_SPINLOCK(netpoll_poll_lock); #define NETPOLL_RX_ENABLED 1 #define NETPOLL_RX_DROP 2 @@ -63,8 +62,15 @@ } /* - * Check whether delayed processing was scheduled for our current CPU, - * and then manually invoke NAPI polling to pump data off the card. + * Check whether delayed processing was scheduled for our NIC. If so, + * we attempt to grab the poll lock and use ->poll() to pump the card. + * If this fails, either we've recursed in ->poll() or it's already + * running on another CPU. + * + * Note: we don't mask interrupts with this lock because we're using + * trylock here and interrupts are already disabled in the softirq + * case. Further, we test the poll_flag to avoid recursion on UP + * systems where the lock doesn't exist. * * In cases where there is bi-directional communications, reading only * one message at a time can lead to packets being dropped by the @@ -74,13 +80,9 @@ static void poll_napi(struct netpoll *np) { int budget = 16; - unsigned long flags; - struct softnet_data *queue; - spin_lock_irqsave(&netpoll_poll_lock, flags); - queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && - !list_empty(&queue->poll_list)) { + !np->poll_flag && spin_trylock(&np->poll_lock)) { np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); @@ -88,8 +90,8 @@ atomic_dec(&trapped); np->rx_flags &= ~NETPOLL_RX_DROP; + spin_unlock(&np->poll_lock); } - spin_unlock_irqrestore(&netpoll_poll_lock, flags); } void netpoll_poll(struct netpoll *np) @@ -276,7 +278,6 @@ int size, type = ARPOP_REPLY, ptype = ETH_P_ARP; u32 sip, tip; struct sk_buff *send_skb; - unsigned long flags; struct netpoll *np = skb->dev->np; if (!np) return; @@ -360,7 +361,7 @@ int proto, len, ulen; struct iphdr *iph; struct udphdr *uh; - struct netpoll *np; + struct netpoll *np = skb->dev->np; if (!np->rx_hook) goto out; @@ -618,6 +619,7 @@ if(np->rx_hook) np->rx_flags = NETPOLL_RX_ENABLED; + np->poll_lock = SPIN_LOCK_UNLOCKED; np->dev = ndev; ndev->np = np; > I know you want to do anything except drop the packet. What you > may do instead, therefore, is add the packet to the normal device > mid-layer queue and kick NET_TX_ACTION if netif_queue_stopped() is > true. Actually, I think it's better to keep the midlayer out of it. Netpoll clients like netdump and kgdb basically stop the machine so queueing to avoid deadlock is just not going to work. > As an aside, ipt_LOG is a great stress test for netpoll, because 4 > incoming packets can generate 8 outgoing packets worth of netconsole > traffic :-) -- Mathematics is the supreme nostalgia of our time. --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netpoll-helpers.patch" Add netpoll rx helpers Move skb_free for rx into __netpoll_rx Index: mm1/net/core/netpoll.c =================================================================== --- mm1.orig/net/core/netpoll.c 2005-02-09 10:51:43.000000000 -0800 +++ mm1/net/core/netpoll.c 2005-02-09 11:36:15.000000000 -0800 @@ -368,7 +368,7 @@ netpoll_send_skb(np, send_skb); } -int netpoll_rx(struct sk_buff *skb) +int __netpoll_rx(struct sk_buff *skb) { int proto, len, ulen; struct iphdr *iph; @@ -440,12 +440,18 @@ (char *)(uh+1), ulen - sizeof(struct udphdr)); + kfree_skb(skb); return 1; } spin_unlock_irqrestore(&rx_list_lock, flags); out: - return atomic_read(&trapped); + if (atomic_read(&trapped)) { + kfree_skb(skb); + return 1; + } + + return 0; } int netpoll_parse_options(struct netpoll *np, char *opt) Index: mm1/include/linux/netpoll.h =================================================================== --- mm1.orig/include/linux/netpoll.h 2005-02-09 10:40:59.000000000 -0800 +++ mm1/include/linux/netpoll.h 2005-02-09 11:36:15.000000000 -0800 @@ -30,7 +30,15 @@ int netpoll_trap(void); void netpoll_set_trap(int trap); void netpoll_cleanup(struct netpoll *np); -int netpoll_rx(struct sk_buff *skb); +int __netpoll_rx(struct sk_buff *skb); +#ifdef CONFIG_NETPOLL +static inline int netpoll_rx(struct sk_buff *skb) +{ + return skb->dev->netpoll_rx && __netpoll_rx(skb); +} +#else +#define netpoll_rx(a) 0 +#endif #endif Index: mm1/net/core/dev.c =================================================================== --- mm1.orig/net/core/dev.c 2005-02-09 10:40:59.000000000 -0800 +++ mm1/net/core/dev.c 2005-02-09 11:36:20.000000000 -0800 @@ -1425,13 +1425,10 @@ struct softnet_data *queue; unsigned long flags; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && netpoll_rx(skb)) { - kfree_skb(skb); + /* if netpoll wants it, pretend we never saw it */ + if (netpoll_rx(skb)) return NET_RX_DROP; - } -#endif - + if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); @@ -1627,12 +1624,9 @@ int ret = NET_RX_DROP; unsigned short type; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && skb->dev->poll && netpoll_rx(skb)) { - kfree_skb(skb); + /* if we've gotten here through NAPI, check netpoll */ + if (skb->dev->poll && netpoll_rx(skb)) return NET_RX_DROP; - } -#endif if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netpoll-in-dev.patch" Add struct netpoll pointer to struct netdevice Move netpoll rx flags to netpoll struct Stop traversing rx_list and get np pointer from skb->dev->np Remove now unneeded rx_list Index: mm1/include/linux/netdevice.h =================================================================== --- mm1.orig/include/linux/netdevice.h 2005-02-09 11:36:15.000000000 -0800 +++ mm1/include/linux/netdevice.h 2005-02-09 11:36:39.000000000 -0800 @@ -41,7 +41,7 @@ struct divert_blk; struct vlan_group; struct ethtool_ops; - +struct netpoll; /* source back-compat hooks */ #define SET_ETHTOOL_OPS(netdev,ops) \ ( (netdev)->ethtool_ops = (ops) ) @@ -471,7 +471,7 @@ int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); int (*accept_fastpath)(struct net_device *, struct dst_entry*); #ifdef CONFIG_NETPOLL - int netpoll_rx; + struct netpoll *np; #endif #ifdef CONFIG_NET_POLL_CONTROLLER void (*poll_controller)(struct net_device *dev); Index: mm1/net/core/netpoll.c =================================================================== --- mm1.orig/net/core/netpoll.c 2005-02-09 11:36:15.000000000 -0800 +++ mm1/net/core/netpoll.c 2005-02-09 11:37:38.000000000 -0800 @@ -35,9 +35,6 @@ static int nr_skbs; static struct sk_buff *skbs; -static DEFINE_SPINLOCK(rx_list_lock); -static LIST_HEAD(rx_list); - static atomic_t trapped; static DEFINE_SPINLOCK(netpoll_poll_lock); @@ -84,13 +81,13 @@ queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && !list_empty(&queue->poll_list)) { - np->dev->netpoll_rx |= NETPOLL_RX_DROP; + np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); np->dev->poll(np->dev, &budget); atomic_dec(&trapped); - np->dev->netpoll_rx &= ~NETPOLL_RX_DROP; + np->rx_flags &= ~NETPOLL_RX_DROP; } spin_unlock_irqrestore(&netpoll_poll_lock, flags); } @@ -280,17 +277,7 @@ u32 sip, tip; struct sk_buff *send_skb; unsigned long flags; - struct list_head *p; - struct netpoll *np = NULL; - - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if ( np->dev == skb->dev ) - break; - np = NULL; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + struct netpoll *np = skb->dev->np; if (!np) return; @@ -374,9 +361,9 @@ struct iphdr *iph; struct udphdr *uh; struct netpoll *np; - struct list_head *p; - unsigned long flags; + if (!np->rx_hook) + goto out; if (skb->dev->type != ARPHRD_ETHER) goto out; @@ -420,30 +407,19 @@ goto out; if (checksum_udp(skb, uh, ulen, iph->saddr, iph->daddr) < 0) goto out; + if (np->local_ip && np->local_ip != ntohl(iph->daddr)) + goto out; + if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) + goto out; + if (np->local_port && np->local_port != ntohs(uh->dest)) + goto out; - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if (np->dev && np->dev != skb->dev) - continue; - if (np->local_ip && np->local_ip != ntohl(iph->daddr)) - continue; - if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) - continue; - if (np->local_port && np->local_port != ntohs(uh->dest)) - continue; - - spin_unlock_irqrestore(&rx_list_lock, flags); - - if (np->rx_hook) - np->rx_hook(np, ntohs(uh->source), - (char *)(uh+1), - ulen - sizeof(struct udphdr)); + np->rx_hook(np, ntohs(uh->source), + (char *)(uh+1), + ulen - sizeof(struct udphdr)); - kfree_skb(skb); - return 1; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + kfree_skb(skb); + return 1; out: if (atomic_read(&trapped)) { @@ -639,17 +615,11 @@ np->name, HIPQUAD(np->local_ip)); } - np->dev = ndev; - - if(np->rx_hook) { - unsigned long flags; - - np->dev->netpoll_rx = NETPOLL_RX_ENABLED; - spin_lock_irqsave(&rx_list_lock, flags); - list_add(&np->rx_list, &rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } + if(np->rx_hook) + np->rx_flags = NETPOLL_RX_ENABLED; + np->dev = ndev; + ndev->np = np; return 0; release: @@ -659,16 +629,8 @@ void netpoll_cleanup(struct netpoll *np) { - if (np->rx_hook) { - unsigned long flags; - - spin_lock_irqsave(&rx_list_lock, flags); - list_del(&np->rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } - if (np->dev) - np->dev->netpoll_rx = 0; + np->dev->np = NULL; dev_put(np->dev); np->dev = NULL; } Index: mm1/include/linux/netpoll.h =================================================================== --- mm1.orig/include/linux/netpoll.h 2005-02-09 11:36:15.000000000 -0800 +++ mm1/include/linux/netpoll.h 2005-02-09 11:36:39.000000000 -0800 @@ -16,11 +16,11 @@ struct netpoll { struct net_device *dev; char dev_name[16], *name; + int rx_flags; void (*rx_hook)(struct netpoll *, int, char *, int); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; - struct list_head rx_list; }; void netpoll_poll(struct netpoll *np); @@ -35,7 +35,7 @@ #ifdef CONFIG_NETPOLL static inline int netpoll_rx(struct sk_buff *skb) { - return skb->dev->netpoll_rx && __netpoll_rx(skb); + return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } #else #define netpoll_rx(a) 0 --opJtzjQTFsWo+cga-- From dgibson@ozlabs.org Wed Feb 9 18:53:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 18:53:53 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A2rksq009895 for ; Wed, 9 Feb 2005 18:53:46 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 182E367A8F; Thu, 10 Feb 2005 13:53:38 +1100 (EST) Date: Thu, 10 Feb 2005 13:53:33 +1100 From: David Gibson To: Jeff Garzik Cc: orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [0/8] orinoco driver updates Message-ID: <20050210025333.GE5324@localhost.localdomain> Mail-Followup-To: Jeff Garzik , orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050112052352.GA30426@localhost.localdomain> <4200316F.7030401@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4200316F.7030401@pobox.com> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1300 Lines: 30 On Tue, Feb 01, 2005 at 08:48:31PM -0500, Jeff Garzik wrote: > David Gibson wrote: > >Following are a bunch of patches which make a few more steps towards > >the long overdue merge of the CVS orinoco driver into mainline. These > >do make behavioural changes to the driver, but they should all be > >trivial and largely cosmetic. > > OK, the changes look good, but I was waiting for the previous stuff you > submitted to land in upstream. > > Could I convince you to rediff and resend against the latest 2.6.x snapshot? > > At the time you sent these, they conflicted with a previous cleanup you > had sent, and that I had applied. Ok, I'm a little confused. The last batch were all checked against the then-current netdev-2.6 bk tree, or was the conflict with something you'd applied between when I pulled the tree and you looked at the patches? As far as I can tell all the previous batch of patches I sent you are in netdev (plus a couple from this batch), but most are still not in upstream. I'm now not entirely clear on whether you want patches against the netdev bk, or against Linus bk/snapshots. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From jgarzik@pobox.com Wed Feb 9 19:07:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 19:07:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A37SuG010678 for ; Wed, 9 Feb 2005 19:07:29 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cz4fu-0007QS-3Y; Thu, 10 Feb 2005 03:07:26 +0000 Message-ID: <420ACFDC.9060500@pobox.com> Date: Wed, 09 Feb 2005 22:07:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [0/8] orinoco driver updates References: <20050112052352.GA30426@localhost.localdomain> <4200316F.7030401@pobox.com> <20050210025333.GE5324@localhost.localdomain> In-Reply-To: <20050210025333.GE5324@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1459 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: 195 Lines: 10 David Gibson wrote: > I'm now not entirely clear on whether you want patches against the > netdev bk, or against Linus bk/snapshots. Please send diff'd against vanilla Linus upstream. Jeff From dgibson@ozlabs.org Wed Feb 9 19:23:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 19:23:21 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A3NFPF011682 for ; Wed, 9 Feb 2005 19:23:15 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id B2F1767AB8; Thu, 10 Feb 2005 14:23:09 +1100 (EST) Date: Thu, 10 Feb 2005 14:23:05 +1100 From: David Gibson To: Jeff Garzik Cc: orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [0/8] orinoco driver updates Message-ID: <20050210032305.GF5324@localhost.localdomain> Mail-Followup-To: Jeff Garzik , orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050112052352.GA30426@localhost.localdomain> <4200316F.7030401@pobox.com> <20050210025333.GE5324@localhost.localdomain> <420ACFDC.9060500@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420ACFDC.9060500@pobox.com> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 533 Lines: 16 On Wed, Feb 09, 2005 at 10:07:08PM -0500, Jeff Garzik wrote: > David Gibson wrote: > >I'm now not entirely clear on whether you want patches against the > >netdev bk, or against Linus bk/snapshots. > > > Please send diff'd against vanilla Linus upstream. Ok, in that case do you want me to resend the things which are in netdev but not vanilla? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From werner@almesberger.net Wed Feb 9 20:25:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 20:25:39 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.238] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A4PX5J016587 for ; Wed, 9 Feb 2005 20:25:33 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.12.8/8.9.3) with ESMTP id j1A4ODAS009295; Wed, 9 Feb 2005 20:24:20 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id j1A4N4718628; Thu, 10 Feb 2005 01:23:04 -0300 Date: Thu, 10 Feb 2005 01:23:04 -0300 From: Werner Almesberger To: "David S. Miller" Cc: herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050210012304.E25338@almesberger.net> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204222428.1a13a482.davem@davemloft.net>; from davem@davemloft.net on Fri, Feb 04, 2005 at 10:24:28PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 2140 Lines: 61 David S. Miller wrote: > This document is intended to serve as a guide to Linux port > maintainers on how to implement atomic counter and bitops operations > properly. Finally, some light is shed into one of the most arcane areas of the kernel ;-) Thanks ! > Unlike the above routines, it is required that explicit memory > barriers are performed before and after the operation. It must > be done such that all memory operations before and after the > atomic operation calls are strongly ordered with respect to the > atomic operation itself. Hmm, given that this description will not only be read by implementers of atomic functions, but also by users, the "explicit memory barriers" may be confusing. Who does them, the atomic_* function, or the user ? In fact, I would call them "implicit", because they're hidden in the atomic_foo functions :-) > void smb_mb__before_atomic_dec(void); > void smb_mb__after_atomic_dec(void); > void smb_mb__before_atomic_inc(void); > void smb_mb__after_atomic_dec(void); s/smb_/smp/ :-) Do they also work for atomic_add and atomic_sub, or do we have to fall back to smb_mb or atomic_add_return (see below) there ? > With the memory barrier semantics required of the atomic_t > operations which return values, the above sequence of memory > visibility can never happen. What happens if the operation could return a value, but the user ignores it ? E.g. if I don't like smp_mb__*, could I just use atomic_inc_and_test(foo); instead of smp_mb__before_atomic_inc(); atomic_inc(foo); smp_mb__after_atomic_dec(); ? If yes, is this a good idea ? > These routines, like the atomic_t counter operations returning > values, require explicit memory barrier semantics around their > execution. Very confusing: the barriers aren't around the routines (that is something the user would be doing), but around whatever does the atomic stuff inside them. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From rddunlap@osdl.org Wed Feb 9 20:46:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 20:46:32 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A4kS0W017415 for ; Wed, 9 Feb 2005 20:46:28 -0800 Received: from [192.168.1.103] (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1A4kKuM019593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 9 Feb 2005 20:46:21 -0800 Message-ID: <420AE4E1.7070204@osdl.org> Date: Wed, 09 Feb 2005 20:36:49 -0800 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <420828A9.7060306@osdl.org> <42087751.3040806@linux.intel.com> In-Reply-To: <42087751.3040806@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1462 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: 2909 Lines: 73 James Ketrenos wrote: > Randy.Dunlap wrote: > >> James Ketrenos wrote: >> >>> Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 >>> subsystem used by the ipw2100 and ipw2200 projects. >>> >>> I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 >>> that use thist stack to the list on Monday. >>> >>> In terms of what the stack currently does: >>> >>> * HW independent -- it only knows about 802.11 data and structures >>> * Performs an 802.3 <-> 802.11 transform for data Tx/Rx >>> * Host based support for fragmentation, WEP, and WPA using the >>> kernel's crypto functions >>> * Beacon and probe response collection and parsing >>> * Default implementation of some of the WE handlers that can be >>> managed without hardware knowledge >>> >>> We are working to merge in Dave Miller's p80211 code into the >>> ieee80211 subsystem so that it hooks into the kernel as a true >>> network layer as opposed to a mutated offspring of ethernet. >>> Once that is done, hopefully the skb to txb code can be reworked and >>> 802.11 fragments can be treated either as normal skbs, or skbs can be >>> modified to directly support them (ideally so that encrypted 802.11 >>> frames in support of IP packets can be cached by the stack instead of >>> having to be re-encrypted on TCP retries) >>> >>> Support for HW/FW crypto and fragmentation offload, in a HW >>> independent fashion, is also on the short-term list. >>> >>> When you look through the patch you'll likely notice the #ifdef >>> NOTYET/#endif sequences surrounding portions of code from the hostap >>> project. Portions of this subsystem were based on an earlier version >>> of the hostap project. Those areas that weren't directly supported >>> by the ipw* projects weren't ported to be completely hardware >>> independent (since I don't have the hardware to test it), and so are >>> still wrapped in the ifdefs. These sections mainly cover support for >>> MASTER and WDS modes. >>> >>> Anyway, please let me know what you think. Hopefully I built the >>> patch right... >> >> >> >> James, >> Can you post a patch that will build? or did you just want >> feedback on the current state of the patch? > > > Ah; I see my tree that I did the diff on was missing the > wireless/Makefile and the ieee80211/ieee80211_module.c to create the > patch against... sigh. Attached is ieee80211_module.c; you have the > change for the Makefile to include ieee80211. > Later {hopefully today} I'll send a full patch that includes several of > the corrections you called out in your prior patch. Now missing ieee80211_crypt.h (#included in the new ieee80211.h). Apparently still needing a complete diff. + /* Add the ESSID */ + iwe.cmd = SIOCGIWESSID; + iwe.u.data.flags = 1; + if (network->flags & NETWORK_EMPTY_ESSID) { Lines 2-3 above use spaces (e.g.) -- please use tabs. -- ~Randy From herbert@gondor.apana.org.au Wed Feb 9 20:58:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 20:58:14 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A4w6Qd018232 for ; Wed, 9 Feb 2005 20:58:06 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Cz6ON-0003lk-00; Thu, 10 Feb 2005 15:57:27 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cz6Nj-00043B-00; Thu, 10 Feb 2005 15:56:47 +1100 Date: Thu, 10 Feb 2005 15:56:47 +1100 To: Werner Almesberger Cc: "David S. Miller" , anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050210045647.GA15552@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> <20050210012304.E25338@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050210012304.E25338@almesberger.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 705 Lines: 26 On Thu, Feb 10, 2005 at 01:23:04AM -0300, Werner Almesberger wrote: > > What happens if the operation could return a value, but the user > ignores it ? E.g. if I don't like smp_mb__*, could I just use > > atomic_inc_and_test(foo); > > instead of > > smp_mb__before_atomic_inc(); > atomic_inc(foo); > smp_mb__after_atomic_dec(); Yes you can. > ? If yes, is this a good idea ? Dave mentioned that on sparc64, atomic_inc_and_test is much more expensive than the second variant. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Wed Feb 9 20:58:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 20:58:17 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A4wC4T018238 for ; Wed, 9 Feb 2005 20:58:12 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BB29333CC2; Thu, 10 Feb 2005 13:59:16 +0900 (JST) Date: Thu, 10 Feb 2005 13:59:16 +0900 (JST) Message-Id: <20050210.135916.65691686.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] Use TASK_COMM_LEN macro. 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1464 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: 705 Lines: 20 Use TASK_COMM_LEN macro instead of magic number 16. Signed-off-by: Hideaki YOSHIFUJI ===== net/core/sock.c 1.57 vs edited ===== --- 1.57/net/core/sock.c 2005-01-11 05:23:56 +09:00 +++ edited/net/core/sock.c 2005-02-10 13:53:08 +09:00 @@ -166,7 +166,7 @@ static void sock_warn_obsolete_bsdism(const char *name) { static int warned; - static char warncomm[16]; + static char warncomm[TASK_COMM_LEN]; if (strcmp(warncomm, current->comm) && warned < 5) { strcpy(warncomm, current->comm); printk(KERN_WARNING "process `%s' is using obsolete " -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Thu Feb 10 00:24:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 00:24:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A8O4bI026223 for ; Thu, 10 Feb 2005 00:24:04 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j1A8Nxl14342 for ; Thu, 10 Feb 2005 00:23:59 -0800 Date: Thu, 10 Feb 2005 00:23:56 -0800 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Message-Id: <20050210002356.500401f7.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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1465 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: 2538 Lines: 66 Begin forwarded message: Date: Thu, 10 Feb 2005 00:00:14 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts http://bugme.osdl.org/show_bug.cgi?id=4189 Summary: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: yoshfuji@linux-ipv6.org Submitter: ikebe.takashi@lab.ntt.co.jp Distribution:Fedora core 3 Hardware Environment: x86, x86_64, NIC is e1000 x4 Software Environment: kernel 2.6.10 Problem Description: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts. Same link local address is assigned to bond0 & bond1 bond0 Link encap:Ethernet HWaddr 00:04:23:A8:F7:78 inet addr:129.60.11.15 Bcast:129.60.11.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:4109866 errors:0 dropped:0 overruns:0 frame:0 TX packets:2624 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:360539888 (343.8 MiB) TX bytes:352807 (344.5 KiB) bond1 Link encap:Ethernet HWaddr 00:04:23:A8:F7:79 inet addr:129.60.11.21 Bcast:129.60.11.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:2483103 errors:0 dropped:0 overruns:0 frame:0 TX packets:378 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:221572495 (211.3 MiB) TX bytes:47244 (46.1 KiB) In the source, net/ipv6/addrconf.c, there is a function; static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) It create ipv6 address from MAC address, however it seems dev->dev_addr is "0" in the case of bonding. Steps to reproduce: 1.set the multiple bonding to the machine. (In my case, set 4 nics to use the bonding, and set the double bond as following modprobe.conf. alias bond0 bonding options bond0 miimon=100 mode=1 max_bonds=2 options bond1 -o bonding1 miimon=100 mode=1 ) 2.start the network. 3.show /sbin/ifconfig and check link local address. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gandalf@wlug.westbo.se Thu Feb 10 01:16:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 01:16:18 -0800 (PST) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A9GBCd027769 for ; Thu, 10 Feb 2005 01:16:14 -0800 Received: by null.rsn.bth.se (Postfix, from userid 65534) id 2D77E2C0047; Thu, 10 Feb 2005 10:16:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id D42B02C0050; Thu, 10 Feb 2005 10:16:07 +0100 (CET) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id 1D61A2C0047; Thu, 10 Feb 2005 10:16:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tux.rsn.bth.se (Postfix) with ESMTP id 555DF3ED9; Thu, 10 Feb 2005 10:16:08 +0100 (CET) Date: Thu, 10 Feb 2005 10:16:08 +0100 (CET) From: Martin Josefsson X-X-Sender: gandalf@tux.rsn.bth.se To: Matt Mackall Cc: "David S. Miller" , jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI In-Reply-To: <20050210011104.GF2366@waste.org> Message-ID: References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 on null.rsn.bth.se X-Virus-Status: Clean X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 680 Lines: 28 On Wed, 9 Feb 2005, Matt Mackall wrote: > --- mm1npc.orig/net/core/dev.c 2005-02-09 14:15:11.236086000 -0800 > +++ mm1npc/net/core/dev.c 2005-02-09 14:15:13.710042000 -0800 > @@ -1772,6 +1772,7 @@ > > dev = list_entry(queue->poll_list.next, > struct net_device, poll_list); > + netpoll_poll_lock(dev); > > if (dev->quota <= 0 || dev->poll(dev, &budget)) { > local_irq_disable(); > @@ -1782,9 +1783,11 @@ > else > dev->quota = dev->weight; > } else { > + netpoll_poll_unlock(dev); > dev_put(dev); > local_irq_disable(); > } > + netpoll_poll_unlock(dev); > > #ifdef CONFIG_KGDBOE > kgdb_process_breakpoint(); Double unlock? /Martin From SRS0+4342de050f84b3d3efba+536+infradead.org+dwmw2@baythorne.srs.infradead.org Thu Feb 10 01:20:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 01:20:23 -0800 (PST) Received: from baythorne.infradead.org (exim@baythorne.infradead.org [81.187.226.107]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A9KHXL028305 for ; Thu, 10 Feb 2005 01:20:18 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by baythorne.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1CzAUe-00018F-QD; Thu, 10 Feb 2005 09:20:12 +0000 Subject: Re: [PATCH] Add audit uid to netlink credentials From: David Woodhouse To: Chris Wright Cc: Linux Audit Discussion , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050209161946.F24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> <20050209161946.F24171@build.pdx.osdl.net> Content-Type: text/plain Date: Thu, 10 Feb 2005 09:20:12 +0000 Message-Id: <1108027212.7716.146.camel@baythorne.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 706 Lines: 18 On Wed, 2005-02-09 at 16:19 -0800, Chris Wright wrote: > Then it comes back to the question of how to protect loginuid. If it > can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be > write protected by CAP_AUDIT_CONTROL. I'm not sure I agree with that. With CAP_AUDIT_WRITE you _can't_ modify the loginuid of the audit logs of your own actions. You can only modify the loginuid on the messages you pull out of thin air and send. You can already make up the rest of the payload -- why shouldn't you be allowed to make up the loginuid too? You could be reporting something that someone _else_ has done, after all. Or am I misunderstanding the intended use of CAP_AUDIT_WRITE? -- dwmw2 From yoshfuji@linux-ipv6.org Thu Feb 10 01:21:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 01:21:28 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A9LLoC028659 for ; Thu, 10 Feb 2005 01:21:21 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4836633CC2; Thu, 10 Feb 2005 18:22:26 +0900 (JST) Date: Thu, 10 Feb 2005 18:22:25 +0900 (JST) Message-Id: <20050210.182225.07335127.yoshfuji@linux-ipv6.org> To: netdev@oss.sgi.com Cc: ikebe.takashi@lab.ntt.co.jp, yoshfuji@linux-ipv6.org, davem@davemloft.net, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050210002356.500401f7.akpm@osdl.org> References: <20050210002356.500401f7.akpm@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1468 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: 1505 Lines: 43 In article <20050210002356.500401f7.akpm@osdl.org> (at Thu, 10 Feb 2005 00:23:56 -0800), Andrew Morton says: > http://bugme.osdl.org/show_bug.cgi?id=4189 > > Summary: IPv6 link local addresses are not assigned correctly on > multiple-bonding enviromrnts > Kernel Version: 2.6.10 > Status: NEW > Severity: normal > Owner: yoshfuji@linux-ipv6.org > Submitter: ikebe.takashi@lab.ntt.co.jp : > It create ipv6 address from MAC address, however it seems dev->dev_addr is "0" > in the case of bonding. I don't think it is the case. > Steps to reproduce: > 1.set the multiple bonding to the machine. > (In my case, set 4 nics to use the bonding, and set the double bond as following > modprobe.conf. This is the key. That we do is: # ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned # ifenslave bond0 eth0 ... IPv6 Link-local address is configured just after the corresponding device is enabled. MAC should be configured before you bring up the interface. So, currently, you need to do this: # ip link set bond0 address 00:01:02:03:04:05 # ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned # ifenslave bond0 eth0 ... BTW, why is it required to bring up bonding device before its configuratoin? Ethernet devices is not allowed to change its MAC during it is up. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Feb 10 01:24:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 01:24:17 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A9ODbk029309 for ; Thu, 10 Feb 2005 01:24:13 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4E89033CC2; Thu, 10 Feb 2005 18:25:18 +0900 (JST) Date: Thu, 10 Feb 2005 18:25:17 +0900 (JST) Message-Id: <20050210.182517.55994883.yoshfuji@linux-ipv6.org> To: netdev@oss.sgi.com Cc: ikebe.takashi@lab.ntt.co.jp, yoshfuji@linux-ipv6.org, davem@davemloft.net, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050210.182225.07335127.yoshfuji@linux-ipv6.org> References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1469 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: 567 Lines: 14 Sorry for typo... In article <20050210.182225.07335127.yoshfuji@linux-ipv6.org> (at Thu, 10 Feb 2005 18:22:25 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > So, currently, you need to do this: > > # ip link set bond0 address 00:01:02:03:04:05 > # ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned fe80::201:02ff:fe03:0405 is assigned > # ifenslave bond0 eth0 ... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ikebe.takashi@lab.ntt.co.jp Thu Feb 10 04:02:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 04:02:29 -0800 (PST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AC2CI2003162 for ; Thu, 10 Feb 2005 04:02:13 -0800 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1sWn022816; Thu, 10 Feb 2005 21:01:54 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1sMe008930; Thu, 10 Feb 2005 21:01:54 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1rnj008924; Thu, 10 Feb 2005 21:01:53 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1rFh026795; Thu, 10 Feb 2005 21:01:53 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1rYp026787; Thu, 10 Feb 2005 21:01:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1q2U012208; Thu, 10 Feb 2005 21:01:52 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1qAv008044; Thu, 10 Feb 2005 21:01:52 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (imd0.m.ecl.ntt.co.jp [129.60.5.142]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AC1qRE008041; Thu, 10 Feb 2005 21:01:52 +0900 (JST) Received: from [129.60.11.18] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA02840; Thu, 10 Feb 2005 21:01:51 +0900 (JST) Message-ID: <420B4C96.9010808@lab.ntt.co.jp> Date: Thu, 10 Feb 2005 20:59:18 +0900 From: Takashi Ikebe User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-2022-JP?B?WU9TSElGVUpJIEhpZGVha2kgLyAbJEI1SEYjMVFMQBsoQg==?= CC: netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <20050210.182517.55994883.yoshfuji@linux-ipv6.org> In-Reply-To: <20050210.182517.55994883.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ikebe.takashi@lab.ntt.co.jp Precedence: bulk X-list: netdev Content-Length: 972 Lines: 32 I think this cause by network init script. network init script always bring up ifcfg-[A-Za-z0-9\._-], so ifcfg-bond* always bring up before ifcfg-eth*! ("b" is before "e" in alphabet order!) I see, this is not a kernel issue, and this is initscript issue. YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Sorry for typo... > > In article <20050210.182225.07335127.yoshfuji@linux-ipv6.org> (at Thu, 10 Feb 2005 18:22:25 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > >>So, currently, you need to do this: >> >># ip link set bond0 address 00:01:02:03:04:05 >># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned > > fe80::201:02ff:fe03:0405 is assigned > >># ifenslave bond0 eth0 ... > > -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : ikebe.takashi@lab.ntt.co.jp From sds@epoch.ncsc.mil Thu Feb 10 04:44:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 04:44:14 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ACi8LB008033 for ; Thu, 10 Feb 2005 04:44:08 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1ACehMU024137; Thu, 10 Feb 2005 12:40:43 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1AChFRH026351; Thu, 10 Feb 2005 07:43:15 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Chris Wright Cc: netdev@oss.sgi.com, Linux Audit Discussion , davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050209171115.G24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <20050209171115.G24171@build.pdx.osdl.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108038968.22172.26.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 10 Feb 2005 07:36:09 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 2014 Lines: 38 On Wed, 2005-02-09 at 20:11, Chris Wright wrote: > * Chris Wright (chrisw@osdl.org) wrote: > > Hmm, perhaps we could eliminate the whole asynchronous issue by allowing > > registration of a netlink link specific security handler. Something like: > > > > netlink_kernel_create_sec(unit, rx, sec_handler) > > > > Then the check would be done before the packet was ever queued. This > > would eliminate the if (NETLINK_CREDS(skb)->$cred == bad) on receipt > > side, and push it to sender side. It would also be link specific so > > audit could do it's audit payload loginuid check here. I think it would > > also eliminate SELinux's need to tag the packet for later checking on > > receipt. Thoughts? > > Here's an example of what I mean. It's quite rough, doesn't yet eliminate > any of the code that it eventually could, and doesn't deal with broadcast. > I gave it a quick test with audit netlink, and it does what I expect. Why not just call the security handler from the security_netlink_send() function, which is already called by netlink_sendmsg()? Note that SELinux (thanks to work by James Morris a while back) does apply fine-grained netlink controls using its selinux_netlink_send() hook function, but the problem with this approach is that it requires maintaining a netlink message type table within SELinux itself that maps netlink operations to generic flow operations (read, write), effectively duplicating state between SELinux and the netlink protocol implementations. It also isn't necessarily sufficiently granular for all needs. It would be preferable to have the netlink protocol implementations to maintain such mappings and just invoke security modules to check the generic permissions based on its own internal mapping (same idea applies for ioctls, where the device driver or filesystem code should handle the mapping to generic permissions and only invoke the security module to check the generic permission). -- Stephen Smalley National Security Agency From sds@epoch.ncsc.mil Thu Feb 10 04:48:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 04:48:36 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ACmVZ6008543 for ; Thu, 10 Feb 2005 04:48:32 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1ACipMU024317; Thu, 10 Feb 2005 12:44:51 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1AClNRH026398; Thu, 10 Feb 2005 07:47:23 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Linux Audit Discussion Cc: David Woodhouse , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <20050209161946.F24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> <20050209161946.F24171@build.pdx.osdl.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108039217.22172.31.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 10 Feb 2005 07:40:17 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 603 Lines: 15 On Wed, 2005-02-09 at 19:19, Chris Wright wrote: > Then it comes back to the question of how to protect loginuid. If it > can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be > write protected by CAP_AUDIT_CONTROL. To be precise, isn't it true that someone with only CAP_AUDIT_WRITE would only be able to spoof loginuids in the AUDIT_USER messages they generate? The loginuid on any syscall audit messages for the task would still be the one associated with the task's audit context, so that would not be spoofable. -- Stephen Smalley National Security Agency From SRS0+81e737e4e25a4d65e438+536+infradead.org+dwmw2@pentafluge.srs.infradead.org Thu Feb 10 04:49:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 04:49:51 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ACnlJ8009028 for ; Thu, 10 Feb 2005 04:49:47 -0800 Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1CzDlN-00011f-Eh; Thu, 10 Feb 2005 12:49:45 +0000 Subject: Re: [PATCH] Add audit uid to netlink credentials From: David Woodhouse To: Stephen Smalley Cc: Linux Audit Discussion , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <1108039217.22172.31.camel@moss-spartans.epoch.ncsc.mil> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> <20050209161946.F24171@build.pdx.osdl.net> <1108039217.22172.31.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Date: Thu, 10 Feb 2005 12:49:39 +0000 Message-Id: <1108039780.19262.533.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 392 Lines: 12 On Thu, 2005-02-10 at 07:40 -0500, Stephen Smalley wrote: > To be precise, isn't it true that someone with only CAP_AUDIT_WRITE > would only be able to spoof loginuids in the AUDIT_USER messages they > generate? The loginuid on any syscall audit messages for the task would > still be the one associated with the task's audit context, so that would > not be spoofable. Correct. -- dwmw2 From sds@tycho.nsa.gov Thu Feb 10 04:59:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 04:59:19 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ACxCWJ009807 for ; Thu, 10 Feb 2005 04:59:13 -0800 Received: from tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1ACu2MU025117; Thu, 10 Feb 2005 12:56:02 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1ACwQL9010924; Thu, 10 Feb 2005 07:58:26 -0500 (EST) Subject: Re: [PATCH] Add audit uid to netlink credentials From: Stephen Smalley To: Chris Wright Cc: netdev@oss.sgi.com, Linux Audit Discussion , davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <1108038968.22172.26.camel@moss-spartans.epoch.ncsc.mil> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <20050209171115.G24171@build.pdx.osdl.net> <1108038968.22172.26.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108039883.22172.40.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 10 Feb 2005 07:51:23 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@tycho.nsa.gov Precedence: bulk X-list: netdev Content-Length: 500 Lines: 13 On Thu, 2005-02-10 at 07:36, Stephen Smalley wrote: > Why not just call the security handler from the security_netlink_send() > function, which is already called by netlink_sendmsg()? Ok, I can see why you wouldn't want to do that, but why not just call the handler immediately after security_netlink_send() then in netlink_sendmsg()? What is the advantage of deferring to netlink_sendskb (and some other location for broadcasts)? -- Stephen Smalley National Security Agency From chanson@TrustedCS.com Thu Feb 10 06:37:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 06:37:39 -0800 (PST) Received: from tcsfw4.tcs-sec.com (h-67-100-190-245.mclnva23.covad.net [67.100.190.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AEbWwh015179 for ; Thu, 10 Feb 2005 06:37:35 -0800 Received: (from smmsp@localhost) by tcsfw4.tcs-sec.com (8.12.2/8.12.2) id j1AEaBDB000305; Thu, 10 Feb 2005 09:36:11 -0500 (EST) Received: from trauma.tcs-sec.com(192.168.1.16) by tcsfw4.tcs-sec.com via smap (V1.3) id (null); Thu Feb 10 09:36:05 2005 Received: from chaos.tcs.tcs-sec.com (Not Verified[192.168.1.4]) by Trauma.tcs-sec.com with NetIQ MailMarshal (v6,0,3,8) id ; Thu, 10 Feb 2005 09:37:29 -0500 Received: by chaos.tcs.tcs-sec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Feb 2005 09:37:29 -0500 Message-ID: <36282A1733C57546BE392885C06185927377BE@chaos.tcs.tcs-sec.com> From: Chad Hanson To: Linux Audit Discussion , Chris Wright Cc: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: RE: [PATCH] Add audit uid to netlink credentials Date: Thu, 10 Feb 2005 09:37:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chanson@TrustedCS.com Precedence: bulk X-list: netdev Content-Length: 1911 Lines: 38 David Woodhouse wrote: > > On Wed, 2005-02-09 at 16:19 -0800, Chris Wright wrote: > > Then it comes back to the question of how to protect loginuid. If it > > can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be > > write protected by CAP_AUDIT_CONTROL. > > I'm not sure I agree with that. With CAP_AUDIT_WRITE you _can't_ modify > the loginuid of the audit logs of your own actions. You can only modify > the loginuid on the messages you pull out of thin air and send. You can > already make up the rest of the payload -- why shouldn't you be allowed > to make up the loginuid too? You could be reporting something that > someone _else_ has done, after all. > I'm not sure I understand this logic. Let me start with some background. The purpose of the loginuid is to record the original creator of the process regardless of credential changes since login. We use a capability to protect this, so it cannot be altered by most programs, even those which write audit records. Placing the loginuid in the payload effectively removes the purpose of CAP_AUDIT_CONTROL from all userland audit messages. A program may be privileged to write an audit record, but a granular security approach would not let them have the ability to change the loginuid as well. In your example of a process watching daemon, why would this daemon want to spoof the credentials of the watched process? I can think of two examples. One you are recording information for IDS like purposes of system and process state. This could be a good use of audit, however, I don't understand the need to make the loginuid of the audit logs match the process you are watching. If you really did, y0ou are a heavily privileged process already to watch all of these other processes, simply change your loginuid through CAP_AUDIT_CONTROL and add that to the other privileges you already have in monitoring the system state. -Chad From SRS0+81e737e4e25a4d65e438+536+infradead.org+dwmw2@pentafluge.srs.infradead.org Thu Feb 10 06:56:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 06:56:52 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AEulGh016166 for ; Thu, 10 Feb 2005 06:56:47 -0800 Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1CzFkH-0001YO-0c; Thu, 10 Feb 2005 14:56:42 +0000 Subject: RE: [PATCH] Add audit uid to netlink credentials From: David Woodhouse To: Linux Audit Discussion Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru In-Reply-To: <36282A1733C57546BE392885C06185927377BE@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C06185927377BE@chaos.tcs.tcs-sec.com> Content-Type: text/plain; charset=UTF-8 Date: Thu, 10 Feb 2005 14:56:36 +0000 Message-Id: <1108047396.19262.537.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 460 Lines: 12 On Thu, 2005-02-10 at 09:37 -0500, Chad Hanson wrote: > In your example of a process watching daemon, why would this daemon want to > spoof the credentials of the watched process? I can think of two examples. Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you provide examples of why you _wouldn't_ want to let a dæmon which is already sending random unvetted AUDIT_WRITE messages also specify the loginuid on _those_ messages? -- dwmw2 From chanson@TrustedCS.com Thu Feb 10 07:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 07:16:08 -0800 (PST) Received: from tcsfw4.tcs-sec.com (h-67-100-190-245.mclnva23.covad.net [67.100.190.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AFG4RZ017015 for ; Thu, 10 Feb 2005 07:16:05 -0800 Received: (from smmsp@localhost) by tcsfw4.tcs-sec.com (8.12.2/8.12.2) id j1AFFCKG014017; Thu, 10 Feb 2005 10:15:12 -0500 (EST) Received: from trauma.tcs-sec.com(192.168.1.16) by tcsfw4.tcs-sec.com via smap (V1.3) id (null); Thu Feb 10 10:14:57 2005 Received: from chaos.tcs.tcs-sec.com (Not Verified[192.168.1.4]) by Trauma.tcs-sec.com with NetIQ MailMarshal (v6,0,3,8) id ; Thu, 10 Feb 2005 10:16:22 -0500 Received: by chaos.tcs.tcs-sec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Feb 2005 10:16:22 -0500 Message-ID: <36282A1733C57546BE392885C06185927377E6@chaos.tcs.tcs-sec.com> From: Chad Hanson To: Linux Audit Discussion Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com Subject: RE: [PATCH] Add audit uid to netlink credentials Date: Thu, 10 Feb 2005 10:16:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1AFG4RZ017015 X-archive-position: 1477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chanson@TrustedCS.com Precedence: bulk X-list: netdev Content-Length: 499 Lines: 14 David Woodhouse wrote: > > Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you > provide examples of why you _wouldn't_ want to let a dæmon which is > already sending random unvetted AUDIT_WRITE messages also specify the > loginuid on _those_ messages? The loginuid is part of the process state. This is the reason you do not want to write out this information from a userspace application, as the process state portions of the audit record are recorded by the kernel. -Chad From oxymoron@waste.org Thu Feb 10 09:14:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 09:14:11 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AHE7Ra024774 for ; Thu, 10 Feb 2005 09:14:08 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1AHE1Sv003511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Feb 2005 11:14:01 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j1AHE0en003507; Thu, 10 Feb 2005 11:14:00 -0600 Date: Thu, 10 Feb 2005 09:14:00 -0800 From: Matt Mackall To: Martin Josefsson Cc: "David S. Miller" , jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050210171400.GM2366@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1478 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: 1067 Lines: 37 On Thu, Feb 10, 2005 at 10:16:08AM +0100, Martin Josefsson wrote: > On Wed, 9 Feb 2005, Matt Mackall wrote: > > > --- mm1npc.orig/net/core/dev.c 2005-02-09 14:15:11.236086000 -0800 > > +++ mm1npc/net/core/dev.c 2005-02-09 14:15:13.710042000 -0800 > > @@ -1772,6 +1772,7 @@ > > > > dev = list_entry(queue->poll_list.next, > > struct net_device, poll_list); > > + netpoll_poll_lock(dev); > > > > if (dev->quota <= 0 || dev->poll(dev, &budget)) { > > local_irq_disable(); > > @@ -1782,9 +1783,11 @@ > > else > > dev->quota = dev->weight; > > } else { > > + netpoll_poll_unlock(dev); > > dev_put(dev); > > local_irq_disable(); > > } > > + netpoll_poll_unlock(dev); > > > > #ifdef CONFIG_KGDBOE > > kgdb_process_breakpoint(); > > Double unlock? Yes. The second one should instead be up a few lines here: if (dev->quota <= 0 || dev->poll(dev, &budget)) { + netpoll_poll_unlock(dev); local_irq_disable(); -- Mathematics is the supreme nostalgia of our time. From chrisw@osdl.org Thu Feb 10 09:14:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 09:14:57 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AHEpiB024902 for ; Thu, 10 Feb 2005 09:14:51 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1AHESl23481; Thu, 10 Feb 2005 09:14:28 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1AHERg04007; Thu, 10 Feb 2005 09:14:27 -0800 Date: Thu, 10 Feb 2005 09:14:27 -0800 From: Chris Wright To: Stephen Smalley Cc: Linux Audit Discussion , netdev@oss.sgi.com, David Woodhouse , davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050210091427.K24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> <20050209161946.F24171@build.pdx.osdl.net> <1108039217.22172.31.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1108039217.22172.31.camel@moss-spartans.epoch.ncsc.mil>; from sds@epoch.ncsc.mil on Thu, Feb 10, 2005 at 07:40:17AM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 716 Lines: 18 * Stephen Smalley (sds@epoch.ncsc.mil) wrote: > On Wed, 2005-02-09 at 19:19, Chris Wright wrote: > > Then it comes back to the question of how to protect loginuid. If it > > can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be > > write protected by CAP_AUDIT_CONTROL. > > To be precise, isn't it true that someone with only CAP_AUDIT_WRITE > would only be able to spoof loginuids in the AUDIT_USER messages they > generate? The loginuid on any syscall audit messages for the task would > still be the one associated with the task's audit context, so that would > not be spoofable. Yes, that's true. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From klaus@atsec.com Thu Feb 10 09:52:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 09:52:40 -0800 (PST) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AHqZAp026189 for ; Thu, 10 Feb 2005 09:52:36 -0800 Received: (qmail 7336 invoked by uid 10125); 10 Feb 2005 17:52:33 -0000 X-SpaceNet-Virusscan: Sophos Version: 3.89; Last IDE Update: 2005-02-10 15:40 FILE NOT INFECTED: [1108057953.7332-0.mail.atsec.com] Received: from host203-77.discord.birch.net (HELO io.lan.w-m-p.com) (65.16.203.77) by mail.atsec.com with SMTP; 10 Feb 2005 17:52:33 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Received: by io.lan.w-m-p.com (Postfix, from userid 501) id 0FE151D14B; Thu, 10 Feb 2005 11:52:25 -0600 (CST) Date: Thu, 10 Feb 2005 11:52:21 -0600 From: Klaus Weidner To: Linux Audit Discussion Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050210175221.GA13458@w-m-p.com> References: <36282A1733C57546BE392885C06185927377BE@chaos.tcs.tcs-sec.com> <1108047396.19262.537.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1108047396.19262.537.camel@hades.cambridge.redhat.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klaus@atsec.com Precedence: bulk X-list: netdev Content-Length: 1627 Lines: 32 On Thu, Feb 10, 2005 at 02:56:36PM +0000, David Woodhouse wrote: > On Thu, 2005-02-10 at 09:37 -0500, Chad Hanson wrote: > > In your example of a process watching daemon, why would this daemon want to > > spoof the credentials of the watched process? I can think of two examples. > > Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you > provide examples of why you _wouldn't_ want to let a dæmon which is > already sending random unvetted AUDIT_WRITE messages also specify the > loginuid on _those_ messages? A few comments on this issue from the point of view of common criteria evaluations... Briefly, either choice of implementation would be okay. Both CAPP and LSPP assume trustworthy administrators, and those protection profiles don't really support the concept of fine grained capabilities for not-quite-administrator tasks. The CAPP and LSPP audit requirements include that audit records contain the subject identity, this corresponds to the login UID. The point of the user messages is to support proper auditing of actions that aren't directly related to system calls, such as authenticating users, modifying security databases, and similar things. This is always done by trusted processes, so the technical method used to get the login UID into the audit record for user messages doesn't matter as long as it can't be falsified by non-administrators. A CAPP/LSPP compliant implementation could for example completely bypass the kernel and append user messages from trusted processes directly to the audit log file - I'm not saying that would be a good idea, but it could be compliant. -Klaus From casey@schaufler-ca.com Thu Feb 10 10:10:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 10:10:35 -0800 (PST) Received: from web50202.mail.yahoo.com (web50202.mail.yahoo.com [206.190.38.43]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1AIAT9S027970 for ; Thu, 10 Feb 2005 10:10:29 -0800 Received: (qmail 92821 invoked by uid 60001); 10 Feb 2005 18:10:23 -0000 Message-ID: <20050210181023.92819.qmail@web50202.mail.yahoo.com> Received: from [66.32.184.110] by web50202.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 10:10:23 PST Date: Thu, 10 Feb 2005 10:10:23 -0800 (PST) From: Casey Schaufler Subject: Re: [PATCH] Add audit uid to netlink credentials To: Linux Audit Discussion Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <20050210175221.GA13458@w-m-p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: casey@schaufler-ca.com Precedence: bulk X-list: netdev Content-Length: 2481 Lines: 80 --- Klaus Weidner wrote: > Both CAPP and LSPP assume trustworthy > administrators, and those > protection profiles don't really support the concept > of fine grained > capabilities for not-quite-administrator tasks. I don't know where you get that idea, as it is inconsistent with the evaluations I have done. A fine grained capability model that is used will always make an evaluation easier. A process that runs with partial privilege requires much less supporting evidence for evaluation than one that has superuser privilege. The Criteria may not require fine grained privilege, but that does not mean it doesn't help. > The CAPP and LSPP audit requirements include that > audit records contain > the subject identity, this corresponds to the login > UID. The subject identity is the name of the subject, that is the process ID. The user associated with the session is the login UID. The user is not the subject. > The point of the > user messages is to support proper auditing of > actions that aren't > directly related to system calls, such as > authenticating users, modifying > security databases, and similar things. This is > always done by trusted > processes, so the technical method used to get the > login UID into the > audit record for user messages doesn't matter as > long as it can't be > falsified by non-administrators. This is correct as far as it goes. One of the requirements is to correctly audit attempts made by unprivileged users to write to the audit trail. This is one reason you need the login UID of the process attempting to write to the audit trail. > A CAPP/LSPP compliant implementation could for > example completely bypass > the kernel and append user messages from trusted > processes directly to > the audit log file - I'm not saying that would be a > good idea, but it > could be compliant. It is actually a very good idea to maintain modifications to system security databases outside the audit trail proper. In the Orange Book days the NSA went so far as to declare a that a reasonable procedure for keeping them under revision control would be sufficient to meet the audit requirements. Another mechanism that would work well is to send the user space records directly to the audit daemon using a protected socket. ===== Casey Schaufler casey@schaufler-ca.com __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From fubar@us.ibm.com Thu Feb 10 10:17:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 10:17:31 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AIHNF8029171 for ; Thu, 10 Feb 2005 10:17:24 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1AIHIRm021567 for ; Thu, 10 Feb 2005 13:17:18 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1AIHIvj200422 for ; Thu, 10 Feb 2005 13:17:18 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1AIHHZ6022014 for ; Thu, 10 Feb 2005 13:17:18 -0500 Received: from death.nxdomain.ibm.com (sig-9-65-44-221.mts.ibm.com [9.65.44.221]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1AIHGdI021992; Thu, 10 Feb 2005 13:17:17 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1AIH8Nn000611; Thu, 10 Feb 2005 10:17:11 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1AIH6p7000602; Thu, 10 Feb 2005 10:17:07 -0800 Message-Id: <200502101817.j1AIH6p7000602@death.nxdomain.ibm.com> To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, davem@davemloft.net, akpm@osdl.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts In-Reply-To: Message from YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= of "Thu, 10 Feb 2005 18:22:25 +0900." <20050210.182225.07335127.yoshfuji@linux-ipv6.org> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=euc-jp Date: Thu, 10 Feb 2005 10:17:06 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1AIHNF8029171 X-archive-position: 1482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2807 Lines: 67 YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote: >> It create ipv6 address from MAC address, however it seems dev->dev_addr is "0" >> in the case of bonding. > >I don't think it is the case. Given the below sequence, i.e., ifconfig bond0 up before ifenslave, then, yes, the dev_addr is all zeroes when the ifconfig up happens. The bonding master device (bond0) uses the ethernet address of the first slave to be added, so if there are no slaves, the dev_addr is all zeros. ># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned ># ifenslave bond0 eth0 ... > >IPv6 Link-local address is configured just after the >corresponding device is enabled. MAC should be configured >before you bring up the interface. > >So, currently, you need to do this: > ># ip link set bond0 address 00:01:02:03:04:05 ># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned ># ifenslave bond0 eth0 ... > >BTW, why is it required to bring up bonding device before its configuratoin? I can't say for sure why it was originally done that way, but a lot of initialization in done in the device open function, and that happens at "ifconfig up" time. For IPv4 it's not a problem (nothing really happens at "ifconfig bond0 up", the device can't really communicate until at least one slave is added, and the MAC address can be gleaned at that time). The general model for bonding is that down means "no slaves," so "ifconfig bond0 down" releases the slaves (and the module can be removed at that point). The model used by the bridge device is probably a better way to go, particularly given that IPv6 link local addresses are created at "ifconfig up" time. In that case, bonding would insist on having at least one slave before ifconfig up can succeed, and a ifconfig down wouldn't necessarily release the slaves (although that part can be more flexible; we could preserve the current "ifconfig down releases all slaves" behavior). Changing this is a significant change to the user interface. Making it backwards compatible with the current scheme while still preventing users from ending up with bogus IPv6 link local addresses seems difficult (I can't think of a way offhand; one method requires that ifenslave happen before ifconfig up, the other requires the opposite). I'll have to give this some thought; it will have to change somehow, since IPv6 doesn't work properly with the current scheme. >Ethernet devices is not allowed to change its MAC during it is up. Some of the bonding modes alter a slave's MAC addresses while up, typically to have a slave masquerade as one of the other slaves (if, e.g., the other slave fails). Not all of the device drivers support this, so it doesn't work with all devices. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From klaus@atsec.com Thu Feb 10 11:27:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 11:27:12 -0800 (PST) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AJR6PO005691 for ; Thu, 10 Feb 2005 11:27:07 -0800 Received: (qmail 23586 invoked by uid 10125); 10 Feb 2005 19:27:06 -0000 X-SpaceNet-Virusscan: Sophos Version: 3.89; Last IDE Update: 2005-02-10 15:40 FILE NOT INFECTED: [1108063626.23584-0.mail.atsec.com] Received: from host203-77.discord.birch.net (HELO io.lan.w-m-p.com) (65.16.203.77) by mail.atsec.com with SMTP; 10 Feb 2005 19:27:06 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Received: by io.lan.w-m-p.com (Postfix, from userid 501) id AF72A1D14B; Thu, 10 Feb 2005 13:26:57 -0600 (CST) Date: Thu, 10 Feb 2005 13:26:55 -0600 From: Klaus Weidner To: Linux Audit Discussion Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050210192655.GA14534@w-m-p.com> References: <20050210175221.GA13458@w-m-p.com> <20050210181023.92819.qmail@web50202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050210181023.92819.qmail@web50202.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klaus@atsec.com Precedence: bulk X-list: netdev Content-Length: 3171 Lines: 59 On Thu, Feb 10, 2005 at 10:10:23AM -0800, Casey Schaufler wrote: > --- Klaus Weidner wrote: > > Both CAPP and LSPP assume trustworthy administrators, and those > > protection profiles don't really support the concept of fine grained > > capabilities for not-quite-administrator tasks. > > I don't know where you get that idea, as it is inconsistent with the > evaluations I have done. A fine grained capability model that is used > will always make an evaluation easier. A process that runs with partial > privilege requires much less supporting evidence for evaluation than > one that has superuser privilege. The Criteria may not require fine > grained privilege, but that does not mean it doesn't help. My point was that the security functional requirements in CAPP and LSPP related to audit and user management only differentiate between authorized users and authorized administrators, and adding a finer grained distinction to those SFRs would be incompatible with CAPP/LSPP. CAPP and LSPP permit extending the DAC and MAC policies by adding additional rules such as capability-based ones, but I'd normally expect that to cause more work instead of less when evaluating since all claims related to that policy would then need to be sufficiently tested and verified. But I think that's getting off-topic for this list. > > The CAPP and LSPP audit requirements include that audit records > > contain the subject identity, this corresponds to the login UID. > > The subject identity is the name of the subject, that is the process > ID. The user associated with the session is the login UID. The user is > not the subject. Sorry, I blame lack of caffeine for that mixup. The requirement I meant was that each auditable event needs to be associated with the identity of the user that caused the event. In the context of this discussion, that means that the login UID in audit records needs to correspond to the user identity of the user on whose behalf the process (subject) runs. For cron/at and other indirect execution methods, the daemon running the jobs needs to be able to correctly associate the login UID of the user who submitted the job with the audit records generated by that job. Usually such daemons will need the capability to change the login UID for forked processes in addition to generating user messages with a specific login UID included in the record, so the distinction between those two capabilities isn't all that useful in this case. > It is actually a very good idea to maintain modifications to system > security databases outside the audit trail proper. In the Orange Book > days the NSA went so far as to declare a that a reasonable procedure > for keeping them under revision control would be sufficient to meet the > audit requirements. Hmmm, this doesn't match the application note for FAU_SAR.1 in CAPP and LSPP that mentions that it is expected that a single tool will exist that satisfies all the various requirements related to audit information access. Of course application notes aren't normative, and you could claim that "grep" is the single tool usable for all types of audit trail access... -Klaus From pb@bieringer.de Thu Feb 10 12:09:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 12:09:33 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AK9RTa006824 for ; Thu, 10 Feb 2005 12:09:28 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 31D8E137EE; Thu, 10 Feb 2005 21:09:25 +0100 (CET) X-AV-Checked: Thu Feb 10 21:09:25 2005 smtp2.aerasec.de Received: from [192.168.1.2] (pD9E4E7BB.dip.t-dialin.net [217.228.231.187]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id 47D20137EA; Thu, 10 Feb 2005 21:09:24 +0100 (CET) Date: Thu, 10 Feb 2005 21:09:22 +0100 From: Peter Bieringer To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com, initscripts-ipv6@deepspace6.net Subject: Re: (usagi-users 03019) Re: sysctl net.ipv6.conf.eth0.use_tempaddr only recogniced on interface start? Message-ID: <83D85B170EFC0F1C0451F2EB@worker.muc.bieringer.de> In-Reply-To: <20040830.180805.06423987.yoshfuji@linux-ipv6.org> References: <20040830.180805.06423987.yoshfuji@linux-ipv6.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Content-Length: 1297 Lines: 36 Hi, --On Monday, August 30, 2004 06:08:05 PM +0900 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" wrote: > In article (at Mon, 30 > Aug 2004 10:09:46 +0200), Peter Bieringer says: > >> during playing around with RFC3041 capability in Linux kernel, I >> recognized that the toggle (e.g. net.ipv6.conf.eth0.use_tempaddr) in >> sysctl is only recognized if interface state changes from down to up, >> which means you can't enable RFC3041 on an already running interface. > > Not quite true. net.ipv6.conf.eth0.use_tempaddr is recognized, but > new temporary addresses is created only when new public address is created > (by specification). > >> Is this >> >> a) by design >> b) temporary issue, will be solved later >> c) bug, will be solved soon > > a > > and even b; we can probably extend our implementation > to create temprary address when net.ipv6.conf.eth0.use_tempaddr is > changed from 0 to 1. Any news on that? Have you plans to implement it? Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From davem@davemloft.net Thu Feb 10 12:26:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 12:26:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AKQILk011093 for ; Thu, 10 Feb 2005 12:26:19 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzKsN-00034m-00; Thu, 10 Feb 2005 12:25:23 -0800 Date: Thu, 10 Feb 2005 12:25:23 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Message-Id: <20050210122523.41276d5a.davem@davemloft.net> In-Reply-To: <20050210.182225.07335127.yoshfuji@linux-ipv6.org> References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1AKQILk011093 X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 563 Lines: 17 On Thu, 10 Feb 2005 18:22:25 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Ethernet devices is not allowed to change its MAC during it is up. This is not true. All ethernet drivers try to support this, and just about all do. This is what dev->set_mac_address() driver routine implements. I guess this causes problems for ipv6 local addresses, it will need to catch some callback to handle these events and thus adjust the local address properly. This is the real bug in my opinion, ipv4 handles this situation just fine. From davem@davemloft.net Thu Feb 10 12:28:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 12:28:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AKSiVK011573 for ; Thu, 10 Feb 2005 12:28:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzKuf-00035Y-00; Thu, 10 Feb 2005 12:27:45 -0800 Date: Thu, 10 Feb 2005 12:27:45 -0800 From: "David S. Miller" To: Jay Vosburgh Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Message-Id: <20050210122745.16ca7cb3.davem@davemloft.net> In-Reply-To: <200502101817.j1AIH6p7000602@death.nxdomain.ibm.com> References: <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <200502101817.j1AIH6p7000602@death.nxdomain.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 518 Lines: 13 On Thu, 10 Feb 2005 10:17:06 -0800 Jay Vosburgh wrote: > The model used by the bridge device is probably a better way to > go, particularly given that IPv6 link local addresses are created at > "ifconfig up" time. IPv6 should catch an event when MAC addresses change, to reassign to correct link local address. I don't think the bonding driver needs to change at all. IPv6 needs to fix this issue, regardless of bonding. It is perfectly legal to change MAC addresses while a link is still up. From pekkas@netcore.fi Thu Feb 10 12:34:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 12:34:12 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AKY6jG012119 for ; Thu, 10 Feb 2005 12:34:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1AKXfb05117; Thu, 10 Feb 2005 22:33:41 +0200 Date: Thu, 10 Feb 2005 22:33:41 +0200 (EET) From: Pekka Savola To: Peter Bieringer cc: usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: (usagi-users 03019) Re: sysctl net.ipv6.conf.eth0.use_tempaddr only recogniced on interface start? In-Reply-To: <83D85B170EFC0F1C0451F2EB@worker.muc.bieringer.de> Message-ID: References: <20040830.180805.06423987.yoshfuji@linux-ipv6.org> <83D85B170EFC0F1C0451F2EB@worker.muc.bieringer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 653 Lines: 17 On Thu, 10 Feb 2005, Peter Bieringer wrote: >> a >> >> and even b; we can probably extend our implementation >> to create temprary address when net.ipv6.conf.eth0.use_tempaddr is >> changed from 0 to 1. > > Any news on that? Have you plans to implement it? Speaking of which, it would REALLY useful to implement the similar "state change triggers" for e.g. accept_ra (which would send out a RS immediately, which is currently impossible from the user space). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rick.jones2@hp.com Thu Feb 10 13:26:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 13:26:37 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ALQQtF013491 for ; Thu, 10 Feb 2005 13:26:26 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id CADC388F7; Thu, 10 Feb 2005 13:26:25 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA16894; Thu, 10 Feb 2005 13:26:24 -0800 (PST) Message-ID: <420BD180.2040605@hp.com> Date: Thu, 10 Feb 2005 13:26:24 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: Jay Vosburgh , yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts References: <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <200502101817.j1AIH6p7000602@death.nxdomain.ibm.com> <20050210122745.16ca7cb3.davem@davemloft.net> In-Reply-To: <20050210122745.16ca7cb3.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 427 Lines: 11 >IPv6 should catch an event when MAC addresses change, to reassign > to correct link local address. I don't think the bonding driver > needs to change at all. > > IPv6 needs to fix this issue, regardless of bonding. It is perfectly > legal to change MAC addresses while a link is still up. This may seem a silly question, but what happens to existing TCP connections when the IPv6 link local address changes? rick jones From hubert.tonneau@fullpliant.org Thu Feb 10 14:20:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 14:20:50 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1AMKae9014762 for ; Thu, 10 Feb 2005 14:20:41 -0800 From: Hubert Tonneau To: Stephen Hemminger Cc: Francois Romieu , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Thu, 10 Feb 2005 21:53:20 GMT Message-ID: <0523RGW12@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 1453 Lines: 43 It does not seem to solve the problem: . Linux 2.6.9 takes 15 seconds to copy 105 MB to the Mac OSX . Linux 2.6.10 with the TCP patch still takes 325 seconds. Stephen Hemminger wrote: > > Please try this patch, based on Alexey's suggestion: > > > That's one quick and simple idea: set PSH on each tso segment. > > Seems, it is always good. Hardware will preserve it only on the last skb and > > everyone will be happy. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2005/02/09 11:00:57-08:00 shemminger@linux.site > # Always set PUSH on TSO multi-segment frames > # to workaround bugs in MacOSX > # > # net/ipv4/tcp_output.c > # 2005/02/09 11:00:44-08:00 shemminger@linux.site +8 -0 > # Always set PUSH on TSO multi-segment frames > # to workaround bugs in MacOSX > # > diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > --- a/net/ipv4/tcp_output.c 2005-02-09 11:01:12 -08:00 > +++ b/net/ipv4/tcp_output.c 2005-02-09 11:01:12 -08:00 > @@ -754,6 +754,14 @@ > break; > } > > + /* Force push to be on for any large TSO frames > + * to workaround problems with busted implementations > + * like MacOSX that hold off delivery of data until > + * push. > + */ > + if (tcp_skb_pcount(skb) > 1) > + TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; > + > TCP_SKB_CB(skb)->when = tcp_time_stamp; > if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) > break; From rick.jones2@hp.com Thu Feb 10 14:36:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 14:37:00 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1AMas1V015415 for ; Thu, 10 Feb 2005 14:36:54 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 2CCBBC0E; Thu, 10 Feb 2005 14:36:53 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA17287; Thu, 10 Feb 2005 14:36:40 -0800 (PST) Message-ID: <420BE1F8.1080500@hp.com> Date: Thu, 10 Feb 2005 14:36:40 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hubert Tonneau Cc: Stephen Hemminger , Francois Romieu , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0523RGW12@server5.heliogroup.fr> In-Reply-To: <0523RGW12@server5.heliogroup.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 235 Lines: 8 Hubert Tonneau wrote: > It does not seem to solve the problem: > . Linux 2.6.9 takes 15 seconds to copy 105 MB to the Mac OSX > . Linux 2.6.10 with the TCP patch still takes 325 seconds. is there a packet trace somewhere? rick jones From pablo@eurodev.net Thu Feb 10 16:14:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:14:29 -0800 (PST) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0EOiU018479 for ; Thu, 10 Feb 2005 16:14:24 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp07.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001418.PCNX10926.smtp07.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:14:18 +0100 Message-ID: <420BF8DF.4080407@eurodev.net> Date: Fri, 11 Feb 2005 01:14:23 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH 4/4] [NETLINK] make rtnetlink use netlink_check_skb Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 78 Lines: 4 The modification required to make rtnetlink.c use netlink_check_skb -- Pablo From pablo@eurodev.net Thu Feb 10 16:14:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:14:09 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0E4ET018196 for ; Thu, 10 Feb 2005 16:14:04 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001358.GFYX9125.smtp09.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:13:58 +0100 Message-ID: <420BF8CB.6080005@eurodev.net> Date: Fri, 11 Feb 2005 01:14:03 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH 2/4] [NETLINK] introduce netlink_check_skb function Content-Type: multipart/mixed; boundary="------------070807090606050805050302" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 2554 Lines: 86 This is a multi-part message in MIME format. --------------070807090606050805050302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch introduces a new function called netlink_check_skb that does the sanity checkings for received messages. -- Pablo --------------070807090606050805050302 Content-Type: text/x-patch; name="01process_skb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="01process_skb.patch" ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 +++ edited/net/netlink/af_netlink.c 2005-02-10 00:37:57 +01:00 @@ -1201,6 +1201,42 @@ netlink_unicast(in_skb->sk, skb, NETLINK_CB(in_skb).pid, MSG_DONTWAIT); } +/* + * Process one packet of messages. + * Malformed skbs with wrong lengths of messages are discarded silently. + */ +int netlink_process_skb(struct sk_buff *skb, + int (*process_msg)(struct sk_buff *skb, + struct nlmsghdr *nlh, + int *err)) +{ + int err; + struct nlmsghdr * nlh; + + while (skb->len >= NLMSG_SPACE(0)) { + u32 rlen; + + nlh = (struct nlmsghdr *)skb->data; + if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len) + return 0; + rlen = NLMSG_ALIGN(nlh->nlmsg_len); + if (rlen > skb->len) + rlen = skb->len; + if (process_msg(skb, nlh, &err)) { + /* Not error, but we must interrupt processing here: + * Note, that in this case we do not pull message + * from skb, it will be processed later. + */ + if (err == 0) + return -1; + netlink_ack(skb, nlh, err); + } else if (nlh->nlmsg_flags&NLM_F_ACK) + netlink_ack(skb, nlh, 0); + skb_pull(skb, rlen); + } + + return 0; +} #ifdef CONFIG_PROC_FS struct nl_seq_iter { @@ -1456,6 +1492,7 @@ MODULE_ALIAS_NETPROTO(PF_NETLINK); +EXPORT_SYMBOL(netlink_process_skb); EXPORT_SYMBOL(netlink_ack); EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); --- linux-2.5/include/linux/netlink.h.orig 2005-02-10 00:48:55.000000000 +0100 +++ linux-2.5/include/linux/netlink.h 2005-02-10 00:49:40.000000000 +0100 @@ -119,6 +119,9 @@ #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) +extern int +netlink_process_skb(struct sk_buff *skb, int (*process_msg)(struct sk_buff *skb, + struct nlmsghdr *nlh, int *err)); extern struct sock * netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); --------------070807090606050805050302-- From pablo@eurodev.net Thu Feb 10 16:13:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:13:55 -0800 (PST) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0DnwN018167 for ; Thu, 10 Feb 2005 16:13:50 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp08.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001343.WJNU4106.smtp08.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:13:43 +0100 Message-ID: <420BF8BB.5000809@eurodev.net> Date: Fri, 11 Feb 2005 01:13:47 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH 0/4] [NETLINK] unify checkings for clean messages and fix indentation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 873 Lines: 25 Hi, The following patches introduce a new function that check that the netlink messages received are clean. Actually some people performs such checkings, some don't and others simply do some half of them. I think that we must unify the behaviour of a netlink socket when it has to reply to malformed messages. Attached an indentation fix for netlink.h as well. 00indent-fix.patch: fixes broken indentation in netlink.h 01process_skb.patch: introduces the new function called netlink_check_skb that does the sanity checkings for received messages. 02xfrm.patch: the modification to make xfrm_user use such new function. 03rtnetlink.patch: same thing for rtnetlink. The 02 and 03 patches are straightforward conversions. If you are ok with this, I could post more patches to make other netlink sockets use this new function. -- Pablo From pablo@eurodev.net Thu Feb 10 16:13:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:14:02 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0Dv8f018174 for ; Thu, 10 Feb 2005 16:13:58 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001351.GFYN9125.smtp09.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:13:51 +0100 Message-ID: <420BF8C3.3050305@eurodev.net> Date: Fri, 11 Feb 2005 01:13:55 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH 1/4] [NETLINK] fix broken indentation in netlink.h Content-Type: multipart/mixed; boundary="------------010800010108090902080203" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 4185 Lines: 105 This is a multi-part message in MIME format. --------------010800010108090902080203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit the subject says all -- Pablo --------------010800010108090902080203 Content-Type: text/x-patch; name="00ident-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="00ident-fix.patch" ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-07 06:59:39 +01:00 +++ edited/include/linux/netlink.h 2005-02-10 01:16:41 +01:00 @@ -4,11 +4,11 @@ #include /* for sa_family_t */ #include -#define NETLINK_ROUTE 0 /* Routing/device hook */ -#define NETLINK_SKIP 1 /* Reserved for ENskip */ -#define NETLINK_USERSOCK 2 /* Reserved for user mode socket protocols */ -#define NETLINK_FIREWALL 3 /* Firewalling hook */ -#define NETLINK_TCPDIAG 4 /* TCP socket monitoring */ +#define NETLINK_ROUTE 0 /* Routing/device hook */ +#define NETLINK_SKIP 1 /* Reserved for ENskip */ +#define NETLINK_USERSOCK 2 /* For user mode socket protocols */ +#define NETLINK_FIREWALL 3 /* Firewalling hook */ +#define NETLINK_TCPDIAG 4 /* TCP socket monitoring */ #define NETLINK_NFLOG 5 /* netfilter/iptables ULOG */ #define NETLINK_XFRM 6 /* ipsec */ #define NETLINK_SELINUX 7 /* SELinux event notifications */ @@ -42,8 +42,10 @@ /* Flags values */ #define NLM_F_REQUEST 1 /* It is request message. */ -#define NLM_F_MULTI 2 /* Multipart message, terminated by NLMSG_DONE */ -#define NLM_F_ACK 4 /* Reply with ack, with zero or error code */ +#define NLM_F_MULTI 2 /* Multipart message, + terminated by NLMSG_DONE */ +#define NLM_F_ACK 4 /* Reply with ack, with zero or + error code */ #define NLM_F_ECHO 8 /* Echo this request */ /* Modifiers to GET request */ @@ -73,7 +75,8 @@ #define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len)) #define NLMSG_DATA(nlh) ((void*)(((char*)nlh) + NLMSG_LENGTH(0))) #define NLMSG_NEXT(nlh,len) ((len) -= NLMSG_ALIGN((nlh)->nlmsg_len), \ - (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len))) + (struct nlmsghdr*)(((char*)(nlh)) + \ + NLMSG_ALIGN((nlh)->nlmsg_len))) #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len <= (len)) @@ -90,7 +93,7 @@ struct nlmsghdr msg; }; -#define NET_MAJOR 36 /* Major 36 is reserved for networking */ +#define NET_MAJOR 36 /* Major 36 is reserved for networking */ enum { NETLINK_UNCONNECTED = 0, @@ -116,9 +119,11 @@ #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) -extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern struct sock * +netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); -extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); +extern int +netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, __u32 group, int allocation); extern void netlink_set_err(struct sock *ssk, __u32 pid, __u32 group, int code); @@ -127,7 +132,8 @@ /* finegrained unicast helpers: */ struct sock *netlink_getsockbyfilp(struct file *filp); -int netlink_attachskb(struct sock *sk, struct sk_buff *skb, int nonblock, long timeo); +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); @@ -175,7 +181,8 @@ extern int netlink_dump_start(struct sock *ssk, struct sk_buff *skb, struct nlmsghdr *nlh, - int (*dump)(struct sk_buff *skb, struct netlink_callback*), + int (*dump)(struct sk_buff *skb, + struct netlink_callback*), int (*done)(struct netlink_callback*)); --------------010800010108090902080203-- From pablo@eurodev.net Thu Feb 10 16:14:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:14:18 -0800 (PST) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0ECoW018295 for ; Thu, 10 Feb 2005 16:14:13 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp07.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001406.PCNB10926.smtp07.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:14:06 +0100 Message-ID: <420BF8D3.1060000@eurodev.net> Date: Fri, 11 Feb 2005 01:14:11 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH 3/4] [NETLINK] make xfrm_user use netlink_check_skb Content-Type: multipart/mixed; boundary="------------080805090606010004050501" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1615 Lines: 65 This is a multi-part message in MIME format. --------------080805090606010004050501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The modification required to make xfrm_user.c use netlink_check_skb -- Pablo --------------080805090606010004050501 Content-Type: text/x-patch; name="02xfrm.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="02xfrm.patch" ===== net/xfrm/xfrm_user.c 1.52 vs edited ===== --- 1.52/net/xfrm/xfrm_user.c 2005-01-26 06:53:19 +01:00 +++ edited/net/xfrm/xfrm_user.c 2005-02-10 00:15:16 +01:00 @@ -980,33 +980,6 @@ return -1; } -static int xfrm_user_rcv_skb(struct sk_buff *skb) -{ - int err; - struct nlmsghdr *nlh; - - while (skb->len >= NLMSG_SPACE(0)) { - u32 rlen; - - nlh = (struct nlmsghdr *) skb->data; - if (nlh->nlmsg_len < sizeof(*nlh) || - skb->len < nlh->nlmsg_len) - return 0; - rlen = NLMSG_ALIGN(nlh->nlmsg_len); - if (rlen > skb->len) - rlen = skb->len; - if (xfrm_user_rcv_msg(skb, nlh, &err) < 0) { - if (err == 0) - return -1; - netlink_ack(skb, nlh, err); - } else if (nlh->nlmsg_flags & NLM_F_ACK) - netlink_ack(skb, nlh, 0); - skb_pull(skb, rlen); - } - - return 0; -} - static void xfrm_netlink_rcv(struct sock *sk, int len) { do { @@ -1015,7 +988,7 @@ down(&xfrm_cfg_sem); while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) { - if (xfrm_user_rcv_skb(skb)) { + if (netlink_process_skb(skb, xfrm_user_rcv_msg)) { if (skb->len) skb_queue_head(&sk->sk_receive_queue, skb); --------------080805090606010004050501-- From pablo@eurodev.net Thu Feb 10 16:19:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:19:36 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0JW0c024148 for ; Thu, 10 Feb 2005 16:19:32 -0800 Received: from eurodev.net ([85.136.112.120]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211001926.GGRJ9125.smtp09.retemail.es@eurodev.net>; Fri, 11 Feb 2005 01:19:26 +0100 Message-ID: <420BFA12.1050504@eurodev.net> Date: Fri, 11 Feb 2005 01:19:30 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: Re: [PATCH 4/4] [NETLINK] make rtnetlink use netlink_check_skb References: <420BF8DF.4080407@eurodev.net> In-Reply-To: <420BF8DF.4080407@eurodev.net> Content-Type: multipart/mixed; boundary="------------040009010804030004010404" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 2015 Lines: 79 This is a multi-part message in MIME format. --------------040009010804030004010404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit oops, forgot to attach the patch Pablo Neira wrote: > The modification required to make rtnetlink.c use netlink_check_skb > > -- > Pablo > --------------040009010804030004010404 Content-Type: text/x-patch; name="03rtnetlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="03rtnetlink.patch" ===== net/core/rtnetlink.c 1.33 vs edited ===== --- 1.33/net/core/rtnetlink.c 2005-01-10 22:42:22 +01:00 +++ edited/net/core/rtnetlink.c 2005-02-10 00:14:59 +01:00 @@ -570,41 +570,6 @@ return -1; } -/* - * Process one packet of messages. - * Malformed skbs with wrong lengths of messages are discarded silently. - */ - -static inline int rtnetlink_rcv_skb(struct sk_buff *skb) -{ - int err; - struct nlmsghdr * nlh; - - while (skb->len >= NLMSG_SPACE(0)) { - u32 rlen; - - nlh = (struct nlmsghdr *)skb->data; - if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len) - return 0; - rlen = NLMSG_ALIGN(nlh->nlmsg_len); - if (rlen > skb->len) - rlen = skb->len; - if (rtnetlink_rcv_msg(skb, nlh, &err)) { - /* Not error, but we must interrupt processing here: - * Note, that in this case we do not pull message - * from skb, it will be processed later. - */ - if (err == 0) - return -1; - netlink_ack(skb, nlh, err); - } else if (nlh->nlmsg_flags&NLM_F_ACK) - netlink_ack(skb, nlh, 0); - skb_pull(skb, rlen); - } - - return 0; -} - /* * rtnetlink input queue processing routine: * - try to acquire shared lock. If it is failed, defer processing. @@ -622,7 +587,7 @@ return; while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) { - if (rtnetlink_rcv_skb(skb)) { + if (netlink_process_skb(skb, rtnetlink_rcv_msg)) { if (skb->len) skb_queue_head(&sk->sk_receive_queue, skb); --------------040009010804030004010404-- From yoshfuji@linux-ipv6.org Thu Feb 10 16:28:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:28:23 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0SCWK024888 for ; Thu, 10 Feb 2005 16:28:12 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B340733CC2; Fri, 11 Feb 2005 09:29:17 +0900 (JST) Date: Fri, 11 Feb 2005 09:29:16 +0900 (JST) Message-Id: <20050211.092916.50162307.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050210122523.41276d5a.davem@davemloft.net> References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <20050210122523.41276d5a.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1497 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: 476 Lines: 12 In article <20050210122523.41276d5a.davem@davemloft.net> (at Thu, 10 Feb 2005 12:25:23 -0800), "David S. Miller" says: > I guess this causes problems for ipv6 local addresses, it > will need to catch some callback to handle these events and > thus adjust the local address properly. Okay, I'll try to solve it: 1) catch NETDEV_CHANGEADDR 2) (try to) add new link-local address and deprecate old one. 3) (when DAD finishes) RS will be sent. --yoshfuji From jketreno@linux.intel.com Thu Feb 10 16:50:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 16:50:40 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0oJEt025793 for ; Thu, 10 Feb 2005 16:50:19 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1B0oDK8016633 for ; Fri, 11 Feb 2005 00:50:13 GMT Received: from [192.168.1.154] (hdlrvguser-315.hd.intel.com [10.127.53.78]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j1B0o8Kt029797 for ; Fri, 11 Feb 2005 00:50:09 GMT Message-ID: <420C0117.9070603@linux.intel.com> Date: Thu, 10 Feb 2005 18:49:27 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <20050208042950.GD8366@jm.kir.nu> <420885B6.7090606@linux.intel.com> <42094A6D.9080508@pobox.com> In-Reply-To: <42094A6D.9080508@pobox.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040200080309090603080508" X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 159348 Lines: 5415 This is a multi-part message in MIME format. --------------040200080309090603080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff Garzik wrote: > Just to keep everything moving, my recommendation would be to move the > code to net/*, and resend the patch (with whatever changes you have > made to date). Alrighty... attached is the latest diff against netdev-2.6. Changes since last version: * Includes previously missing files * Lots of whitespace cleanups * Various syntactical cleanups * Moved to net/ieee80211 from drivers/net/wireless/ieee80211 -- I wasn't sure what people's thoughts were for how Wireless is currently leveled under menuconfig. * Moved ieee80211.h and ieee80211_crypt.h to include/net * Updated descriptions of WEP, TKIP, and CCMP software cipher suites and reworked Makefile to match * Verified that the patch applies, can be configured via menuconfig, and builds successfully * Changed AES_586 selection to just AES Also attached is the list of items folks have sent me that I have not resolved (if anyone wants to throw me a patch that hits any of these, feel free) I've pushed the above changes to bk://ipw.bkbits.net/ipw-2.6 if anyone wants to use them on conjunction w/ the current development snapshots of the ipw* drivers. James --------------040200080309090603080508 Content-Type: text/x-patch; name="ieee80211-021005.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ieee80211-021005.patch" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/include/net/ieee80211.h netdev-2.6-ipw/include/net/ieee80211.h --- netdev-2.6/include/net/ieee80211.h 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/include/net/ieee80211.h 2005-02-10 16:46:19 -06:00 @@ -0,0 +1,883 @@ +/* + * Merged with mainline ieee80211.h in Aug 2004. Original ieee802_11 + * remains copyright by the original authors + * + * Portions of the merged code are based on Host AP (software wireless + * LAN access point) driver for Intersil Prism2/2.5/3. + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * + * Adaption to a generic IEEE 802.11 stack by James Ketrenos + * + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ +#ifndef IEEE80211_H +#define IEEE80211_H +#include /* ETH_ALEN */ +#include /* ARRAY_SIZE */ + +#if WIRELESS_EXT < 17 +#define IW_QUAL_QUAL_INVALID 0x10 +#define IW_QUAL_LEVEL_INVALID 0x20 +#define IW_QUAL_NOISE_INVALID 0x40 +#define IW_QUAL_QUAL_UPDATED 0x1 +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define IW_QUAL_NOISE_UPDATED 0x4 +#endif + +#define IEEE80211_DATA_LEN 2304 +/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section + 6.2.1.1.2. + + The figure in section 7.1.2 suggests a body size of up to 2312 + bytes is allowed, which is a bit confusing, I suspect this + represents the 2304 bytes of real data, plus a possible 8 bytes of + WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ + + +#define IEEE80211_HLEN 30 +#define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN) + +struct ieee80211_hdr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; + u8 addr4[ETH_ALEN]; +} __attribute__ ((packed)); + +struct ieee80211_hdr_3addr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; +} __attribute__ ((packed)); + +static const char *eap_types[] = { + "EAP-Packet", "EAPOL-Start", "EAPOL-Logoff", "EAPOL-Key", + "EAPOL-Encap-ASF-Alert", "Unknown" +}; + +static inline const char *eap_get_type(int type) +{ + if (type > ARRAY_SIZE(eap_types)) + type = ARRAY_SIZE(eap_types) - 1; + return eap_types[type]; +} + +struct eapol { + u8 snap[6]; + u16 ethertype; + u8 version; + u8 type; + u16 length; +} __attribute__ ((packed)); + +#define IEEE80211_3ADDR_LEN 24 +#define IEEE80211_4ADDR_LEN 30 +#define IEEE80211_FCS_LEN 4 + +#define MIN_FRAG_THRESHOLD 256U +#define MAX_FRAG_THRESHOLD 2346U + +/* Frame control field constants */ +#define IEEE80211_FCTL_VERS 0x0002 +#define IEEE80211_FCTL_FTYPE 0x000c +#define IEEE80211_FCTL_STYPE 0x00f0 +#define IEEE80211_FCTL_TODS 0x0100 +#define IEEE80211_FCTL_FROMDS 0x0200 +#define IEEE80211_FCTL_MOREFRAGS 0x0400 +#define IEEE80211_FCTL_RETRY 0x0800 +#define IEEE80211_FCTL_PM 0x1000 +#define IEEE80211_FCTL_MOREDATA 0x2000 +#define IEEE80211_FCTL_WEP 0x4000 +#define IEEE80211_FCTL_ORDER 0x8000 + +#define IEEE80211_FTYPE_MGMT 0x0000 +#define IEEE80211_FTYPE_CTL 0x0004 +#define IEEE80211_FTYPE_DATA 0x0008 + +/* management */ +#define IEEE80211_STYPE_ASSOC_REQ 0x0000 +#define IEEE80211_STYPE_ASSOC_RESP 0x0010 +#define IEEE80211_STYPE_REASSOC_REQ 0x0020 +#define IEEE80211_STYPE_REASSOC_RESP 0x0030 +#define IEEE80211_STYPE_PROBE_REQ 0x0040 +#define IEEE80211_STYPE_PROBE_RESP 0x0050 +#define IEEE80211_STYPE_BEACON 0x0080 +#define IEEE80211_STYPE_ATIM 0x0090 +#define IEEE80211_STYPE_DISASSOC 0x00A0 +#define IEEE80211_STYPE_AUTH 0x00B0 +#define IEEE80211_STYPE_DEAUTH 0x00C0 + +/* control */ +#define IEEE80211_STYPE_PSPOLL 0x00A0 +#define IEEE80211_STYPE_RTS 0x00B0 +#define IEEE80211_STYPE_CTS 0x00C0 +#define IEEE80211_STYPE_ACK 0x00D0 +#define IEEE80211_STYPE_CFEND 0x00E0 +#define IEEE80211_STYPE_CFENDACK 0x00F0 + +/* data */ +#define IEEE80211_STYPE_DATA 0x0000 +#define IEEE80211_STYPE_DATA_CFACK 0x0010 +#define IEEE80211_STYPE_DATA_CFPOLL 0x0020 +#define IEEE80211_STYPE_DATA_CFACKPOLL 0x0030 +#define IEEE80211_STYPE_NULLFUNC 0x0040 +#define IEEE80211_STYPE_CFACK 0x0050 +#define IEEE80211_STYPE_CFPOLL 0x0060 +#define IEEE80211_STYPE_CFACKPOLL 0x0070 + +#define IEEE80211_SCTL_FRAG 0x000F +#define IEEE80211_SCTL_SEQ 0xFFF0 + + +/* debug macros */ + +#ifdef CONFIG_IEEE80211_DEBUG +extern u32 ieee80211_debug_level; +#define IEEE80211_DEBUG(level, fmt, args...) \ +do { if (ieee80211_debug_level & (level)) \ + printk(KERN_DEBUG "ieee80211: %c %s " fmt, \ + in_interrupt() ? 'I' : 'U', __FUNCTION__ , ## args); } while (0) +#else +#define IEEE80211_DEBUG(level, fmt, args...) do {} while (0) +#endif /* CONFIG_IEEE80211_DEBUG */ + +/* + * To use the debug system; + * + * If you are defining a new debug classification, simply add it to the #define + * list here in the form of: + * + * #define IEEE80211_DL_xxxx VALUE + * + * shifting value to the left one bit from the previous entry. xxxx should be + * the name of the classification (for example, WEP) + * + * You then need to either add a IEEE80211_xxxx_DEBUG() macro definition for your + * classification, or use IEEE80211_DEBUG(IEEE80211_DL_xxxx, ...) whenever you want + * to send output to that classification. + * + * To add your debug level to the list of levels seen when you perform + * + * % cat /proc/net/ipw/debug_level + * + * you simply need to add your entry to the ipw_debug_levels array. + * + * If you do not see debug_level in /proc/net/ipw then you do not have + * CONFIG_IEEE80211_DEBUG defined in your kernel configuration + * + */ + +#define IEEE80211_DL_INFO (1<<0) +#define IEEE80211_DL_WX (1<<1) +#define IEEE80211_DL_SCAN (1<<2) +#define IEEE80211_DL_STATE (1<<3) +#define IEEE80211_DL_MGMT (1<<4) +#define IEEE80211_DL_FRAG (1<<5) +#define IEEE80211_DL_EAP (1<<6) +#define IEEE80211_DL_DROP (1<<7) + +#define IEEE80211_DL_TX (1<<8) +#define IEEE80211_DL_RX (1<<9) + +#define IEEE80211_ERROR(f, a...) printk(KERN_ERR "ieee80211: " f, ## a) +#define IEEE80211_WARNING(f, a...) printk(KERN_WARNING "ieee80211: " f, ## a) +#define IEEE80211_DEBUG_INFO(f, a...) IEEE80211_DEBUG(IEEE80211_DL_INFO, f, ## a) + +#define IEEE80211_DEBUG_WX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_WX, f, ## a) +#define IEEE80211_DEBUG_SCAN(f, a...) IEEE80211_DEBUG(IEEE80211_DL_SCAN, f, ## a) +#define IEEE80211_DEBUG_STATE(f, a...) IEEE80211_DEBUG(IEEE80211_DL_STATE, f, ## a) +#define IEEE80211_DEBUG_MGMT(f, a...) IEEE80211_DEBUG(IEEE80211_DL_MGMT, f, ## a) +#define IEEE80211_DEBUG_FRAG(f, a...) IEEE80211_DEBUG(IEEE80211_DL_FRAG, f, ## a) +#define IEEE80211_DEBUG_EAP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_EAP, f, ## a) +#define IEEE80211_DEBUG_DROP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_DROP, f, ## a) +#define IEEE80211_DEBUG_TX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_TX, f, ## a) +#define IEEE80211_DEBUG_RX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_RX, f, ## a) +#include +#include +#include /* ARPHRD_ETHER */ + +#ifndef WIRELESS_SPY +#define WIRELESS_SPY // enable iwspy support +#endif +#include // new driver API + +#ifndef ETH_P_PAE +#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ +#endif /* ETH_P_PAE */ + +#define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ + +#ifndef ETH_P_80211_RAW +#define ETH_P_80211_RAW (ETH_P_ECONET + 1) +#endif + +/* IEEE 802.11 defines */ + +#define P80211_OUI_LEN 3 + +struct ieee80211_snap_hdr { + + u8 dsap; /* always 0xAA */ + u8 ssap; /* always 0xAA */ + u8 ctrl; /* always 0x03 */ + u8 oui[P80211_OUI_LEN]; /* organizational universal id */ + +} __attribute__ ((packed)); + +#define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) + +#define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) +#define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) + +#define WLAN_GET_SEQ_FRAG(seq) ((seq) & IEEE80211_SCTL_FRAG) +#define WLAN_GET_SEQ_SEQ(seq) ((seq) & IEEE80211_SCTL_SEQ) + +/* Authentication algorithms */ +#define WLAN_AUTH_OPEN 0 +#define WLAN_AUTH_SHARED_KEY 1 + +#define WLAN_AUTH_CHALLENGE_LEN 128 + +#define WLAN_CAPABILITY_BSS (1<<0) +#define WLAN_CAPABILITY_IBSS (1<<1) +#define WLAN_CAPABILITY_CF_POLLABLE (1<<2) +#define WLAN_CAPABILITY_CF_POLL_REQUEST (1<<3) +#define WLAN_CAPABILITY_PRIVACY (1<<4) +#define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5) +#define WLAN_CAPABILITY_PBCC (1<<6) +#define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7) + +/* Status codes */ +#define WLAN_STATUS_SUCCESS 0 +#define WLAN_STATUS_UNSPECIFIED_FAILURE 1 +#define WLAN_STATUS_CAPS_UNSUPPORTED 10 +#define WLAN_STATUS_REASSOC_NO_ASSOC 11 +#define WLAN_STATUS_ASSOC_DENIED_UNSPEC 12 +#define WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG 13 +#define WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION 14 +#define WLAN_STATUS_CHALLENGE_FAIL 15 +#define WLAN_STATUS_AUTH_TIMEOUT 16 +#define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17 +#define WLAN_STATUS_ASSOC_DENIED_RATES 18 +/* 802.11b */ +#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19 +#define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20 +#define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21 + +/* Reason codes */ +#define WLAN_REASON_UNSPECIFIED 1 +#define WLAN_REASON_PREV_AUTH_NOT_VALID 2 +#define WLAN_REASON_DEAUTH_LEAVING 3 +#define WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY 4 +#define WLAN_REASON_DISASSOC_AP_BUSY 5 +#define WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA 6 +#define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7 +#define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8 +#define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 + + +/* Information Element IDs */ +#define WLAN_EID_SSID 0 +#define WLAN_EID_SUPP_RATES 1 +#define WLAN_EID_FH_PARAMS 2 +#define WLAN_EID_DS_PARAMS 3 +#define WLAN_EID_CF_PARAMS 4 +#define WLAN_EID_TIM 5 +#define WLAN_EID_IBSS_PARAMS 6 +#define WLAN_EID_CHALLENGE 16 +#define WLAN_EID_RSN 48 +#define WLAN_EID_GENERIC 221 + +#define IEEE80211_MGMT_HDR_LEN 24 +#define IEEE80211_DATA_HDR3_LEN 24 +#define IEEE80211_DATA_HDR4_LEN 30 + + +#define IEEE80211_STATMASK_SIGNAL (1<<0) +#define IEEE80211_STATMASK_RSSI (1<<1) +#define IEEE80211_STATMASK_NOISE (1<<2) +#define IEEE80211_STATMASK_RATE (1<<3) +#define IEEE80211_STATMASK_WEMASK 0x7 + + +#define IEEE80211_CCK_MODULATION (1<<0) +#define IEEE80211_OFDM_MODULATION (1<<1) + +#define IEEE80211_24GHZ_BAND (1<<0) +#define IEEE80211_52GHZ_BAND (1<<1) + +#define IEEE80211_CCK_RATE_1MB 0x02 +#define IEEE80211_CCK_RATE_2MB 0x04 +#define IEEE80211_CCK_RATE_5MB 0x0B +#define IEEE80211_CCK_RATE_11MB 0x16 +#define IEEE80211_OFDM_RATE_6MB 0x0C +#define IEEE80211_OFDM_RATE_9MB 0x12 +#define IEEE80211_OFDM_RATE_12MB 0x18 +#define IEEE80211_OFDM_RATE_18MB 0x24 +#define IEEE80211_OFDM_RATE_24MB 0x30 +#define IEEE80211_OFDM_RATE_36MB 0x48 +#define IEEE80211_OFDM_RATE_48MB 0x60 +#define IEEE80211_OFDM_RATE_54MB 0x6C +#define IEEE80211_BASIC_RATE_MASK 0x80 + +#define IEEE80211_CCK_RATE_1MB_MASK (1<<0) +#define IEEE80211_CCK_RATE_2MB_MASK (1<<1) +#define IEEE80211_CCK_RATE_5MB_MASK (1<<2) +#define IEEE80211_CCK_RATE_11MB_MASK (1<<3) +#define IEEE80211_OFDM_RATE_6MB_MASK (1<<4) +#define IEEE80211_OFDM_RATE_9MB_MASK (1<<5) +#define IEEE80211_OFDM_RATE_12MB_MASK (1<<6) +#define IEEE80211_OFDM_RATE_18MB_MASK (1<<7) +#define IEEE80211_OFDM_RATE_24MB_MASK (1<<8) +#define IEEE80211_OFDM_RATE_36MB_MASK (1<<9) +#define IEEE80211_OFDM_RATE_48MB_MASK (1<<10) +#define IEEE80211_OFDM_RATE_54MB_MASK (1<<11) + +#define IEEE80211_CCK_RATES_MASK 0x0000000F +#define IEEE80211_CCK_BASIC_RATES_MASK (IEEE80211_CCK_RATE_1MB_MASK | \ + IEEE80211_CCK_RATE_2MB_MASK) +#define IEEE80211_CCK_DEFAULT_RATES_MASK (IEEE80211_CCK_BASIC_RATES_MASK | \ + IEEE80211_CCK_RATE_5MB_MASK | \ + IEEE80211_CCK_RATE_11MB_MASK) + +#define IEEE80211_OFDM_RATES_MASK 0x00000FF0 +#define IEEE80211_OFDM_BASIC_RATES_MASK (IEEE80211_OFDM_RATE_6MB_MASK | \ + IEEE80211_OFDM_RATE_12MB_MASK | \ + IEEE80211_OFDM_RATE_24MB_MASK) +#define IEEE80211_OFDM_DEFAULT_RATES_MASK (IEEE80211_OFDM_BASIC_RATES_MASK | \ + IEEE80211_OFDM_RATE_9MB_MASK | \ + IEEE80211_OFDM_RATE_18MB_MASK | \ + IEEE80211_OFDM_RATE_36MB_MASK | \ + IEEE80211_OFDM_RATE_48MB_MASK | \ + IEEE80211_OFDM_RATE_54MB_MASK) +#define IEEE80211_DEFAULT_RATES_MASK (IEEE80211_OFDM_DEFAULT_RATES_MASK | \ + IEEE80211_CCK_DEFAULT_RATES_MASK) + +#define IEEE80211_NUM_OFDM_RATES 8 +#define IEEE80211_NUM_CCK_RATES 4 +#define IEEE80211_OFDM_SHIFT_MASK_A 4 + + + + +/* NOTE: This data is for statistical purposes; not all hardware provides this + * information for frames received. Not setting these will not cause + * any adverse affects. */ +struct ieee80211_rx_stats { + u32 mac_time; + s8 rssi; + u8 signal; + u8 noise; + u16 rate; /* in 100 kbps */ + u8 received_channel; + u8 control; + u8 mask; + u8 freq; + u16 len; +}; + +/* IEEE 802.11 requires that STA supports concurrent reception of at least + * three fragmented frames. This define can be increased to support more + * concurrent frames, but it should be noted that each entry can consume about + * 2 kB of RAM and increasing cache size will slow down frame reassembly. */ +#define IEEE80211_FRAG_CACHE_LEN 4 + +struct ieee80211_frag_entry { + unsigned long first_frag_time; + unsigned int seq; + unsigned int last_frag; + struct sk_buff *skb; + u8 src_addr[ETH_ALEN]; + u8 dst_addr[ETH_ALEN]; +}; + +struct ieee80211_stats { + unsigned int tx_unicast_frames; + unsigned int tx_multicast_frames; + unsigned int tx_fragments; + unsigned int tx_unicast_octets; + unsigned int tx_multicast_octets; + unsigned int tx_deferred_transmissions; + unsigned int tx_single_retry_frames; + unsigned int tx_multiple_retry_frames; + unsigned int tx_retry_limit_exceeded; + unsigned int tx_discards; + unsigned int rx_unicast_frames; + unsigned int rx_multicast_frames; + unsigned int rx_fragments; + unsigned int rx_unicast_octets; + unsigned int rx_multicast_octets; + unsigned int rx_fcs_errors; + unsigned int rx_discards_no_buffer; + unsigned int tx_discards_wrong_sa; + unsigned int rx_discards_undecryptable; + unsigned int rx_message_in_msg_fragments; + unsigned int rx_message_in_bad_msg_fragments; +}; + +struct ieee80211_device; + +#include "ieee80211_crypt.h" + +#define SEC_KEY_1 (1<<0) +#define SEC_KEY_2 (1<<1) +#define SEC_KEY_3 (1<<2) +#define SEC_KEY_4 (1<<3) +#define SEC_ACTIVE_KEY (1<<4) +#define SEC_AUTH_MODE (1<<5) +#define SEC_UNICAST_GROUP (1<<6) +#define SEC_LEVEL (1<<7) +#define SEC_ENABLED (1<<8) + +#define SEC_LEVEL_0 0 /* None */ +#define SEC_LEVEL_1 1 /* WEP 40 and 104 bit */ +#define SEC_LEVEL_2 2 /* Level 1 + TKIP */ +#define SEC_LEVEL_2_CKIP 3 /* Level 1 + CKIP */ +#define SEC_LEVEL_3 4 /* Level 2 + CCMP */ + +#define WEP_KEYS 4 +#define WEP_KEY_LEN 13 + +struct ieee80211_security { + u16 active_key:2, + enabled:1, + auth_mode:2, + auth_algo:4, + unicast_uses_group:1; + u8 key_sizes[WEP_KEYS]; + u8 keys[WEP_KEYS][WEP_KEY_LEN]; + u8 level; + u16 flags; +} __attribute__ ((packed)); + + +/* + + 802.11 data frame from AP + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `-------------------------------------------------------------------' + +Total: 28-2340 bytes + +*/ + +struct ieee80211_header_data { + u16 frame_ctl; + u16 duration_id; + u8 addr1[6]; + u8 addr2[6]; + u8 addr3[6]; + u16 seq_ctrl; +}; + +#define BEACON_PROBE_SSID_ID_POSITION 12 + +/* Management Frame Information Element Types */ +#define MFIE_TYPE_SSID 0 +#define MFIE_TYPE_RATES 1 +#define MFIE_TYPE_FH_SET 2 +#define MFIE_TYPE_DS_SET 3 +#define MFIE_TYPE_CF_SET 4 +#define MFIE_TYPE_TIM 5 +#define MFIE_TYPE_IBSS_SET 6 +#define MFIE_TYPE_CHALLENGE 16 +#define MFIE_TYPE_RSN 48 +#define MFIE_TYPE_RATES_EX 50 +#define MFIE_TYPE_GENERIC 221 + +struct ieee80211_info_element_hdr { + u8 id; + u8 len; +} __attribute__ ((packed)); + +struct ieee80211_info_element { + u8 id; + u8 len; + u8 data[0]; +} __attribute__ ((packed)); + +/* + * These are the data types that can make up management packets + * + u16 auth_algorithm; + u16 auth_sequence; + u16 beacon_interval; + u16 capability; + u8 current_ap[ETH_ALEN]; + u16 listen_interval; + struct { + u16 association_id:14, reserved:2; + } __attribute__ ((packed)); + u32 time_stamp[2]; + u16 reason; + u16 status; +*/ + +struct ieee80211_authentication { + struct ieee80211_header_data header; + u16 algorithm; + u16 transaction; + u16 status; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + + +struct ieee80211_probe_response { + struct ieee80211_header_data header; + u32 time_stamp[2]; + u16 beacon_interval; + u16 capability; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_request_frame { + u16 capability; + u16 listen_interval; + u8 current_ap[ETH_ALEN]; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_response_frame { + struct ieee80211_hdr_3addr header; + u16 capability; + u16 status; + u16 aid; + struct ieee80211_info_element info_element; /* supported rates */ +} __attribute__ ((packed)); + + +struct ieee80211_txb { + u8 nr_frags; + u8 encrypted; + u16 reserved; + u16 frag_size; + u16 payload_size; + struct sk_buff *fragments[0]; +}; + + +/* SWEEP TABLE ENTRIES NUMBER*/ +#define MAX_SWEEP_TAB_ENTRIES 42 +#define MAX_SWEEP_TAB_ENTRIES_PER_PACKET 7 +/* MAX_RATES_LENGTH needs to be 12. The spec says 8, and many APs + * only use 8, and then use extended rates for the remaining supported + * rates. Other APs, however, stick all of their supported rates on the + * main rates information element... */ +#define MAX_RATES_LENGTH ((u8)12) +#define MAX_RATES_EX_LENGTH ((u8)16) +#define MAX_NETWORK_COUNT 128 + +#define CRC_LENGTH 4U + +#define MAX_WPA_IE_LEN 64 + +#define NETWORK_EMPTY_ESSID (1<<0) +#define NETWORK_HAS_OFDM (1<<1) +#define NETWORK_HAS_CCK (1<<2) + +struct ieee80211_network { + /* These entries are used to identify a unique network */ + u8 bssid[ETH_ALEN]; + u8 channel; + /* Ensure null-terminated for any debug msgs */ + u8 ssid[IW_ESSID_MAX_SIZE + 1]; + u8 ssid_len; + + /* These are network statistics */ + struct ieee80211_rx_stats stats; + u16 capability; + u8 rates[MAX_RATES_LENGTH]; + u8 rates_len; + u8 rates_ex[MAX_RATES_EX_LENGTH]; + u8 rates_ex_len; + unsigned long last_scanned; + u8 mode; + u8 flags; + u32 last_associate; + u32 time_stamp[2]; + u16 beacon_interval; + u16 listen_interval; + u16 atim_window; + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; + u8 rsn_ie[MAX_WPA_IE_LEN]; + size_t rsn_ie_len; + struct list_head list; +}; + +enum ieee80211_state { + IEEE80211_UNINITIALIZED = 0, + IEEE80211_INITIALIZED, + IEEE80211_ASSOCIATING, + IEEE80211_ASSOCIATED, + IEEE80211_AUTHENTICATING, + IEEE80211_AUTHENTICATED, + IEEE80211_SHUTDOWN +}; + +#define DEFAULT_MAX_SCAN_AGE (15 * HZ) +#define DEFAULT_FTS 2346 +#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x" +#define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5] + + +extern inline int is_multicast_ether_addr(const u8 *addr) +{ + return ((addr[0] != 0xff) && (0x01 & addr[0])); +} + +extern inline int is_broadcast_ether_addr(const u8 *addr) +{ + return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) && \ + (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff)); +} + +#define CFG_IEEE80211_RESERVE_FCS (1<<0) +#define CFG_IEEE80211_COMPUTE_FCS (1<<1) + +struct ieee80211_device { + struct net_device *dev; + + /* Bookkeeping structures */ + struct net_device_stats stats; + struct ieee80211_stats ieee_stats; + + /* Probe / Beacon management */ + struct list_head network_free_list; + struct list_head network_list; + struct ieee80211_network *networks; + int scans; + int scan_age; + + int iw_mode; /* operating mode (IW_MODE_*) */ + + spinlock_t lock; + + int tx_headroom; /* Set to size of any additional room needed at front + * of allocated Tx SKBs */ + u32 config; + + /* WEP and other encryption related settings at the device level */ + int open_wep; /* Set to 1 to allow unencrypted frames */ + + int reset_on_keychange; /* Set to 1 if the HW needs to be reset on + * WEP key changes */ + + /* If the host performs {en,de}cryption, then set to 1 */ + int host_encrypt; + int host_decrypt; + int ieee802_1x; /* is IEEE 802.1X used */ + + /* WPA data */ + int wpa_enabled; + int drop_unencrypted; + int tkip_countermeasures; + int privacy_invoked; + size_t wpa_ie_len; + u8 *wpa_ie; + + struct list_head crypt_deinit_list; + struct ieee80211_crypt_data *crypt[WEP_KEYS]; + int tx_keyidx; /* default TX key index (crypt[tx_keyidx]) */ + struct timer_list crypt_deinit_timer; + + int bcrx_sta_key; /* use individual keys to override default keys even + * with RX of broad/multicast frames */ + + /* Fragmentation structures */ + struct ieee80211_frag_entry frag_cache[IEEE80211_FRAG_CACHE_LEN]; + unsigned int frag_next_idx; + u16 fts; /* Fragmentation Threshold */ + + /* Association info */ + u8 bssid[ETH_ALEN]; + + enum ieee80211_state state; + + int mode; /* A, B, G */ + int modulation; /* CCK, OFDM */ + int freq_band; /* 2.4Ghz, 5.2Ghz, Mixed */ + int abg_ture; /* ABG flag */ + + /* Callback functions */ + void (*set_security)(struct net_device *dev, + struct ieee80211_security *sec); + int (*hard_start_xmit)(struct ieee80211_txb *txb, + struct net_device *dev); + int (*reset_port)(struct net_device *dev); + + /* This must be the last item so that it points to the data + * allocated beyond this structure by alloc_ieee80211 */ + u8 priv[0]; +}; + +#define IEEE_A (1<<0) +#define IEEE_B (1<<1) +#define IEEE_G (1<<2) +#define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G) + +extern inline void *ieee80211_priv(struct net_device *dev) +{ + return ((struct ieee80211_device *)netdev_priv(dev))->priv; +} + +extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len) +{ + /* Single white space is for Linksys APs */ + if (essid_len == 1 && essid[0] == ' ') + return 1; + + /* Otherwise, if the entire essid is 0, we assume it is hidden */ + while (essid_len) { + essid_len--; + if (essid[essid_len] != '\0') + return 0; + } + + return 1; +} + +extern inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode) +{ + /* + * It is possible for both access points and our device to support + * combinations of modes, so as long as there is one valid combination + * of ap/device supported modes, then return success + * + */ + if ((mode & IEEE_A) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_52GHZ_BAND)) + return 1; + + if ((mode & IEEE_G) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + if ((mode & IEEE_B) && + (ieee->modulation & IEEE80211_CCK_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + return 0; +} + +extern inline int ieee80211_get_hdrlen(u16 fc) +{ + int hdrlen = 24; + + switch (WLAN_FC_GET_TYPE(fc)) { + case IEEE80211_FTYPE_DATA: + if ((fc & IEEE80211_FCTL_FROMDS) && (fc & IEEE80211_FCTL_TODS)) + hdrlen = 30; /* Addr4 */ + break; + case IEEE80211_FTYPE_CTL: + switch (WLAN_FC_GET_STYPE(fc)) { + case IEEE80211_STYPE_CTS: + case IEEE80211_STYPE_ACK: + hdrlen = 10; + break; + default: + hdrlen = 16; + break; + } + break; + } + + return hdrlen; +} + + + +/* ieee80211.c */ +extern void free_ieee80211(struct net_device *dev); +extern struct net_device *alloc_ieee80211(int sizeof_priv); + +extern int ieee80211_set_encryption(struct ieee80211_device *ieee); + +/* ieee80211_tx.c */ + + +extern int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev); +extern void ieee80211_txb_free(struct ieee80211_txb *); + + +/* ieee80211_rx.c */ +extern int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats); +extern void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats); + +/* iee80211_wx.c */ +extern int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); + + +extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee) +{ + ieee->scans++; +} + +extern inline int ieee80211_get_scans(struct ieee80211_device *ieee) +{ + return ieee->scans; +} + +static inline const char *escape_essid(const char *essid, u8 essid_len) { + static char escaped[IW_ESSID_MAX_SIZE * 2 + 1]; + const char *s = essid; + char *d = escaped; + + if (ieee80211_is_empty_essid(essid, essid_len)) { + memcpy(escaped, "", sizeof("")); + return escaped; + } + + essid_len = min(essid_len, (u8)IW_ESSID_MAX_SIZE); + while (essid_len--) { + if (*s == '\0') { + *d++ = '\\'; + *d++ = '0'; + s++; + } else { + *d++ = *s++; + } + } + *d = '\0'; + return escaped; +} + +#ifndef offset_in_page +#define offset_in_page(p) ((unsigned long)(p) & ~PAGE_MASK) +#endif + +#endif /* IEEE80211_H */ diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/include/net/ieee80211_crypt.h netdev-2.6-ipw/include/net/ieee80211_crypt.h --- netdev-2.6/include/net/ieee80211_crypt.h 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/include/net/ieee80211_crypt.h 2005-02-10 16:46:19 -06:00 @@ -0,0 +1,86 @@ +/* + * Original code based on Host AP (software wireless LAN access point) driver + * for Intersil Prism2/2.5/3. + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * + * Adaption to a generic IEEE 802.11 stack by James Ketrenos + * + * + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +/* + * This file defines the interface to the ieee80211 crypto module. + */ +#ifndef IEEE80211_CRYPT_H +#define IEEE80211_CRYPT_H + +#include + +struct ieee80211_crypto_ops { + const char *name; + + /* init new crypto context (e.g., allocate private data space, + * select IV, etc.); returns NULL on failure or pointer to allocated + * private data on success */ + void * (*init)(int keyidx); + + /* deinitialize crypto context and free allocated private data */ + void (*deinit)(void *priv); + + /* encrypt/decrypt return < 0 on error or >= 0 on success. The return + * value from decrypt_mpdu is passed as the keyidx value for + * decrypt_msdu. skb must have enough head and tail room for the + * encryption; if not, error will be returned; these functions are + * called for all MPDUs (i.e., fragments). + */ + int (*encrypt_mpdu)(struct sk_buff *skb, int hdr_len, void *priv); + int (*decrypt_mpdu)(struct sk_buff *skb, int hdr_len, void *priv); + + /* These functions are called for full MSDUs, i.e. full frames. + * These can be NULL if full MSDU operations are not needed. */ + int (*encrypt_msdu)(struct sk_buff *skb, int hdr_len, void *priv); + int (*decrypt_msdu)(struct sk_buff *skb, int keyidx, int hdr_len, + void *priv); + + int (*set_key)(void *key, int len, u8 *seq, void *priv); + int (*get_key)(void *key, int len, u8 *seq, void *priv); + + /* procfs handler for printing out key information and possible + * statistics */ + char * (*print_stats)(char *p, void *priv); + + /* maximum number of bytes added by encryption; encrypt buf is + * allocated with extra_prefix_len bytes, copy of in_buf, and + * extra_postfix_len; encrypt need not use all this space, but + * the result must start at the beginning of the buffer and correct + * length must be returned */ + int extra_prefix_len, extra_postfix_len; + + struct module *owner; +}; + +struct ieee80211_crypt_data { + struct list_head list; /* delayed deletion list */ + struct ieee80211_crypto_ops *ops; + void *priv; + atomic_t refcnt; +}; + +int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops); +int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops); +struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name); +void ieee80211_crypt_deinit_entries(struct ieee80211_device *, int); +void ieee80211_crypt_deinit_handler(unsigned long); +void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee, + struct ieee80211_crypt_data **crypt); + +#endif diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/Kconfig netdev-2.6-ipw/net/Kconfig --- netdev-2.6/net/Kconfig 2005-02-04 10:11:14 -06:00 +++ netdev-2.6-ipw/net/Kconfig 2005-02-10 17:40:59 -06:00 @@ -653,6 +653,8 @@ source "net/bluetooth/Kconfig" +source "net/ieee80211/Kconfig" + source "drivers/net/Kconfig" endmenu diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/Makefile netdev-2.6-ipw/net/Makefile --- netdev-2.6/net/Makefile 2005-02-04 10:11:14 -06:00 +++ netdev-2.6-ipw/net/Makefile 2005-02-10 17:40:04 -06:00 @@ -42,6 +42,7 @@ obj-$(CONFIG_ECONET) += econet/ obj-$(CONFIG_VLAN_8021Q) += 8021q/ obj-$(CONFIG_IP_SCTP) += sctp/ +obj-$(CONFIG_IEEE80211) += ieee80211/ ifeq ($(CONFIG_NET),y) obj-$(CONFIG_SYSCTL) += sysctl_net.o diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/Kconfig netdev-2.6-ipw/net/ieee80211/Kconfig --- netdev-2.6/net/ieee80211/Kconfig 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/Kconfig 2005-02-10 17:48:14 -06:00 @@ -0,0 +1,71 @@ +config IEEE80211 + tristate "Generic IEEE 802.11 Networking Stack" + select NET_RADIO + ---help--- + This option enables the hardware independent IEEE 802.11 + networking stack. This option will also select NET_RADIO. + +config IEEE80211_DEBUG + bool "Enable full debugging output" + depends on IEEE80211 + ---help--- + This option will enable debug tracing output for the + ieee80211 network stack. + + This will result in the kernel module being ~70k larger. You + can control which debug output is sent to the kernel log by + setting the value in + + /proc/net/ieee80211/debug_level + + For example: + + % echo 0x00000FFO > /proc/net/ieee80211/debug_level + + For a list of values you can assign to debug_level, you + can look at the bit mask values in + + If you are not trying to debug or develop the ieee80211 + subsystem, you most likely want to say N here. + +config IEEE80211_CRYPT_WEP + tristate "IEEE 802.11 WEP encryption (802.1x)" + depends on IEEE80211 + select CRYPTO + select CRYPTO_ARC4 + select CRC32 + ---help--- + Include software based cipher suites in support of IEEE + 802.11's WEP. This is needed for WEP as well as 802.1x. This + selects ARC4 under kernel crypto libraries, and CRC32 under + kernel libraries. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_wep". + +config IEEE80211_CRYPT_CCMP + tristate "IEEE 802.11i CCMP support" + depends on IEEE80211 + select CRYPTO_AES + ---help--- + Include software based cipher suites in support of IEEE 802.11i + (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled + networks. This selects AES support under kernel crypto + libraries. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_ccmp". + +config IEEE80211_CRYPT_TKIP + tristate "IEEE 802.11i TKIP encryption" + depends on IEEE80211 + select CRYPTO_MICHAEL_MIC + ---help--- + Include software based cipher suites in support of IEEE 802.11i + (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled + networks. This selects Michael Mic support under kernel crypto + libraries. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_tkip". + diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/Makefile netdev-2.6-ipw/net/ieee80211/Makefile --- netdev-2.6/net/ieee80211/Makefile 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/Makefile 2005-02-10 17:55:08 -06:00 @@ -0,0 +1,11 @@ +obj-$(CONFIG_IEEE80211) += ieee80211.o +obj-$(CONFIG_IEEE80211) += ieee80211_crypt.o +obj-$(CONFIG_IEEE80211_CRYPT_WEP) += ieee80211_crypt_wep.o +obj-$(CONFIG_IEEE80211_CRYPT_CCMP) += ieee80211_crypt_ccmp.o +obj-$(CONFIG_IEEE80211_CRYPT_TKIP) += ieee80211_crypt_tkip.o +ieee80211-objs := \ + ieee80211_module.o \ + ieee80211_tx.o \ + ieee80211_rx.o \ + ieee80211_wx.o + diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_crypt.c netdev-2.6-ipw/net/ieee80211/ieee80211_crypt.c --- netdev-2.6/net/ieee80211/ieee80211_crypt.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_crypt.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,253 @@ +/* + * Host AP crypto routines + * + * Copyright (c) 2002-2003, Jouni Malinen + * Portions Copyright (C) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("HostAP crypto"); +MODULE_LICENSE("GPL"); + +struct ieee80211_crypto_alg { + struct list_head list; + struct ieee80211_crypto_ops *ops; +}; + + +struct ieee80211_crypto { + struct list_head algs; + spinlock_t lock; +}; + +static struct ieee80211_crypto *hcrypt; + +void ieee80211_crypt_deinit_entries(struct ieee80211_device *ieee, + int force) +{ + struct list_head *ptr, *n; + struct ieee80211_crypt_data *entry; + + for (ptr = ieee->crypt_deinit_list.next, n = ptr->next; + ptr != &ieee->crypt_deinit_list; ptr = n, n = ptr->next) { + entry = list_entry(ptr, struct ieee80211_crypt_data, list); + + if (atomic_read(&entry->refcnt) != 0 && !force) + continue; + + list_del(ptr); + + if (entry->ops) { + entry->ops->deinit(entry->priv); + module_put(entry->ops->owner); + } + kfree(entry); + } +} + +void ieee80211_crypt_deinit_handler(unsigned long data) +{ + struct ieee80211_device *ieee = (struct ieee80211_device *)data; + unsigned long flags; + + spin_lock_irqsave(&ieee->lock, flags); + ieee80211_crypt_deinit_entries(ieee, 0); + if (!list_empty(&ieee->crypt_deinit_list)) { + printk(KERN_DEBUG "%s: entries remaining in delayed crypt " + "deletion list\n", ieee->dev->name); + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); + +} + +void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee, + struct ieee80211_crypt_data **crypt) +{ + struct ieee80211_crypt_data *tmp; + unsigned long flags; + + if (*crypt == NULL) + return; + + tmp = *crypt; + *crypt = NULL; + + /* must not run ops->deinit() while there may be pending encrypt or + * decrypt operations. Use a list of delayed deinits to avoid needing + * locking. */ + + spin_lock_irqsave(&ieee->lock, flags); + list_add(&tmp->list, &ieee->crypt_deinit_list); + if (!timer_pending(&ieee->crypt_deinit_timer)) { + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); +} + +int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct ieee80211_crypto_alg *alg; + + if (hcrypt == NULL) + return -1; + + alg = kmalloc(sizeof(*alg), GFP_KERNEL); + if (alg == NULL) + return -ENOMEM; + + memset(alg, 0, sizeof(*alg)); + alg->ops = ops; + + spin_lock_irqsave(&hcrypt->lock, flags); + list_add(&alg->list, &hcrypt->algs); + spin_unlock_irqrestore(&hcrypt->lock, flags); + + printk(KERN_DEBUG "ieee80211_crypt: registered algorithm '%s'\n", + ops->name); + + return 0; +} + +int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *del_alg = NULL; + + if (hcrypt == NULL) + return -1; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (alg->ops == ops) { + list_del(&alg->list); + del_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (del_alg) { + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s'\n", ops->name); + kfree(del_alg); + } + + return del_alg ? 0 : -1; +} + + +struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *found_alg = NULL; + + if (hcrypt == NULL) + return NULL; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (strcmp(alg->ops->name, name) == 0) { + found_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (found_alg) + return found_alg->ops; + else + return NULL; +} + + +static void * ieee80211_crypt_null_init(int keyidx) { return (void *) 1; } +static void ieee80211_crypt_null_deinit(void *priv) {} + +static struct ieee80211_crypto_ops ieee80211_crypt_null = { + .name = "NULL", + .init = ieee80211_crypt_null_init, + .deinit = ieee80211_crypt_null_deinit, + .encrypt_mpdu = NULL, + .decrypt_mpdu = NULL, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = NULL, + .get_key = NULL, + .extra_prefix_len = 0, + .extra_postfix_len = 0, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_init(void) +{ + hcrypt = kmalloc(sizeof(*hcrypt), GFP_KERNEL); + if (hcrypt == NULL) + return -ENOMEM; + + memset(hcrypt, 0, sizeof(*hcrypt)); + INIT_LIST_HEAD(&hcrypt->algs); + spin_lock_init(&hcrypt->lock); + + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); + + return 0; +} + + +static void __exit ieee80211_crypto_deinit(void) +{ + struct list_head *ptr, *n; + + if (hcrypt == NULL) + return; + + for (ptr = hcrypt->algs.next, n = ptr->next; ptr != &hcrypt->algs; + ptr = n, n = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + list_del(ptr); + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s' (deinit)\n", alg->ops->name); + kfree(alg); + } + + kfree(hcrypt); +} + +EXPORT_SYMBOL(ieee80211_crypt_deinit_entries); +EXPORT_SYMBOL(ieee80211_crypt_deinit_handler); +EXPORT_SYMBOL(ieee80211_crypt_delayed_deinit); + +EXPORT_SYMBOL(ieee80211_register_crypto_ops); +EXPORT_SYMBOL(ieee80211_unregister_crypto_ops); +EXPORT_SYMBOL(ieee80211_get_crypto_ops); + +module_init(ieee80211_crypto_init); +module_exit(ieee80211_crypto_deinit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_crypt_ccmp.c netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_ccmp.c --- netdev-2.6/net/ieee80211/ieee80211_crypt_ccmp.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_ccmp.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,473 @@ +/* + * Host AP crypt: host-based CCMP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: CCMP"); +MODULE_LICENSE("GPL"); + +#define AES_BLOCK_LEN 16 +#define CCMP_HDR_LEN 8 +#define CCMP_MIC_LEN 8 +#define CCMP_TK_LEN 16 +#define CCMP_PN_LEN 6 + +struct ieee80211_ccmp_data { + u8 key[CCMP_TK_LEN]; + int key_set; + + u8 tx_pn[CCMP_PN_LEN]; + u8 rx_pn[CCMP_PN_LEN]; + + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; + + int key_idx; + + struct crypto_tfm *tfm; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN], + tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN]; + u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN]; +}; + +void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm, + const u8 pt[16], u8 ct[16]) +{ + struct scatterlist src, dst; + + src.page = virt_to_page(pt); + src.offset = offset_in_page(pt); + src.length = AES_BLOCK_LEN; + + dst.page = virt_to_page(ct); + dst.offset = offset_in_page(ct); + dst.length = AES_BLOCK_LEN; + + crypto_cipher_encrypt(tfm, &dst, &src, AES_BLOCK_LEN); +} + +static void * ieee80211_ccmp_init(int key_idx) +{ + struct ieee80211_ccmp_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm = crypto_alloc_tfm("aes", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_ccmp: could not allocate " + "crypto API aes\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_ccmp_deinit(void *priv) +{ + struct ieee80211_ccmp_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +static inline void xor_block(u8 *b, u8 *a, size_t len) +{ + int i; + for (i = 0; i < len; i++) + b[i] ^= a[i]; +} + + +static void ccmp_init_blocks(struct crypto_tfm *tfm, + struct ieee80211_hdr *hdr, + u8 *pn, size_t dlen, u8 *b0, u8 *auth, + u8 *s0) +{ + u8 *pos, qc = 0; + size_t aad_len; + u16 fc; + int a4_included, qc_included; + u8 aad[2 * AES_BLOCK_LEN]; + + fc = le16_to_cpu(hdr->frame_ctl); + a4_included = ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)); + qc_included = ((WLAN_FC_GET_TYPE(fc) == IEEE80211_FTYPE_DATA) && + (WLAN_FC_GET_STYPE(fc) & 0x08)); + aad_len = 22; + if (a4_included) + aad_len += 6; + if (qc_included) { + pos = (u8 *) &hdr->addr4; + if (a4_included) + pos += 6; + qc = *pos & 0x0f; + aad_len += 2; + } + + /* CCM Initial Block: + * Flag (Include authentication header, M=3 (8-octet MIC), + * L=1 (2-octet Dlen)) + * Nonce: 0x00 | A2 | PN + * Dlen */ + b0[0] = 0x59; + b0[1] = qc; + memcpy(b0 + 2, hdr->addr2, ETH_ALEN); + memcpy(b0 + 8, pn, CCMP_PN_LEN); + b0[14] = (dlen >> 8) & 0xff; + b0[15] = dlen & 0xff; + + /* AAD: + * FC with bits 4..6 and 11..13 masked to zero; 14 is always one + * A1 | A2 | A3 + * SC with bits 4..15 (seq#) masked to zero + * A4 (if present) + * QC (if present) + */ + pos = (u8 *) hdr; + aad[0] = 0; /* aad_len >> 8 */ + aad[1] = aad_len & 0xff; + aad[2] = pos[0] & 0x8f; + aad[3] = pos[1] & 0xc7; + memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN); + pos = (u8 *) &hdr->seq_ctl; + aad[22] = pos[0] & 0x0f; + aad[23] = 0; /* all bits masked */ + memset(aad + 24, 0, 8); + if (a4_included) + memcpy(aad + 24, hdr->addr4, ETH_ALEN); + if (qc_included) { + aad[a4_included ? 30 : 24] = qc; + /* rest of QC masked */ + } + + /* Start with the first block and AAD */ + ieee80211_ccmp_aes_encrypt(tfm, b0, auth); + xor_block(auth, aad, AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + b0[0] &= 0x07; + b0[14] = b0[15] = 0; + ieee80211_ccmp_aes_encrypt(tfm, b0, s0); +} + + +static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + int data_len, i, blocks, last, len; + u8 *pos, *mic; + struct ieee80211_hdr *hdr; + u8 *b0 = key->tx_b0; + u8 *b = key->tx_b; + u8 *e = key->tx_e; + u8 *s0 = key->tx_s0; + + if (skb_headroom(skb) < CCMP_HDR_LEN || + skb_tailroom(skb) < CCMP_MIC_LEN || + skb->len < hdr_len) + return -1; + + data_len = skb->len - hdr_len; + pos = skb_push(skb, CCMP_HDR_LEN); + memmove(pos, pos + CCMP_HDR_LEN, hdr_len); + pos += hdr_len; + mic = skb_put(skb, CCMP_MIC_LEN); + + i = CCMP_PN_LEN - 1; + while (i >= 0) { + key->tx_pn[i]++; + if (key->tx_pn[i] != 0) + break; + i--; + } + + *pos++ = key->tx_pn[5]; + *pos++ = key->tx_pn[4]; + *pos++ = 0; + *pos++ = (key->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = key->tx_pn[3]; + *pos++ = key->tx_pn[2]; + *pos++ = key->tx_pn[1]; + *pos++ = key->tx_pn[0]; + + hdr = (struct ieee80211_hdr *) skb->data; + ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Authentication */ + xor_block(b, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, b, b); + /* Encryption, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, e); + xor_block(pos, e, len); + pos += len; + } + + for (i = 0; i < CCMP_MIC_LEN; i++) + mic[i] = b[i] ^ s0[i]; + + return 0; +} + + +static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + u8 keyidx, *pos; + struct ieee80211_hdr *hdr; + u8 *b0 = key->rx_b0; + u8 *b = key->rx_b; + u8 *a = key->rx_a; + u8 pn[6]; + int i, blocks, last, len; + size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN; + u8 *mic = skb->data + skb->len - CCMP_MIC_LEN; + + if (skb->len < hdr_len + CCMP_HDR_LEN + CCMP_MIC_LEN) { + key->dot11RSNAStatsCCMPFormatErrors++; + return -1; + } + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPFormatErrors++; + return -2; + } + keyidx >>= 6; + if (key->key_idx != keyidx) { + printk(KERN_DEBUG "CCMP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", key->key_idx, keyidx, priv); + return -6; + } + if (!key->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + + pn[0] = pos[7]; + pn[1] = pos[6]; + pn[2] = pos[5]; + pn[3] = pos[4]; + pn[4] = pos[1]; + pn[5] = pos[0]; + pos += 8; + + if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT + " previous PN %02x%02x%02x%02x%02x%02x " + "received PN %02x%02x%02x%02x%02x%02x\n", + MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn), + MAC_ARG(pn)); + } + key->dot11RSNAStatsCCMPReplays++; + return -4; + } + + ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b); + xor_block(mic, b, CCMP_MIC_LEN); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Decrypt, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, b); + xor_block(pos, b, len); + /* Authentication */ + xor_block(a, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, a, a); + pos += len; + } + + if (memcmp(mic, a, CCMP_MIC_LEN) != 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: decrypt failed: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPDecryptErrors++; + return -5; + } + + memcpy(key->rx_pn, pn, CCMP_PN_LEN); + + /* Remove hdr and MIC */ + memmove(skb->data + CCMP_HDR_LEN, skb->data, hdr_len); + skb_pull(skb, CCMP_HDR_LEN); + skb_trim(skb, skb->len - CCMP_MIC_LEN); + + return keyidx; +} + + +static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + int keyidx; + struct crypto_tfm *tfm = data->tfm; + + keyidx = data->key_idx; + memset(data, 0, sizeof(*data)); + data->key_idx = keyidx; + data->tfm = tfm; + if (len == CCMP_TK_LEN) { + memcpy(data->key, key, CCMP_TK_LEN); + data->key_set = 1; + if (seq) { + data->rx_pn[0] = seq[5]; + data->rx_pn[1] = seq[4]; + data->rx_pn[2] = seq[3]; + data->rx_pn[3] = seq[2]; + data->rx_pn[4] = seq[1]; + data->rx_pn[5] = seq[0]; + } + crypto_cipher_setkey(data->tfm, data->key, CCMP_TK_LEN); + } else if (len == 0) + data->key_set = 0; + else + return -1; + + return 0; +} + + +static int ieee80211_ccmp_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + + if (len < CCMP_TK_LEN) + return -1; + + if (!data->key_set) + return 0; + memcpy(key, data->key, CCMP_TK_LEN); + + if (seq) { + seq[0] = data->tx_pn[5]; + seq[1] = data->tx_pn[4]; + seq[2] = data->tx_pn[3]; + seq[3] = data->tx_pn[2]; + seq[4] = data->tx_pn[1]; + seq[5] = data->tx_pn[0]; + } + + return CCMP_TK_LEN; +} + + +static char * ieee80211_ccmp_print_stats(char *p, void *priv) +{ + struct ieee80211_ccmp_data *ccmp = priv; + p += sprintf(p, "key[%d] alg=CCMP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "format_errors=%d replays=%d decrypt_errors=%d\n", + ccmp->key_idx, ccmp->key_set, + MAC_ARG(ccmp->tx_pn), MAC_ARG(ccmp->rx_pn), + ccmp->dot11RSNAStatsCCMPFormatErrors, + ccmp->dot11RSNAStatsCCMPReplays, + ccmp->dot11RSNAStatsCCMPDecryptErrors); + + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_ccmp = { + .name = "CCMP", + .init = ieee80211_ccmp_init, + .deinit = ieee80211_ccmp_deinit, + .encrypt_mpdu = ieee80211_ccmp_encrypt, + .decrypt_mpdu = ieee80211_ccmp_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = ieee80211_ccmp_set_key, + .get_key = ieee80211_ccmp_get_key, + .print_stats = ieee80211_ccmp_print_stats, + .extra_prefix_len = CCMP_HDR_LEN, + .extra_postfix_len = CCMP_MIC_LEN, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_ccmp_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_ccmp) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_ccmp_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_ccmp); +} + + +module_init(ieee80211_crypto_ccmp_init); +module_exit(ieee80211_crypto_ccmp_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_crypt_tkip.c netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_tkip.c --- netdev-2.6/net/ieee80211/ieee80211_crypt_tkip.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_tkip.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,711 @@ +/* + * Host AP crypt: host-based TKIP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: TKIP"); +MODULE_LICENSE("GPL"); + +struct ieee80211_tkip_data { +#define TKIP_KEY_LEN 32 + u8 key[TKIP_KEY_LEN]; + int key_set; + + u32 tx_iv32; + u16 tx_iv16; + u16 tx_ttak[5]; + int tx_phase1_done; + + u32 rx_iv32; + u16 rx_iv16; + u16 rx_ttak[5]; + int rx_phase1_done; + u32 rx_iv32_new; + u16 rx_iv16_new; + + u32 dot11RSNAStatsTKIPReplays; + u32 dot11RSNAStatsTKIPICVErrors; + u32 dot11RSNAStatsTKIPLocalMICFailures; + + int key_idx; + + struct crypto_tfm *tfm_arc4; + struct crypto_tfm *tfm_michael; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 rx_hdr[16], tx_hdr[16]; +}; + +static void * ieee80211_tkip_init(int key_idx) +{ + struct ieee80211_tkip_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm_arc4 = crypto_alloc_tfm("arc4", 0); + if (priv->tfm_arc4 == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + priv->tfm_michael = crypto_alloc_tfm("michael_mic", 0); + if (priv->tfm_michael == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API michael_mic\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm_michael) + crypto_free_tfm(priv->tfm_michael); + if (priv->tfm_arc4) + crypto_free_tfm(priv->tfm_arc4); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_tkip_deinit(void *priv) +{ + struct ieee80211_tkip_data *_priv = priv; + if (_priv && _priv->tfm_michael) + crypto_free_tfm(_priv->tfm_michael); + if (_priv && _priv->tfm_arc4) + crypto_free_tfm(_priv->tfm_arc4); + kfree(priv); +} + + +static inline u16 RotR1(u16 val) +{ + return (val >> 1) | (val << 15); +} + + +static inline u8 Lo8(u16 val) +{ + return val & 0xff; +} + + +static inline u8 Hi8(u16 val) +{ + return val >> 8; +} + + +static inline u16 Lo16(u32 val) +{ + return val & 0xffff; +} + + +static inline u16 Hi16(u32 val) +{ + return val >> 16; +} + + +static inline u16 Mk16(u8 hi, u8 lo) +{ + return lo | (((u16) hi) << 8); +} + + +static inline u16 Mk16_le(u16 *v) +{ + return le16_to_cpu(*v); +} + + +static const u16 Sbox[256] = +{ + 0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154, + 0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A, + 0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B, + 0x41EC, 0xB367, 0x5FFD, 0x45EA, 0x23BF, 0x53F7, 0xE496, 0x9B5B, + 0x75C2, 0xE11C, 0x3DAE, 0x4C6A, 0x6C5A, 0x7E41, 0xF502, 0x834F, + 0x685C, 0x51F4, 0xD134, 0xF908, 0xE293, 0xAB73, 0x6253, 0x2A3F, + 0x080C, 0x9552, 0x4665, 0x9D5E, 0x3028, 0x37A1, 0x0A0F, 0x2FB5, + 0x0E09, 0x2436, 0x1B9B, 0xDF3D, 0xCD26, 0x4E69, 0x7FCD, 0xEA9F, + 0x121B, 0x1D9E, 0x5874, 0x342E, 0x362D, 0xDCB2, 0xB4EE, 0x5BFB, + 0xA4F6, 0x764D, 0xB761, 0x7DCE, 0x527B, 0xDD3E, 0x5E71, 0x1397, + 0xA6F5, 0xB968, 0x0000, 0xC12C, 0x4060, 0xE31F, 0x79C8, 0xB6ED, + 0xD4BE, 0x8D46, 0x67D9, 0x724B, 0x94DE, 0x98D4, 0xB0E8, 0x854A, + 0xBB6B, 0xC52A, 0x4FE5, 0xED16, 0x86C5, 0x9AD7, 0x6655, 0x1194, + 0x8ACF, 0xE910, 0x0406, 0xFE81, 0xA0F0, 0x7844, 0x25BA, 0x4BE3, + 0xA2F3, 0x5DFE, 0x80C0, 0x058A, 0x3FAD, 0x21BC, 0x7048, 0xF104, + 0x63DF, 0x77C1, 0xAF75, 0x4263, 0x2030, 0xE51A, 0xFD0E, 0xBF6D, + 0x814C, 0x1814, 0x2635, 0xC32F, 0xBEE1, 0x35A2, 0x88CC, 0x2E39, + 0x9357, 0x55F2, 0xFC82, 0x7A47, 0xC8AC, 0xBAE7, 0x322B, 0xE695, + 0xC0A0, 0x1998, 0x9ED1, 0xA37F, 0x4466, 0x547E, 0x3BAB, 0x0B83, + 0x8CCA, 0xC729, 0x6BD3, 0x283C, 0xA779, 0xBCE2, 0x161D, 0xAD76, + 0xDB3B, 0x6456, 0x744E, 0x141E, 0x92DB, 0x0C0A, 0x486C, 0xB8E4, + 0x9F5D, 0xBD6E, 0x43EF, 0xC4A6, 0x39A8, 0x31A4, 0xD337, 0xF28B, + 0xD532, 0x8B43, 0x6E59, 0xDAB7, 0x018C, 0xB164, 0x9CD2, 0x49E0, + 0xD8B4, 0xACFA, 0xF307, 0xCF25, 0xCAAF, 0xF48E, 0x47E9, 0x1018, + 0x6FD5, 0xF088, 0x4A6F, 0x5C72, 0x3824, 0x57F1, 0x73C7, 0x9751, + 0xCB23, 0xA17C, 0xE89C, 0x3E21, 0x96DD, 0x61DC, 0x0D86, 0x0F85, + 0xE090, 0x7C42, 0x71C4, 0xCCAA, 0x90D8, 0x0605, 0xF701, 0x1C12, + 0xC2A3, 0x6A5F, 0xAEF9, 0x69D0, 0x1791, 0x9958, 0x3A27, 0x27B9, + 0xD938, 0xEB13, 0x2BB3, 0x2233, 0xD2BB, 0xA970, 0x0789, 0x33A7, + 0x2DB6, 0x3C22, 0x1592, 0xC920, 0x8749, 0xAAFF, 0x5078, 0xA57A, + 0x038F, 0x59F8, 0x0980, 0x1A17, 0x65DA, 0xD731, 0x84C6, 0xD0B8, + 0x82C3, 0x29B0, 0x5A77, 0x1E11, 0x7BCB, 0xA8FC, 0x6DD6, 0x2C3A, +}; + + +static inline u16 _S_(u16 v) +{ + u16 t = Sbox[Hi8(v)]; + return Sbox[Lo8(v)] ^ ((t << 8) | (t >> 8)); +} + + +#define PHASE1_LOOP_COUNT 8 + +static void tkip_mixing_phase1(u16 *TTAK, const u8 *TK, const u8 *TA, u32 IV32) +{ + int i, j; + + /* Initialize the 80-bit TTAK from TSC (IV32) and TA[0..5] */ + TTAK[0] = Lo16(IV32); + TTAK[1] = Hi16(IV32); + TTAK[2] = Mk16(TA[1], TA[0]); + TTAK[3] = Mk16(TA[3], TA[2]); + TTAK[4] = Mk16(TA[5], TA[4]); + + for (i = 0; i < PHASE1_LOOP_COUNT; i++) { + j = 2 * (i & 1); + TTAK[0] += _S_(TTAK[4] ^ Mk16(TK[1 + j], TK[0 + j])); + TTAK[1] += _S_(TTAK[0] ^ Mk16(TK[5 + j], TK[4 + j])); + TTAK[2] += _S_(TTAK[1] ^ Mk16(TK[9 + j], TK[8 + j])); + TTAK[3] += _S_(TTAK[2] ^ Mk16(TK[13 + j], TK[12 + j])); + TTAK[4] += _S_(TTAK[3] ^ Mk16(TK[1 + j], TK[0 + j])) + i; + } +} + + +static void tkip_mixing_phase2(u8 *WEPSeed, const u8 *TK, const u16 *TTAK, + u16 IV16) +{ + /* Make temporary area overlap WEP seed so that the final copy can be + * avoided on little endian hosts. */ + u16 *PPK = (u16 *) &WEPSeed[4]; + + /* Step 1 - make copy of TTAK and bring in TSC */ + PPK[0] = TTAK[0]; + PPK[1] = TTAK[1]; + PPK[2] = TTAK[2]; + PPK[3] = TTAK[3]; + PPK[4] = TTAK[4]; + PPK[5] = TTAK[4] + IV16; + + /* Step 2 - 96-bit bijective mixing using S-box */ + PPK[0] += _S_(PPK[5] ^ Mk16_le((u16 *) &TK[0])); + PPK[1] += _S_(PPK[0] ^ Mk16_le((u16 *) &TK[2])); + PPK[2] += _S_(PPK[1] ^ Mk16_le((u16 *) &TK[4])); + PPK[3] += _S_(PPK[2] ^ Mk16_le((u16 *) &TK[6])); + PPK[4] += _S_(PPK[3] ^ Mk16_le((u16 *) &TK[8])); + PPK[5] += _S_(PPK[4] ^ Mk16_le((u16 *) &TK[10])); + + PPK[0] += RotR1(PPK[5] ^ Mk16_le((u16 *) &TK[12])); + PPK[1] += RotR1(PPK[0] ^ Mk16_le((u16 *) &TK[14])); + PPK[2] += RotR1(PPK[1]); + PPK[3] += RotR1(PPK[2]); + PPK[4] += RotR1(PPK[3]); + PPK[5] += RotR1(PPK[4]); + + /* Step 3 - bring in last of TK bits, assign 24-bit WEP IV value + * WEPSeed[0..2] is transmitted as WEP IV */ + WEPSeed[0] = Hi8(IV16); + WEPSeed[1] = (Hi8(IV16) | 0x20) & 0x7F; + WEPSeed[2] = Lo8(IV16); + WEPSeed[3] = Lo8((PPK[5] ^ Mk16_le((u16 *) &TK[0])) >> 1); + +#ifdef __BIG_ENDIAN + { + int i; + for (i = 0; i < 6; i++) + PPK[i] = (PPK[i] << 8) | (PPK[i] >> 8); + } +#endif +} + +static int ieee80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int len; + u8 rc4key[16], *pos, *icv; + struct ieee80211_hdr *hdr; + u32 crc; + struct scatterlist sg; + + if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + if (!tkey->tx_phase1_done) { + tkip_mixing_phase1(tkey->tx_ttak, tkey->key, hdr->addr2, + tkey->tx_iv32); + tkey->tx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, tkey->tx_iv16); + + len = skb->len - hdr_len; + pos = skb_push(skb, 8); + memmove(pos, pos + 8, hdr_len); + pos += hdr_len; + icv = skb_put(skb, 4); + + *pos++ = rc4key[0]; + *pos++ = rc4key[1]; + *pos++ = rc4key[2]; + *pos++ = (tkey->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = tkey->tx_iv32 & 0xff; + *pos++ = (tkey->tx_iv32 >> 8) & 0xff; + *pos++ = (tkey->tx_iv32 >> 16) & 0xff; + *pos++ = (tkey->tx_iv32 >> 24) & 0xff; + + crc = ~crc32_le(~0, pos, len); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(tkey->tfm_arc4, &sg, &sg, len + 4); + + tkey->tx_iv16++; + if (tkey->tx_iv16 == 0) { + tkey->tx_phase1_done = 0; + tkey->tx_iv32++; + } + + return 0; +} + +static int ieee80211_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 rc4key[16]; + u8 keyidx, *pos; + u32 iv32; + u16 iv16; + struct ieee80211_hdr *hdr; + u8 icv[4]; + u32 crc; + struct scatterlist sg; + int plen; + + if (skb->len < hdr_len + 8 + 4) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + return -2; + } + keyidx >>= 6; + if (tkey->key_idx != keyidx) { + printk(KERN_DEBUG "TKIP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", tkey->key_idx, keyidx, priv); + return -6; + } + if (!tkey->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + iv16 = (pos[0] << 8) | pos[2]; + iv32 = pos[4] | (pos[5] << 8) | (pos[6] << 16) | (pos[7] << 24); + pos += 8; + + if (iv32 < tkey->rx_iv32 || + (iv32 == tkey->rx_iv32 && iv16 <= tkey->rx_iv16)) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: replay detected: STA=" MAC_FMT + " previous TSC %08x%04x received TSC " + "%08x%04x\n", MAC_ARG(hdr->addr2), + tkey->rx_iv32, tkey->rx_iv16, iv32, iv16); + } + tkey->dot11RSNAStatsTKIPReplays++; + return -4; + } + + if (iv32 != tkey->rx_iv32 || !tkey->rx_phase1_done) { + tkip_mixing_phase1(tkey->rx_ttak, tkey->key, hdr->addr2, iv32); + tkey->rx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->rx_ttak, iv16); + + plen = skb->len - hdr_len - 12; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(tkey->tfm_arc4, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + if (iv32 != tkey->rx_iv32) { + /* Previously cached Phase1 result was already lost, so + * it needs to be recalculated for the next packet. */ + tkey->rx_phase1_done = 0; + } + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: ICV error detected: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + tkey->dot11RSNAStatsTKIPICVErrors++; + return -5; + } + + /* Update real counters only after Michael MIC verification has + * completed */ + tkey->rx_iv32_new = iv32; + tkey->rx_iv16_new = iv16; + + /* Remove IV and ICV */ + memmove(skb->data + 8, skb->data, hdr_len); + skb_pull(skb, 8); + skb_trim(skb, skb->len - 4); + + return keyidx; +} + + +static int michael_mic(struct ieee80211_tkip_data *tkey, u8 *key, u8 *hdr, + u8 *data, size_t data_len, u8 *mic) +{ + struct scatterlist sg[2]; + + if (tkey->tfm_michael == NULL) { + printk(KERN_WARNING "michael_mic: tfm_michael == NULL\n"); + return -1; + } + sg[0].page = virt_to_page(hdr); + sg[0].offset = offset_in_page(hdr); + sg[0].length = 16; + + sg[1].page = virt_to_page(data); + sg[1].offset = offset_in_page(data); + sg[1].length = data_len; + + crypto_digest_init(tkey->tfm_michael); + crypto_digest_setkey(tkey->tfm_michael, key, 8); + crypto_digest_update(tkey->tfm_michael, sg, 2); + crypto_digest_final(tkey->tfm_michael, mic); + + return 0; +} + +static void michael_mic_hdr(struct sk_buff *skb, u8 *hdr) +{ + struct ieee80211_hdr *hdr11; + + hdr11 = (struct ieee80211_hdr *) skb->data; + switch (le16_to_cpu(hdr11->frame_ctl) & + (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr3, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */ + break; + case 0: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + } + + hdr[12] = 0; /* priority */ + hdr[13] = hdr[14] = hdr[15] = 0; /* reserved */ +} + + +static int ieee80211_michael_mic_add(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 *pos; + + if (skb_tailroom(skb) < 8 || skb->len < hdr_len) { + printk(KERN_DEBUG "Invalid packet for Michael MIC add " + "(tailroom=%d hdr_len=%d skb->len=%d)\n", + skb_tailroom(skb), hdr_len, skb->len); + return -1; + } + + michael_mic_hdr(skb, tkey->tx_hdr); + pos = skb_put(skb, 8); + if (michael_mic(tkey, &tkey->key[16], tkey->tx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, pos)) + return -1; + + return 0; +} + + +#if WIRELESS_EXT >= 18 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + struct iw_michaelmicfailure ev; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + memset(&ev, 0, sizeof(ev)); + ev.flags = keyidx & IW_MICFAILURE_KEY_ID; + if (hdr->addr1[0] & 0x01) + ev.flags |= IW_MICFAILURE_GROUP; + else + ev.flags |= IW_MICFAILURE_PAIRWISE; + ev.src_addr.sa_family = ARPHRD_ETHER; + memcpy(ev.src_addr.sa_data, hdr->addr2, ETH_ALEN); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = sizeof(ev); + wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *) &ev); +} +#elif WIRELESS_EXT >= 15 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + char buf[128]; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + sprintf(buf, "MLME-MICHAELMICFAILURE.indication(keyid=%d %scast addr=" + MAC_FMT ")", keyidx, hdr->addr1[0] & 0x01 ? "broad" : "uni", + MAC_ARG(hdr->addr2)); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = strlen(buf); + wireless_send_event(dev, IWEVCUSTOM, &wrqu, buf); +} +#else /* WIRELESS_EXT >= 15 */ +static inline void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ +} +#endif /* WIRELESS_EXT >= 15 */ + + +static int ieee80211_michael_mic_verify(struct sk_buff *skb, int keyidx, + int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 mic[8]; + + if (!tkey->key_set) + return -1; + + michael_mic_hdr(skb, tkey->rx_hdr); + if (michael_mic(tkey, &tkey->key[24], tkey->rx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, mic)) + return -1; + if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) { + struct ieee80211_hdr *hdr; + hdr = (struct ieee80211_hdr *) skb->data; + printk(KERN_DEBUG "%s: Michael MIC verification failed for " + "MSDU from " MAC_FMT " keyidx=%d\n", + skb->dev ? skb->dev->name : "N/A", MAC_ARG(hdr->addr2), + keyidx); + if (skb->dev) + ieee80211_michael_mic_failure(skb->dev, hdr, keyidx); + tkey->dot11RSNAStatsTKIPLocalMICFailures++; + return -1; + } + + /* Update TSC counters for RX now that the packet verification has + * completed. */ + tkey->rx_iv32 = tkey->rx_iv32_new; + tkey->rx_iv16 = tkey->rx_iv16_new; + + skb_trim(skb, skb->len - 8); + + return 0; +} + + +static int ieee80211_tkip_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int keyidx; + struct crypto_tfm *tfm = tkey->tfm_michael; + struct crypto_tfm *tfm2 = tkey->tfm_arc4; + + keyidx = tkey->key_idx; + memset(tkey, 0, sizeof(*tkey)); + tkey->key_idx = keyidx; + tkey->tfm_michael = tfm; + tkey->tfm_arc4 = tfm2; + if (len == TKIP_KEY_LEN) { + memcpy(tkey->key, key, TKIP_KEY_LEN); + tkey->key_set = 1; + tkey->tx_iv16 = 1; /* TSC is initialized to 1 */ + if (seq) { + tkey->rx_iv32 = (seq[5] << 24) | (seq[4] << 16) | + (seq[3] << 8) | seq[2]; + tkey->rx_iv16 = (seq[1] << 8) | seq[0]; + } + } else if (len == 0) + tkey->key_set = 0; + else + return -1; + + return 0; +} + + +static int ieee80211_tkip_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + + if (len < TKIP_KEY_LEN) + return -1; + + if (!tkey->key_set) + return 0; + memcpy(key, tkey->key, TKIP_KEY_LEN); + + if (seq) { + /* Return the sequence number of the last transmitted frame. */ + u16 iv16 = tkey->tx_iv16; + u32 iv32 = tkey->tx_iv32; + if (iv16 == 0) + iv32--; + iv16--; + seq[0] = tkey->tx_iv16; + seq[1] = tkey->tx_iv16 >> 8; + seq[2] = tkey->tx_iv32; + seq[3] = tkey->tx_iv32 >> 8; + seq[4] = tkey->tx_iv32 >> 16; + seq[5] = tkey->tx_iv32 >> 24; + } + + return TKIP_KEY_LEN; +} + + +static char * ieee80211_tkip_print_stats(char *p, void *priv) +{ + struct ieee80211_tkip_data *tkip = priv; + p += sprintf(p, "key[%d] alg=TKIP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "replays=%d icv_errors=%d local_mic_failures=%d\n", + tkip->key_idx, tkip->key_set, + (tkip->tx_iv32 >> 24) & 0xff, + (tkip->tx_iv32 >> 16) & 0xff, + (tkip->tx_iv32 >> 8) & 0xff, + tkip->tx_iv32 & 0xff, + (tkip->tx_iv16 >> 8) & 0xff, + tkip->tx_iv16 & 0xff, + (tkip->rx_iv32 >> 24) & 0xff, + (tkip->rx_iv32 >> 16) & 0xff, + (tkip->rx_iv32 >> 8) & 0xff, + tkip->rx_iv32 & 0xff, + (tkip->rx_iv16 >> 8) & 0xff, + tkip->rx_iv16 & 0xff, + tkip->dot11RSNAStatsTKIPReplays, + tkip->dot11RSNAStatsTKIPICVErrors, + tkip->dot11RSNAStatsTKIPLocalMICFailures); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_tkip = { + .name = "TKIP", + .init = ieee80211_tkip_init, + .deinit = ieee80211_tkip_deinit, + .encrypt_mpdu = ieee80211_tkip_encrypt, + .decrypt_mpdu = ieee80211_tkip_decrypt, + .encrypt_msdu = ieee80211_michael_mic_add, + .decrypt_msdu = ieee80211_michael_mic_verify, + .set_key = ieee80211_tkip_set_key, + .get_key = ieee80211_tkip_get_key, + .print_stats = ieee80211_tkip_print_stats, + .extra_prefix_len = 4 + 4, /* IV + ExtIV */ + .extra_postfix_len = 8 + 4, /* MIC + ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_tkip_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_tkip) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_tkip_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_tkip); +} + + +module_init(ieee80211_crypto_tkip_init); +module_exit(ieee80211_crypto_tkip_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_crypt_wep.c netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_wep.c --- netdev-2.6/net/ieee80211/ieee80211_crypt_wep.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_crypt_wep.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,275 @@ +/* + * Host AP crypt: host-based WEP encryption implementation for Host AP driver + * + * Copyright (c) 2002-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: WEP"); +MODULE_LICENSE("GPL"); + + +struct prism2_wep_data { + u32 iv; +#define WEP_KEY_LEN 13 + u8 key[WEP_KEY_LEN + 1]; + u8 key_len; + u8 key_idx; + struct crypto_tfm *tfm; +}; + + +static void * prism2_wep_init(int keyidx) +{ + struct prism2_wep_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = keyidx; + + priv->tfm = crypto_alloc_tfm("arc4", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + /* start WEP IV from a random value */ + get_random_bytes(&priv->iv, 4); + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + return NULL; +} + + +static void prism2_wep_deinit(void *priv) +{ + struct prism2_wep_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +/* Perform WEP encryption on given skb that has at least 4 bytes of headroom + * for IV and 4 bytes of tailroom for ICV. Both IV and ICV will be transmitted, + * so the payload length increases with 8 bytes. + * + * WEP frame payload: IV + TX key idx, RC4(data), ICV = RC4(CRC32(data)) + */ +static int prism2_wep_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, len; + u8 key[WEP_KEY_LEN + 3]; + u8 *pos, *icv; + struct scatterlist sg; + + if (skb_headroom(skb) < 4 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + len = skb->len - hdr_len; + pos = skb_push(skb, 4); + memmove(pos, pos + 4, hdr_len); + pos += hdr_len; + + klen = 3 + wep->key_len; + + wep->iv++; + + /* Fluhrer, Mantin, and Shamir have reported weaknesses in the key + * scheduling algorithm of RC4. At least IVs (KeyByte + 3, 0xff, N) + * can be used to speedup attacks, so avoid using them. */ + if ((wep->iv & 0xff00) == 0xff00) { + u8 B = (wep->iv >> 16) & 0xff; + if (B >= 3 && B < klen) + wep->iv += 0x0100; + } + + /* Prepend 24-bit IV to RC4 key and TX frame */ + *pos++ = key[0] = (wep->iv >> 16) & 0xff; + *pos++ = key[1] = (wep->iv >> 8) & 0xff; + *pos++ = key[2] = wep->iv & 0xff; + *pos++ = wep->key_idx << 6; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Append little-endian CRC32 and encrypt it to produce ICV */ + crc = ~crc32_le(~0, pos, len); + icv = skb_put(skb, 4); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(wep->tfm, &sg, &sg, len + 4); + + return 0; +} + + +/* Perform WEP decryption on given buffer. Buffer includes whole WEP part of + * the frame: IV (4 bytes), encrypted payload (including SNAP header), + * ICV (4 bytes). len includes both IV and ICV. + * + * Returns 0 if frame was decrypted successfully and ICV was correct and -1 on + * failure. If frame is OK, IV and ICV will be removed. + */ +static int prism2_wep_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, plen; + u8 key[WEP_KEY_LEN + 3]; + u8 keyidx, *pos, icv[4]; + struct scatterlist sg; + + if (skb->len < hdr_len + 8) + return -1; + + pos = skb->data + hdr_len; + key[0] = *pos++; + key[1] = *pos++; + key[2] = *pos++; + keyidx = *pos++ >> 6; + if (keyidx != wep->key_idx) + return -1; + + klen = 3 + wep->key_len; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Apply RC4 to data and compute CRC32 over decrypted data */ + plen = skb->len - hdr_len - 8; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(wep->tfm, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + /* ICV mismatch - drop frame */ + return -2; + } + + /* Remove IV and ICV */ + memmove(skb->data + 4, skb->data, hdr_len); + skb_pull(skb, 4); + skb_trim(skb, skb->len - 4); + + return 0; +} + + +static int prism2_wep_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < 0 || len > WEP_KEY_LEN) + return -1; + + memcpy(wep->key, key, len); + wep->key_len = len; + + return 0; +} + + +static int prism2_wep_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < wep->key_len) + return -1; + + memcpy(key, wep->key, wep->key_len); + + return wep->key_len; +} + + +static char * prism2_wep_print_stats(char *p, void *priv) +{ + struct prism2_wep_data *wep = priv; + p += sprintf(p, "key[%d] alg=WEP len=%d\n", + wep->key_idx, wep->key_len); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_wep = { + .name = "WEP", + .init = prism2_wep_init, + .deinit = prism2_wep_deinit, + .encrypt_mpdu = prism2_wep_encrypt, + .decrypt_mpdu = prism2_wep_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = prism2_wep_set_key, + .get_key = prism2_wep_get_key, + .print_stats = prism2_wep_print_stats, + .extra_prefix_len = 4, /* IV */ + .extra_postfix_len = 4, /* ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_wep_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_wep) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_wep_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_wep); +} + + +module_init(ieee80211_crypto_wep_init); +module_exit(ieee80211_crypto_wep_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_module.c netdev-2.6-ipw/net/ieee80211/ieee80211_module.c --- netdev-2.6/net/ieee80211/ieee80211_module.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_module.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,268 @@ +/******************************************************************************* + + Copyright(c) 2004 Intel Corporation. All rights reserved. + + Portions of this file are based on the WEP enablement code provided by the + Host AP project hostap-drivers v0.1.3 + Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + + Copyright (c) 2002-2003, Jouni Malinen + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + The full GNU General Public License is included in this distribution in the + file called LICENSE. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +*******************************************************************************/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +MODULE_DESCRIPTION("802.11 data/management/control stack"); +MODULE_AUTHOR("Copyright (C) 2004 Intel Corporation "); +MODULE_LICENSE("GPL"); + +#define DRV_NAME "ieee80211" + +static inline int ieee80211_networks_allocate(struct ieee80211_device *ieee) +{ + if (ieee->networks) + return 0; + + ieee->networks = kmalloc( + MAX_NETWORK_COUNT * sizeof(struct ieee80211_network), + GFP_KERNEL); + if (!ieee->networks) { + printk(KERN_WARNING "%s: Out of memory allocating beacons\n", + ieee->dev->name); + return -ENOMEM; + } + + memset(ieee->networks, 0, + MAX_NETWORK_COUNT * sizeof(struct ieee80211_network)); + + return 0; +} + +static inline void ieee80211_networks_free(struct ieee80211_device *ieee) +{ + if (!ieee->networks) + return; + kfree(ieee->networks); + ieee->networks = NULL; +} + +static inline void ieee80211_networks_initialize(struct ieee80211_device *ieee) +{ + int i; + + INIT_LIST_HEAD(&ieee->network_free_list); + INIT_LIST_HEAD(&ieee->network_list); + for (i = 0; i < MAX_NETWORK_COUNT; i++) + list_add_tail(&ieee->networks[i].list, &ieee->network_free_list); +} + + +struct net_device *alloc_ieee80211(int sizeof_priv) +{ + struct ieee80211_device *ieee; + struct net_device *dev; + int err; + + IEEE80211_DEBUG_INFO("Initializing...\n"); + + dev = alloc_etherdev(sizeof(struct ieee80211_device) + sizeof_priv); + if (!dev) { + IEEE80211_ERROR("Unable to network device.\n"); + goto failed; + } + ieee = netdev_priv(dev); + dev->hard_start_xmit = ieee80211_xmit; + + ieee->dev = dev; + + err = ieee80211_networks_allocate(ieee); + if (err) { + IEEE80211_ERROR("Unable to allocate beacon storage: %d\n", + err); + goto failed; + } + ieee80211_networks_initialize(ieee); + + /* Default fragmentation threshold is maximum payload size */ + ieee->fts = DEFAULT_FTS; + ieee->scan_age = DEFAULT_MAX_SCAN_AGE; + ieee->open_wep = 1; + + /* Default to enabling full open WEP with host based encrypt/decrypt */ + ieee->host_encrypt = 1; + ieee->host_decrypt = 1; + ieee->ieee802_1x = 1; /* Default to supporting 802.1x */ + + INIT_LIST_HEAD(&ieee->crypt_deinit_list); + init_timer(&ieee->crypt_deinit_timer); + ieee->crypt_deinit_timer.data = (unsigned long)ieee; + ieee->crypt_deinit_timer.function = ieee80211_crypt_deinit_handler; + + spin_lock_init(&ieee->lock); + + ieee->wpa_enabled = 0; + ieee->tkip_countermeasures = 0; + ieee->drop_unencrypted = 0; + ieee->privacy_invoked = 0; + ieee->ieee802_1x = 1; + + return dev; + + failed: + if (dev) + free_netdev(dev); + return NULL; +} + + +void free_ieee80211(struct net_device *dev) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + + int i; + + del_timer_sync(&ieee->crypt_deinit_timer); + ieee80211_crypt_deinit_entries(ieee, 1); + + for (i = 0; i < WEP_KEYS; i++) { + struct ieee80211_crypt_data *crypt = ieee->crypt[i]; + if (crypt) { + if (crypt->ops) { + crypt->ops->deinit(crypt->priv); + module_put(crypt->ops->owner); + } + kfree(crypt); + ieee->crypt[i] = NULL; + } + } + + ieee80211_networks_free(ieee); + free_netdev(dev); +} + +#ifdef CONFIG_IEEE80211_DEBUG + +static int debug = 0; +u32 ieee80211_debug_level = 0; +struct proc_dir_entry *ieee80211_proc = NULL; + +static int show_debug_level(char *page, char **start, off_t offset, + int count, int *eof, void *data) +{ + return snprintf(page, count, "0x%08X\n", ieee80211_debug_level); +} + +static int store_debug_level(struct file *file, const char *buffer, + unsigned long count, void *data) +{ + char buf[] = "0x00000000"; + unsigned long len = min(sizeof(buf) - 1, (u32)count); + char *p = (char *)buf; + unsigned long val; + + if (copy_from_user(buf, buffer, len)) + return count; + buf[len] = 0; + if (p[1] == 'x' || p[1] == 'X' || p[0] == 'x' || p[0] == 'X') { + p++; + if (p[0] == 'x' || p[0] == 'X') + p++; + val = simple_strtoul(p, &p, 16); + } else + val = simple_strtoul(p, &p, 10); + if (p == buf) + printk(KERN_INFO DRV_NAME + ": %s is not in hex or decimal form.\n", buf); + else + ieee80211_debug_level = val; + + return strnlen(buf, count); +} + +static int __init ieee80211_init(void) +{ + struct proc_dir_entry *e; + + ieee80211_debug_level = debug; + ieee80211_proc = create_proc_entry(DRV_NAME, S_IFDIR, proc_net); + if (ieee80211_proc == NULL) { + IEEE80211_ERROR("Unable to create " DRV_NAME + " proc directory\n"); + return -EIO; + } + e = create_proc_entry("debug_level", S_IFREG | S_IRUGO | S_IWUSR, + ieee80211_proc); + if (!e) { + remove_proc_entry(DRV_NAME, proc_net); + ieee80211_proc = NULL; + return -EIO; + } + e->read_proc = show_debug_level; + e->write_proc = store_debug_level; + e->data = NULL; + + return 0; +} + +static void __exit ieee80211_exit(void) +{ + if (ieee80211_proc) { + remove_proc_entry("debug_level", ieee80211_proc); + remove_proc_entry(DRV_NAME, proc_net); + ieee80211_proc = NULL; + } +} + +#include +module_param(debug, int, 0444); +MODULE_PARM_DESC(debug, "debug output mask"); + + +module_exit(ieee80211_exit); +module_init(ieee80211_init); +#endif + +EXPORT_SYMBOL(alloc_ieee80211); +EXPORT_SYMBOL(free_ieee80211); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_rx.c netdev-2.6-ipw/net/ieee80211/ieee80211_rx.c --- netdev-2.6/net/ieee80211/ieee80211_rx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_rx.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,1206 @@ +/* + * Original code based Host AP (software wireless LAN access point) driver + * for Intersil Prism2/2.5/3 - hostap.o module, common routines + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static inline void ieee80211_monitor_rx(struct ieee80211_device *ieee, + struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + u16 fc = le16_to_cpu(hdr->frame_ctl); + + skb->dev = ieee->dev; + skb->mac.raw = skb->data; + skb_pull(skb, ieee80211_get_hdrlen(fc)); + skb->pkt_type = PACKET_OTHERHOST; + skb->protocol = __constant_htons(ETH_P_80211_RAW); + memset(skb->cb, 0, sizeof(skb->cb)); + netif_rx(skb); +} + + +/* Called only as a tasklet (software IRQ) */ +static struct ieee80211_frag_entry * +ieee80211_frag_cache_find(struct ieee80211_device *ieee, unsigned int seq, + unsigned int frag, u8 *src, u8 *dst) +{ + struct ieee80211_frag_entry *entry; + int i; + + for (i = 0; i < IEEE80211_FRAG_CACHE_LEN; i++) { + entry = &ieee->frag_cache[i]; + if (entry->skb != NULL && + time_after(jiffies, entry->first_frag_time + 2 * HZ)) { + IEEE80211_DEBUG_FRAG( + "expiring fragment cache entry " + "seq=%u last_frag=%u\n", + entry->seq, entry->last_frag); + dev_kfree_skb_any(entry->skb); + entry->skb = NULL; + } + + if (entry->skb != NULL && entry->seq == seq && + (entry->last_frag + 1 == frag || frag == -1) && + memcmp(entry->src_addr, src, ETH_ALEN) == 0 && + memcmp(entry->dst_addr, dst, ETH_ALEN) == 0) + return entry; + } + + return NULL; +} + +/* Called only as a tasklet (software IRQ) */ +static struct sk_buff * +ieee80211_frag_cache_get(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + struct sk_buff *skb = NULL; + u16 sc; + unsigned int frag, seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + seq = WLAN_GET_SEQ_SEQ(sc); + + if (frag == 0) { + /* Reserve enough space to fit maximum frame length */ + skb = dev_alloc_skb(ieee->dev->mtu + + sizeof(struct ieee80211_hdr) + + 8 /* LLC */ + + 2 /* alignment */ + + 8 /* WEP */ + ETH_ALEN /* WDS */); + if (skb == NULL) + return NULL; + + entry = &ieee->frag_cache[ieee->frag_next_idx]; + ieee->frag_next_idx++; + if (ieee->frag_next_idx >= IEEE80211_FRAG_CACHE_LEN) + ieee->frag_next_idx = 0; + + if (entry->skb != NULL) + dev_kfree_skb_any(entry->skb); + + entry->first_frag_time = jiffies; + entry->seq = seq; + entry->last_frag = frag; + entry->skb = skb; + memcpy(entry->src_addr, hdr->addr2, ETH_ALEN); + memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN); + } else { + /* received a fragment of a frame for which the head fragment + * should have already been received */ + entry = ieee80211_frag_cache_find(ieee, seq, frag, hdr->addr2, + hdr->addr1); + if (entry != NULL) { + entry->last_frag = frag; + skb = entry->skb; + } + } + + return skb; +} + + +/* Called only as a tasklet (software IRQ) */ +static int ieee80211_frag_cache_invalidate(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + u16 sc; + unsigned int seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + seq = WLAN_GET_SEQ_SEQ(sc); + + entry = ieee80211_frag_cache_find(ieee, seq, -1, hdr->addr2, + hdr->addr1); + + if (entry == NULL) { + IEEE80211_DEBUG_FRAG( + "could not invalidate fragment cache " + "entry (seq=%u)\n", seq); + return -1; + } + + entry->skb = NULL; + return 0; +} + + +#ifdef NOT_YET +/* ieee80211_rx_frame_mgtmt + * + * Responsible for handling management control frames + * + * Called by ieee80211_rx */ +static inline int +ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats, u16 type, + u16 stype) +{ + if (ieee->iw_mode == IW_MODE_MASTER) { + printk(KERN_DEBUG "%s: Master mode not yet suppported.\n", + ieee->dev->name); + return 0; +/* + hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr *) + skb->data);*/ + } + + if (ieee->hostapd && type == WLAN_FC_TYPE_MGMT) { + if (stype == WLAN_FC_STYPE_BEACON && + ieee->iw_mode == IW_MODE_MASTER) { + struct sk_buff *skb2; + /* Process beacon frames also in kernel driver to + * update STA(AP) table statistics */ + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2) + hostap_rx(skb2->dev, skb2, rx_stats); + } + + /* send management frames to the user space daemon for + * processing */ + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT); + return 0; + } + + if (ieee->iw_mode == IW_MODE_MASTER) { + if (type != WLAN_FC_TYPE_MGMT && type != WLAN_FC_TYPE_CTRL) { + printk(KERN_DEBUG "%s: unknown management frame " + "(type=0x%02x, stype=0x%02x) dropped\n", + skb->dev->name, type, stype); + return -1; + } + + hostap_rx(skb->dev, skb, rx_stats); + return 0; + } + + printk(KERN_DEBUG "%s: hostap_rx_frame_mgmt: management frame " + "received in non-Host AP mode\n", skb->dev->name); + return -1; +} +#endif + + +/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */ +/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ +static unsigned char rfc1042_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 }; +/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */ +static unsigned char bridge_tunnel_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 }; +/* No encapsulation header if EtherType < 0x600 (=length) */ + +/* Called by ieee80211_rx_frame_decrypt */ +static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, + struct sk_buff *skb) +{ + struct net_device *dev = ieee->dev; + u16 fc, ethertype; + struct ieee80211_hdr *hdr; + u8 *pos; + + if (skb->len < 24) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + fc = le16_to_cpu(hdr->frame_ctl); + + /* check that the frame is unicast frame to us */ + if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 && + memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) { + /* ToDS frame with own addr BSSID and DA */ + } else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_FROMDS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) { + /* FromDS frame with own addr as DA */ + } else + return 0; + + if (skb->len < 24 + 8) + return 0; + + /* check for port access entity Ethernet type */ + pos = skb->data + 24; + ethertype = (pos[6] << 8) | pos[7]; + if (ethertype == ETH_P_PAE) + return 1; + + return 0; +} + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt(struct ieee80211_device* ieee, struct sk_buff *skb, + struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_mpdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + +#ifdef CONFIG_IEEE80211_CRYPT_TKIP + if (ieee->tkip_countermeasures && + strcmp(crypt->ops->name, "TKIP") == 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "received packet from " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(hdr->addr2)); + } + return -1; + } +#endif + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_mpdu(skb, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + IEEE80211_DEBUG_DROP( + "decryption failed (SA=" MAC_FMT + ") res=%d\n", MAC_ARG(hdr->addr2), res); + if (res == -2) + IEEE80211_DEBUG_DROP("Decryption failed ICV " + "mismatch (key %d)\n", + skb->data[hdrlen + 3] >> 6); + ieee->ieee_stats.rx_discards_undecryptable++; + return -1; + } + + return res; +} + + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt_msdu(struct ieee80211_device* ieee, struct sk_buff *skb, + int keyidx, struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_msdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed" + " (SA=" MAC_FMT " keyidx=%d)\n", + ieee->dev->name, MAC_ARG(hdr->addr2), keyidx); + return -1; + } + + return 0; +} + + +/* All received frames are sent to this function. @skb contains the frame in + * IEEE 802.11 format, i.e., in the format it was sent over air. + * This function is called only as a tasklet (software IRQ). */ +int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct net_device *dev = ieee->dev; + struct ieee80211_hdr *hdr; + size_t hdrlen; + u16 fc, type, stype, sc; + struct net_device_stats *stats; + unsigned int frag; + u8 *payload; + u16 ethertype; +#ifdef NOT_YET + struct net_device *wds = NULL; + struct sk_buff *skb2 = NULL; + struct net_device *wds = NULL; + int frame_authorized = 0; + int from_assoc_ap = 0; + void *sta = NULL; +#endif + u8 dst[ETH_ALEN]; + u8 src[ETH_ALEN]; + struct ieee80211_crypt_data *crypt = NULL; + int keyidx = 0; + + hdr = (struct ieee80211_hdr *)skb->data; + stats = &ieee->stats; + + if (skb->len < 10) { + printk(KERN_INFO "%s: SKB length < 10\n", + dev->name); + goto rx_dropped; + } + + fc = le16_to_cpu(hdr->frame_ctl); + type = WLAN_FC_GET_TYPE(fc); + stype = WLAN_FC_GET_STYPE(fc); + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + hdrlen = ieee80211_get_hdrlen(fc); + +#ifdef NOT_YET +#if WIRELESS_EXT > 15 + /* Put this code here so that we avoid duplicating it in all + * Rx paths. - Jean II */ +#ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */ + /* If spy monitoring on */ + if (iface->spy_data.spy_number > 0) { + struct iw_quality wstats; + wstats.level = rx_stats->signal; + wstats.noise = rx_stats->noise; + wstats.updated = 6; /* No qual value */ + /* Update spy records */ + wireless_spy_update(dev, hdr->addr2, &wstats); + } +#endif /* IW_WIRELESS_SPY */ +#endif /* WIRELESS_EXT > 15 */ + hostap_update_rx_stats(local->ap, hdr, rx_stats); +#endif + +#if WIRELESS_EXT > 15 + if (ieee->iw_mode == IW_MODE_MONITOR) { + ieee80211_monitor_rx(ieee, skb, rx_stats); + stats->rx_packets++; + stats->rx_bytes += skb->len; + return 1; + } +#endif + + if (ieee->host_decrypt) { + int idx = 0; + if (skb->len >= hdrlen + 3) + idx = skb->data[hdrlen + 3] >> 6; + crypt = ieee->crypt[idx]; +#ifdef NOT_YET + sta = NULL; + + /* Use station specific key to override default keys if the + * receiver address is a unicast address ("individual RA"). If + * bcrx_sta_key parameter is set, station specific key is used + * even with broad/multicast targets (this is against IEEE + * 802.11, but makes it easier to use different keys with + * stations that do not support WEP key mapping). */ + + if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key) + (void) hostap_handle_sta_crypto(local, hdr, &crypt, + &sta); +#endif + + /* allow NULL decrypt to indicate an station specific override + * for default encryption */ + if (crypt && (crypt->ops == NULL || + crypt->ops->decrypt_mpdu == NULL)) + crypt = NULL; + + if (!crypt && (fc & IEEE80211_FCTL_WEP)) { + /* This seems to be triggered by some (multicast?) + * frames from other than current BSS, so just drop the + * frames silently instead of filling system log with + * these reports. */ + IEEE80211_DEBUG_DROP("Decryption failed (not set)" + " (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + ieee->ieee_stats.rx_discards_undecryptable++; + goto rx_dropped; + } + } + +#ifdef NOT_YET + if (type != WLAN_FC_TYPE_DATA) { + if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH && + fc & IEEE80211_FCTL_WEP && ieee->host_decrypt && + (keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0) + { + printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth " + "from " MAC_FMT "\n", dev->name, + MAC_ARG(hdr->addr2)); + /* TODO: could inform hostapd about this so that it + * could send auth failure report */ + goto rx_dropped; + } + + if (ieee80211_rx_frame_mgmt(ieee, skb, rx_stats, type, stype)) + goto rx_dropped; + else + goto rx_exit; + } +#endif + + /* Data frame - extract src/dst addresses */ + if (skb->len < IEEE80211_DATA_HDR3_LEN) + goto rx_dropped; + + switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_FROMDS: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr3, ETH_ALEN); + break; + case IEEE80211_FCTL_TODS: + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + if (skb->len < IEEE80211_DATA_HDR4_LEN) + goto rx_dropped; + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr4, ETH_ALEN); + break; + case 0: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + } + +#ifdef NOT_YET + if (hostap_rx_frame_wds(ieee, hdr, fc, &wds)) + goto rx_dropped; + if (wds) { + skb->dev = dev = wds; + stats = hostap_get_stats(dev); + } + + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && + ieee->stadev && + memcmp(hdr->addr2, ieee->assoc_ap_addr, ETH_ALEN) == 0) { + /* Frame from BSSID of the AP for which we are a client */ + skb->dev = dev = ieee->stadev; + stats = hostap_get_stats(dev); + from_assoc_ap = 1; + } +#endif + + dev->last_rx = jiffies; + +#ifdef NOT_YET + if ((ieee->iw_mode == IW_MODE_MASTER || + ieee->iw_mode == IW_MODE_REPEAT) && + !from_assoc_ap) { + switch (hostap_handle_sta_rx(ieee, dev, skb, rx_stats, + wds != NULL)) { + case AP_RX_CONTINUE_NOT_AUTHORIZED: + frame_authorized = 0; + break; + case AP_RX_CONTINUE: + frame_authorized = 1; + break; + case AP_RX_DROP: + goto rx_dropped; + case AP_RX_EXIT: + goto rx_exit; + } + } +#endif + + /* Nullfunc frames may have PS-bit set, so they must be passed to + * hostap_handle_sta_rx() before being dropped here. */ + if (stype != IEEE80211_STYPE_DATA && + stype != IEEE80211_STYPE_DATA_CFACK && + stype != IEEE80211_STYPE_DATA_CFPOLL && + stype != IEEE80211_STYPE_DATA_CFACKPOLL) { + if (stype != IEEE80211_STYPE_NULLFUNC) + IEEE80211_DEBUG_DROP( + "RX: dropped data frame " + "with no data (type=0x%02x, " + "subtype=0x%02x, len=%d)\n", + type, stype, skb->len); + goto rx_dropped; + } + + /* skb: hdr + (possibly fragmented, possibly encrypted) payload */ + + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + (keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0) + goto rx_dropped; + + hdr = (struct ieee80211_hdr *) skb->data; + + /* skb: hdr + (possibly fragmented) plaintext payload */ + // PR: FIXME: hostap has additional conditions in the "if" below: + // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) { + int flen; + struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr); + IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag); + + if (!frag_skb) { + IEEE80211_DEBUG(IEEE80211_DL_RX | IEEE80211_DL_FRAG, + "Rx cannot get skb from fragment " + "cache (morefrag=%d seq=%u frag=%u)\n", + (fc & IEEE80211_FCTL_MOREFRAGS) != 0, + WLAN_GET_SEQ_SEQ(sc), frag); + goto rx_dropped; + } + + flen = skb->len; + if (frag != 0) + flen -= hdrlen; + + if (frag_skb->tail + flen > frag_skb->end) { + printk(KERN_WARNING "%s: host decrypted and " + "reassembled frame did not fit skb\n", + dev->name); + ieee80211_frag_cache_invalidate(ieee, hdr); + goto rx_dropped; + } + + if (frag == 0) { + /* copy first fragment (including full headers) into + * beginning of the fragment cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data, flen); + } else { + /* append frame payload to the end of the fragment + * cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data + hdrlen, + flen); + } + dev_kfree_skb_any(skb); + skb = NULL; + + if (fc & IEEE80211_FCTL_MOREFRAGS) { + /* more fragments expected - leave the skb in fragment + * cache for now; it will be delivered to upper layers + * after all fragments have been received */ + goto rx_exit; + } + + /* this was the last fragment and the frame will be + * delivered, so remove skb from fragment cache */ + skb = frag_skb; + hdr = (struct ieee80211_hdr *) skb->data; + ieee80211_frag_cache_invalidate(ieee, hdr); + } + + /* skb: hdr + (possible reassembled) full MSDU payload; possibly still + * encrypted/authenticated */ + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt)) + goto rx_dropped; + + hdr = (struct ieee80211_hdr *) skb->data; + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) { + if (/*ieee->ieee802_1x &&*/ + ieee80211_is_eapol_frame(ieee, skb)) { +#ifdef CONFIG_IEEE80211_DEBUG + /* pass unencrypted EAPOL frames even if encryption is + * configured */ + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); +#endif + } else { + IEEE80211_DEBUG_DROP( + "encryption configured, but RX " + "frame not encrypted (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } + } + +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !(fc & IEEE80211_FCTL_WEP) && + ieee80211_is_eapol_frame(ieee, skb)) { + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif + + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep && + !ieee80211_is_eapol_frame(ieee, skb)) { + IEEE80211_DEBUG_DROP( + "dropped unencrypted RX data " + "frame from " MAC_FMT + " (drop_unencrypted=1)\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } + + /* skb: hdr + (possible reassembled) full plaintext payload */ + + payload = skb->data + hdrlen; + ethertype = (payload[6] << 8) | payload[7]; + +#ifdef NOT_YET + /* If IEEE 802.1X is used, check whether the port is authorized to send + * the received frame. */ + if (ieee->ieee802_1x && ieee->iw_mode == IW_MODE_MASTER) { + if (ethertype == ETH_P_PAE) { + printk(KERN_DEBUG "%s: RX: IEEE 802.1X frame\n", + dev->name); + if (ieee->hostapd && ieee->apdev) { + /* Send IEEE 802.1X frames to the user + * space daemon for processing */ + prism2_rx_80211(ieee->apdev, skb, rx_stats, + PRISM2_RX_MGMT); + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + goto rx_exit; + } + } else if (!frame_authorized) { + printk(KERN_DEBUG "%s: dropped frame from " + "unauthorized port (IEEE 802.1X): " + "ethertype=0x%04x\n", + dev->name, ethertype); + goto rx_dropped; + } + } +#endif + + /* convert hdr + possible LLC headers into Ethernet header */ + if (skb->len - hdrlen >= 8 && + ((memcmp(payload, rfc1042_header, SNAP_SIZE) == 0 && + ethertype != ETH_P_AARP && ethertype != ETH_P_IPX) || + memcmp(payload, bridge_tunnel_header, SNAP_SIZE) == 0)) { + /* remove RFC1042 or Bridge-Tunnel encapsulation and + * replace EtherType */ + skb_pull(skb, hdrlen + SNAP_SIZE); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } else { + u16 len; + /* Leave Ethernet header part of hdr and full payload */ + skb_pull(skb, hdrlen); + len = htons(skb->len); + memcpy(skb_push(skb, 2), &len, 2); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } + +#ifdef NOT_YET + if (wds && ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS) && + skb->len >= ETH_HLEN + ETH_ALEN) { + /* Non-standard frame: get addr4 from its bogus location after + * the payload */ + memcpy(skb->data + ETH_ALEN, + skb->data + skb->len - ETH_ALEN, ETH_ALEN); + skb_trim(skb, skb->len - ETH_ALEN); + } +#endif + + stats->rx_packets++; + stats->rx_bytes += skb->len; + +#ifdef NOT_YET + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + ieee->ap->bridge_packets) { + if (dst[0] & 0x01) { + /* copy multicast frame both to the higher layers and + * to the wireless media */ + ieee->ap->bridged_multicast++; + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 == NULL) + printk(KERN_DEBUG "%s: skb_clone failed for " + "multicast frame\n", dev->name); + } else if (hostap_is_sta_assoc(ieee->ap, dst)) { + /* send frame directly to the associated STA using + * wireless media and not passing to higher layers */ + ieee->ap->bridged_unicast++; + skb2 = skb; + skb = NULL; + } + } + + if (skb2 != NULL) { + /* send to wireless media */ + skb2->protocol = __constant_htons(ETH_P_802_3); + skb2->mac.raw = skb2->nh.raw = skb2->data; + /* skb2->nh.raw = skb2->data + ETH_HLEN; */ + skb2->dev = dev; + dev_queue_xmit(skb2); + } + +#endif + + if (skb) { + skb->protocol = eth_type_trans(skb, dev); + memset(skb->cb, 0, sizeof(skb->cb)); + skb->dev = dev; + skb->ip_summed = CHECKSUM_NONE; /* 802.11 crc not sufficient */ + netif_rx(skb); + } + + rx_exit: +#ifdef NOT_YET + if (sta) + hostap_handle_sta_release(sta); +#endif + return 1; + + rx_dropped: + stats->rx_dropped++; + + /* Returning 0 indicates to caller that we have not handled the SKB-- + * so it is still allocated and can be used again by underlying + * hardware as a DMA target */ + return 0; +} + +#define MGMT_FRAME_FIXED_PART_LENGTH 0x24 + +static inline int ieee80211_is_ofdm_rate(u8 rate) +{ + switch (rate & ~IEEE80211_BASIC_RATE_MASK) { + case IEEE80211_OFDM_RATE_6MB: + case IEEE80211_OFDM_RATE_9MB: + case IEEE80211_OFDM_RATE_12MB: + case IEEE80211_OFDM_RATE_18MB: + case IEEE80211_OFDM_RATE_24MB: + case IEEE80211_OFDM_RATE_36MB: + case IEEE80211_OFDM_RATE_48MB: + case IEEE80211_OFDM_RATE_54MB: + return 1; + } + return 0; +} + + +static inline int ieee80211_network_init( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_network *network, + struct ieee80211_rx_stats *stats) +{ +#ifdef CONFIG_IEEE80211_DEBUG + char rates_str[64]; + char *p; +#endif + struct ieee80211_info_element *info_element; + u16 left; + u8 i; + + /* Pull out fixed field data */ + memcpy(network->bssid, beacon->header.addr3, ETH_ALEN); + network->capability = beacon->capability; + network->last_scanned = jiffies; + network->time_stamp[0] = beacon->time_stamp[0]; + network->time_stamp[1] = beacon->time_stamp[1]; + network->beacon_interval = beacon->beacon_interval; + /* Where to pull this? beacon->listen_interval;*/ + network->listen_interval = 0x0A; + network->rates_len = network->rates_ex_len = 0; + network->last_associate = 0; + network->ssid_len = 0; + network->flags = 0; + network->atim_window = 0; + + if (stats->freq == IEEE80211_52GHZ_BAND) { + /* for A band (No DS info) */ + network->channel = stats->received_channel; + } else + network->flags |= NETWORK_HAS_CCK; + + network->wpa_ie_len = 0; + network->rsn_ie_len = 0; + + info_element = &beacon->info_element; + left = stats->len - ((void *)info_element - (void *)beacon); + while (left >= sizeof(struct ieee80211_info_element_hdr)) { + if (sizeof(struct ieee80211_info_element_hdr) + info_element->len > left) { + IEEE80211_DEBUG_SCAN("SCAN: parse failed: info_element->len + 2 > left : info_element->len+2=%d left=%d.\n", + info_element->len + sizeof(struct ieee80211_info_element), + left); + return 1; + } + + switch (info_element->id) { + case MFIE_TYPE_SSID: + if (ieee80211_is_empty_essid(info_element->data, + info_element->len)) { + network->flags |= NETWORK_EMPTY_ESSID; + break; + } + + network->ssid_len = min(info_element->len, + (u8)IW_ESSID_MAX_SIZE); + memcpy(network->ssid, info_element->data, network->ssid_len); + if (network->ssid_len < IW_ESSID_MAX_SIZE) + memset(network->ssid + network->ssid_len, 0, + IW_ESSID_MAX_SIZE - network->ssid_len); + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_SSID: '%s' len=%d.\n", + network->ssid, network->ssid_len); + break; + + case MFIE_TYPE_RATES: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_len = min(info_element->len, MAX_RATES_LENGTH); + for (i = 0; i < network->rates_len; i++) { + network->rates[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES: '%s' (%d)\n", + rates_str, network->rates_len); + break; + + case MFIE_TYPE_RATES_EX: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_ex_len = min(info_element->len, MAX_RATES_EX_LENGTH); + for (i = 0; i < network->rates_ex_len; i++) { + network->rates_ex[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES_EX: '%s' (%d)\n", + rates_str, network->rates_ex_len); + break; + + case MFIE_TYPE_DS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_DS_SET: %d\n", + info_element->data[0]); + if (stats->freq == IEEE80211_24GHZ_BAND) + network->channel = info_element->data[0]; + break; + + case MFIE_TYPE_FH_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_FH_SET: ignored\n"); + break; + + case MFIE_TYPE_CF_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CF_SET: ignored\n"); + break; + + case MFIE_TYPE_TIM: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_TIM: ignored\n"); + break; + + case MFIE_TYPE_IBSS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_IBSS_SET: ignored\n"); + break; + + case MFIE_TYPE_CHALLENGE: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CHALLENGE: ignored\n"); + break; + + case MFIE_TYPE_GENERIC: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_GENERIC: %d bytes\n", + info_element->len); + if (info_element->len >= 4 && + info_element->data[0] == 0x00 && + info_element->data[1] == 0x50 && + info_element->data[2] == 0xf2 && + info_element->data[3] == 0x01) { + network->wpa_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->wpa_ie, info_element, + network->wpa_ie_len); + } + break; + + case MFIE_TYPE_RSN: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RSN: %d bytes\n", + info_element->len); + network->rsn_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->rsn_ie, info_element, + network->rsn_ie_len); + break; + + default: + IEEE80211_DEBUG_SCAN("unsupported IE %d\n", + info_element->id); + break; + } + + left -= sizeof(struct ieee80211_info_element_hdr) + + info_element->len; + info_element = (struct ieee80211_info_element *) + &info_element->data[info_element->len]; + } + + network->mode = 0; + if (stats->freq == IEEE80211_52GHZ_BAND) + network->mode = IEEE_A; + else { + if (network->flags & NETWORK_HAS_OFDM) + network->mode |= IEEE_G; + if (network->flags & NETWORK_HAS_CCK) + network->mode |= IEEE_B; + } + + if (network->mode == 0) { + IEEE80211_DEBUG_SCAN("Filtered out '%s (" MAC_FMT ")' " + "network.\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid)); + return 1; + } + + if (ieee80211_is_empty_essid(network->ssid, network->ssid_len)) + network->flags |= NETWORK_EMPTY_ESSID; + + memcpy(&network->stats, stats, sizeof(network->stats)); + + return 0; +} + +static inline int is_same_network(struct ieee80211_network *src, + struct ieee80211_network *dst) +{ + /* A network is only a duplicate if the channel, BSSID, and ESSID + * all match. We treat all with the same BSSID and channel + * as one network */ + return ((src->ssid_len == dst->ssid_len) && + (src->channel == dst->channel) && + !memcmp(src->bssid, dst->bssid, ETH_ALEN) && + !memcmp(src->ssid, dst->ssid, src->ssid_len)); +} + +static inline void update_network(struct ieee80211_network *dst, + struct ieee80211_network *src) +{ + memcpy(&dst->stats, &src->stats, sizeof(struct ieee80211_rx_stats)); + dst->capability = src->capability; + memcpy(dst->rates, src->rates, src->rates_len); + dst->rates_len = src->rates_len; + memcpy(dst->rates_ex, src->rates_ex, src->rates_ex_len); + dst->rates_ex_len = src->rates_ex_len; + + dst->mode = src->mode; + dst->flags = src->flags; + dst->time_stamp[0] = src->time_stamp[0]; + dst->time_stamp[1] = src->time_stamp[1]; + + dst->beacon_interval = src->beacon_interval; + dst->listen_interval = src->listen_interval; + dst->atim_window = src->atim_window; + + memcpy(dst->wpa_ie, src->wpa_ie, src->wpa_ie_len); + dst->wpa_ie_len = src->wpa_ie_len; + memcpy(dst->rsn_ie, src->rsn_ie, src->rsn_ie_len); + dst->rsn_ie_len = src->rsn_ie_len; + + dst->last_scanned = jiffies; + /* dst->last_associate is not overwritten */ +} + +static inline void ieee80211_process_probe_response( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_rx_stats *stats) +{ + struct ieee80211_network network; + struct ieee80211_network *target; + struct ieee80211_network *oldest = NULL; +#ifdef CONFIG_IEEE80211_DEBUG + struct ieee80211_info_element *info_element = &beacon->info_element; +#endif + unsigned long flags; + + IEEE80211_DEBUG_SCAN( + "'%s' (" MAC_FMT "): %c%c%c%c %c%c%c%c-%c%c%c%c %c%c%c%c\n", + escape_essid(info_element->data, info_element->len), + MAC_ARG(beacon->header.addr3), + (beacon->capability & (1<<0xf)) ? '1' : '0', + (beacon->capability & (1<<0xe)) ? '1' : '0', + (beacon->capability & (1<<0xd)) ? '1' : '0', + (beacon->capability & (1<<0xc)) ? '1' : '0', + (beacon->capability & (1<<0xb)) ? '1' : '0', + (beacon->capability & (1<<0xa)) ? '1' : '0', + (beacon->capability & (1<<0x9)) ? '1' : '0', + (beacon->capability & (1<<0x8)) ? '1' : '0', + (beacon->capability & (1<<0x7)) ? '1' : '0', + (beacon->capability & (1<<0x6)) ? '1' : '0', + (beacon->capability & (1<<0x5)) ? '1' : '0', + (beacon->capability & (1<<0x4)) ? '1' : '0', + (beacon->capability & (1<<0x3)) ? '1' : '0', + (beacon->capability & (1<<0x2)) ? '1' : '0', + (beacon->capability & (1<<0x1)) ? '1' : '0', + (beacon->capability & (1<<0x0)) ? '1' : '0'); + + if (ieee80211_network_init(ieee, beacon, &network, stats)) { + IEEE80211_DEBUG_SCAN("Dropped '%s' (" MAC_FMT ") via %s.\n", + escape_essid(info_element->data, + info_element->len), + MAC_ARG(beacon->header.addr3), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + return; + } + + /* The network parsed correctly -- so now we scan our known networks + * to see if we can find it in our list. + * + * NOTE: This search is definitely not optimized. Once its doing + * the "right thing" we'll optimize it for efficiency if + * necessary */ + + /* Search for this entry in the list and update it if it is + * already there. */ + + spin_lock_irqsave(&ieee->lock, flags); + + list_for_each_entry(target, &ieee->network_list, list) { + if (is_same_network(target, &network)) + break; + + if ((oldest == NULL) || + (target->last_scanned < oldest->last_scanned)) + oldest = target; + } + + /* If we didn't find a match, then get a new network slot to initialize + * with this beacon's information */ + if (&target->list == &ieee->network_list) { + if (list_empty(&ieee->network_free_list)) { + /* If there are no more slots, expire the oldest */ + list_del(&oldest->list); + target = oldest; + IEEE80211_DEBUG_SCAN("Expired '%s' (" MAC_FMT ") from " + "network list.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid)); + } else { + /* Otherwise just pull from the free list */ + target = list_entry(ieee->network_free_list.next, + struct ieee80211_network, list); + list_del(ieee->network_free_list.next); + } + + +#ifdef CONFIG_IEEE80211_DEBUG + IEEE80211_DEBUG_SCAN("Adding '%s' (" MAC_FMT ") via %s.\n", + escape_essid(network.ssid, + network.ssid_len), + MAC_ARG(network.bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); +#endif + memcpy(target, &network, sizeof(*target)); + list_add_tail(&target->list, &ieee->network_list); + } else { + IEEE80211_DEBUG_SCAN("Updating '%s' (" MAC_FMT ") via %s.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + update_network(target, &network); + } + + spin_unlock_irqrestore(&ieee->lock, flags); +} + +void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats) +{ + switch (WLAN_FC_GET_STYPE(header->frame_ctl)) { + case IEEE80211_STYPE_ASSOC_RESP: + IEEE80211_DEBUG_MGMT("received ASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_REASSOC_RESP: + IEEE80211_DEBUG_MGMT("received REASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_PROBE_RESP: + IEEE80211_DEBUG_MGMT("received PROBE RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Probe response\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + case IEEE80211_STYPE_BEACON: + IEEE80211_DEBUG_MGMT("received BEACON (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Beacon\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + default: + IEEE80211_DEBUG_MGMT("received UNKNOWN (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_WARNING("%s: Unknown management packet: %d\n", + ieee->dev->name, + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + } +} + + +EXPORT_SYMBOL(ieee80211_rx_mgt); +EXPORT_SYMBOL(ieee80211_rx); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_tx.c netdev-2.6-ipw/net/ieee80211/ieee80211_tx.c --- netdev-2.6/net/ieee80211/ieee80211_tx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_tx.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,448 @@ +/****************************************************************************** + + Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved. + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + The full GNU General Public License is included in this distribution in the + file called LICENSE. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +/* + + +802.11 Data Frame + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | Frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `--------------------------------------------------| |------' +Total: 28 non-data bytes `----.----' + | + .- 'Frame data' expands to <---------------------------' + | + V + ,---------------------------------------------------. +Bytes | 1 | 1 | 1 | 3 | 2 | 0-2304 | + |------|------|---------|----------|------|---------| +Desc. | SNAP | SNAP | Control |Eth Tunnel| Type | IP | + | DSAP | SSAP | | | | Packet | + | 0xAA | 0xAA |0x03 (UI)|0x00-00-F8| | | + `-----------------------------------------| | +Total: 8 non-data bytes `----.----' + | + .- 'IP Packet' expands, if WEP enabled, to <--' + | + V + ,-----------------------. +Bytes | 4 | 0-2296 | 4 | + |-----|-----------|-----| +Desc. | IV | Encrypted | ICV | + | | IP Packet | | + `-----------------------' +Total: 8 non-data bytes + + +802.3 Ethernet Data Frame + + ,-----------------------------------------. +Bytes | 6 | 6 | 2 | Variable | 4 | + |-------|-------|------|-----------|------| +Desc. | Dest. | Source| Type | IP Packet | fcs | + | MAC | MAC | | | | + `-----------------------------------------' +Total: 18 non-data bytes + +In the event that fragmentation is required, the incoming payload is split into +N parts of size ieee->fts. The first fragment contains the SNAP header and the +remaining packets are just data. + +If encryption is enabled, each fragment payload size is reduced by enough space +to add the prefix and postfix (IV and ICV totalling 8 bytes in the case of WEP) +So if you have 1500 bytes of payload with ieee->fts set to 500 without +encryption it will take 3 frames. With WEP it will take 4 frames as the +payload of each frame is reduced to 492 bytes. + +* SKB visualization +* +* ,- skb->data +* | +* | ETHERNET HEADER ,-<-- PAYLOAD +* | | 14 bytes from skb->data +* | 2 bytes for Type --> ,T. | (sizeof ethhdr) +* | | | | +* |,-Dest.--. ,--Src.---. | | | +* | 6 bytes| | 6 bytes | | | | +* v | | | | | | +* 0 | v 1 | v | v 2 +* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +* ^ | ^ | ^ | +* | | | | | | +* | | | | `T' <---- 2 bytes for Type +* | | | | +* | | '---SNAP--' <-------- 6 bytes for SNAP +* | | +* `-IV--' <-------------------- 4 bytes for IV (WEP) +* +* SNAP HEADER +* +*/ + +static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; +static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; + +static inline int ieee80211_put_snap(u8 *data, u16 h_proto) +{ + struct ieee80211_snap_hdr *snap; + u8 *oui; + + snap = (struct ieee80211_snap_hdr *)data; + snap->dsap = 0xaa; + snap->ssap = 0xaa; + snap->ctrl = 0x03; + + if (h_proto == 0x8137 || h_proto == 0x80f3) + oui = P802_1H_OUI; + else + oui = RFC1042_OUI; + snap->oui[0] = oui[0]; + snap->oui[1] = oui[1]; + snap->oui[2] = oui[2]; + + *(u16 *)(data + SNAP_SIZE) = htons(h_proto); + + return SNAP_SIZE + sizeof(u16); +} + +static inline int ieee80211_encrypt_fragment( + struct ieee80211_device *ieee, + struct sk_buff *frag, + int hdr_len) +{ + struct ieee80211_crypt_data* crypt = ieee->crypt[ieee->tx_keyidx]; + int res; + +#ifdef CONFIG_IEEE80211_CRYPT_TKIP + struct ieee80211_hdr *header; + + if (ieee->tkip_countermeasures && + crypt && crypt->ops && strcmp(crypt->ops->name, "TKIP") == 0) { + header = (struct ieee80211_hdr *) frag->data; + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "TX packet to " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(header->addr1)); + } + return -1; + } +#endif + /* To encrypt, frame format is: + * IV (4 bytes), clear payload (including SNAP), ICV (4 bytes) */ + + // PR: FIXME: Copied from hostap. Check fragmentation/MSDU/MPDU encryption. + /* Host-based IEEE 802.11 fragmentation for TX is not yet supported, so + * call both MSDU and MPDU encryption functions from here. */ + atomic_inc(&crypt->refcnt); + res = 0; + if (crypt->ops->encrypt_msdu) + res = crypt->ops->encrypt_msdu(frag, hdr_len, crypt->priv); + if (res == 0 && crypt->ops->encrypt_mpdu) + res = crypt->ops->encrypt_mpdu(frag, hdr_len, crypt->priv); + + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_INFO "%s: Encryption failed: len=%d.\n", + ieee->dev->name, frag->len); + ieee->ieee_stats.tx_discards++; + return -1; + } + + return 0; +} + + +void ieee80211_txb_free(struct ieee80211_txb *txb) { + int i; + if (unlikely(!txb)) + return; + for (i = 0; i < txb->nr_frags; i++) + if (txb->fragments[i]) + dev_kfree_skb_any(txb->fragments[i]); + kfree(txb); +} + +struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size, + int gfp_mask) +{ + struct ieee80211_txb *txb; + int i; + txb = kmalloc( + sizeof(struct ieee80211_txb) + (sizeof(u8*) * nr_frags), + gfp_mask); + if (!txb) + return NULL; + + memset(txb, sizeof(struct ieee80211_txb), 0); + txb->nr_frags = nr_frags; + txb->frag_size = txb_size; + + for (i = 0; i < nr_frags; i++) { + txb->fragments[i] = dev_alloc_skb(txb_size); + if (unlikely(!txb->fragments[i])) { + i--; + break; + } + } + if (unlikely(i != nr_frags)) { + while (i >= 0) + dev_kfree_skb_any(txb->fragments[i--]); + kfree(txb); + return NULL; + } + return txb; +} + +/* SKBs are added to the ieee->tx_queue. */ +int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_txb *txb = NULL; + struct ieee80211_hdr *frag_hdr; + int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size; + unsigned long flags; + struct net_device_stats *stats = &ieee->stats; + int ether_type, encrypt; + int bytes, fc, hdr_len; + struct sk_buff *skb_frag; + struct ieee80211_hdr header = { /* Ensure zero initialized */ + .duration_id = 0, + .seq_ctl = 0 + }; + u8 dest[ETH_ALEN], src[ETH_ALEN]; + + struct ieee80211_crypt_data* crypt; + + spin_lock_irqsave(&ieee->lock, flags); + + /* If there is no driver handler to take the TXB, dont' bother + * creating it... */ + if (!ieee->hard_start_xmit) { + printk(KERN_WARNING "%s: No xmit handler.\n", + ieee->dev->name); + goto success; + } + + if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { + printk(KERN_WARNING "%s: skb too small (%d).\n", + ieee->dev->name, skb->len); + goto success; + } + + ether_type = ntohs(((struct ethhdr *)skb->data)->h_proto); + + crypt = ieee->crypt[ieee->tx_keyidx]; + + encrypt = !(ether_type == ETH_P_PAE && ieee->ieee802_1x) && + ieee->host_encrypt && crypt && crypt->ops; + + if (!encrypt && ieee->ieee802_1x && + ieee->drop_unencrypted && ether_type != ETH_P_PAE) { + stats->tx_dropped++; + goto success; + } + +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !encrypt && ether_type == ETH_P_PAE) { + struct eapol *eap = (struct eapol *)(skb->data + + sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16)); + IEEE80211_DEBUG_EAP("TX: IEEE 802.11 EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif + + /* Save source and destination addresses */ + memcpy(&dest, skb->data, ETH_ALEN); + memcpy(&src, skb->data+ETH_ALEN, ETH_ALEN); + + /* Advance the SKB to the start of the payload */ + skb_pull(skb, sizeof(struct ethhdr)); + + /* Determine total amount of storage required for TXB packets */ + bytes = skb->len + SNAP_SIZE + sizeof(u16); + + if (encrypt) + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | + IEEE80211_FCTL_WEP; + else + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(&header.addr1, ieee->bssid, ETH_ALEN); + memcpy(&header.addr2, &src, ETH_ALEN); + memcpy(&header.addr3, &dest, ETH_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + memcpy(&header.addr1, dest, ETH_ALEN); + memcpy(&header.addr2, src, ETH_ALEN); + memcpy(&header.addr3, ieee->bssid, ETH_ALEN); + } + header.frame_ctl = cpu_to_le16(fc); + hdr_len = IEEE80211_3ADDR_LEN; + + /* Determine fragmentation size based on destination (multicast + * and broadcast are not fragmented) */ + if (is_multicast_ether_addr(dest) || + is_broadcast_ether_addr(dest)) + frag_size = MAX_FRAG_THRESHOLD; + else + frag_size = ieee->fts; + + /* Determine amount of payload per fragment. Regardless of if + * this stack is providing the full 802.11 header, one will + * eventually be affixed to this fragment -- so we must account for + * it when determining the amount of payload space. */ + bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN; + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + bytes_per_frag -= IEEE80211_FCS_LEN; + + /* Each fragment may need to have room for encryptiong pre/postfix */ + if (encrypt) + bytes_per_frag -= crypt->ops->extra_prefix_len + + crypt->ops->extra_postfix_len; + + /* Number of fragments is the total bytes_per_frag / + * payload_per_fragment */ + nr_frags = bytes / bytes_per_frag; + bytes_last_frag = bytes % bytes_per_frag; + if (bytes_last_frag) + nr_frags++; + else + bytes_last_frag = bytes_per_frag; + + /* When we allocate the TXB we allocate enough space for the reserve + * and full fragment bytes (bytes_per_frag doesn't include prefix, + * postfix, header, FCS, etc.) */ + txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC); + if (unlikely(!txb)) { + printk(KERN_WARNING "%s: Could not allocate TXB\n", + ieee->dev->name); + goto failed; + } + txb->encrypted = encrypt; + txb->payload_size = bytes; + + for (i = 0; i < nr_frags; i++) { + skb_frag = txb->fragments[i]; + + if (encrypt) + skb_reserve(skb_frag, crypt->ops->extra_prefix_len); + + frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); + memcpy(frag_hdr, &header, hdr_len); + + /* If this is not the last fragment, then add the MOREFRAGS + * bit to the frame control */ + if (i != nr_frags - 1) { + frag_hdr->frame_ctl = cpu_to_le16( + fc | IEEE80211_FCTL_MOREFRAGS); + bytes = bytes_per_frag; + } else { + /* The last fragment takes the remaining length */ + bytes = bytes_last_frag; + } + + /* Put a SNAP header on the first fragment */ + if (i == 0) { + ieee80211_put_snap( + skb_put(skb_frag, SNAP_SIZE + sizeof(u16)), + ether_type); + bytes -= SNAP_SIZE + sizeof(u16); + } + + memcpy(skb_put(skb_frag, bytes), skb->data, bytes); + + /* Advance the SKB... */ + skb_pull(skb, bytes); + + /* Encryption routine will move the header forward in order + * to insert the IV between the header and the payload */ + if (encrypt) + ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len); + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + skb_put(skb_frag, 4); + } + + + success: + spin_unlock_irqrestore(&ieee->lock, flags); + + dev_kfree_skb_any(skb); + + if (txb) { + if ((*ieee->hard_start_xmit)(txb, dev) == 0) { + stats->tx_packets++; + stats->tx_bytes += txb->payload_size; + return 0; + } + ieee80211_txb_free(txb); + } + + return 0; + + failed: + spin_unlock_irqrestore(&ieee->lock, flags); + netif_stop_queue(dev); + stats->tx_errors++; + return 1; + +} + +EXPORT_SYMBOL(ieee80211_txb_free); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/net/ieee80211/ieee80211_wx.c netdev-2.6-ipw/net/ieee80211/ieee80211_wx.c --- netdev-2.6/net/ieee80211/ieee80211_wx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/net/ieee80211/ieee80211_wx.c 2005-02-10 17:07:47 -06:00 @@ -0,0 +1,471 @@ +/****************************************************************************** + + Copyright(c) 2004 Intel Corporation. All rights reserved. + + Portions of this file are based on the WEP enablement code provided by the + Host AP project hostap-drivers v0.1.3 + Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + + Copyright (c) 2002-2003, Jouni Malinen + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + The full GNU General Public License is included in this distribution in the + file called LICENSE. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include + +#include +static const char *ieee80211_modes[] = { + "?", "a", "b", "ab", "g", "ag", "bg", "abg" +}; + +#define MAX_CUSTOM_LEN 64 +static inline char *ipw2100_translate_scan(struct ieee80211_device *ieee, + char *start, char *stop, + struct ieee80211_network *network) +{ + char custom[MAX_CUSTOM_LEN]; + char *p; + struct iw_event iwe; + int i, j; + u8 max_rate, rate; + + /* First entry *MUST* be the AP MAC address */ + iwe.cmd = SIOCGIWAP; + iwe.u.ap_addr.sa_family = ARPHRD_ETHER; + memcpy(iwe.u.ap_addr.sa_data, network->bssid, ETH_ALEN); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_ADDR_LEN); + + /* Remaining entries will be displayed in the order we provide them */ + + /* Add the ESSID */ + iwe.cmd = SIOCGIWESSID; + iwe.u.data.flags = 1; + if (network->flags & NETWORK_EMPTY_ESSID) { + iwe.u.data.length = sizeof(""); + start = iwe_stream_add_point(start, stop, &iwe, ""); + } else { + iwe.u.data.length = min(network->ssid_len, (u8)32); + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + } + + /* Add the protocol name */ + iwe.cmd = SIOCGIWNAME; + snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11%s", ieee80211_modes[network->mode]); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_CHAR_LEN); + + /* Add mode */ + iwe.cmd = SIOCGIWMODE; + if (network->capability & + (WLAN_CAPABILITY_BSS | WLAN_CAPABILITY_IBSS)) { + if (network->capability & WLAN_CAPABILITY_BSS) + iwe.u.mode = IW_MODE_MASTER; + else + iwe.u.mode = IW_MODE_ADHOC; + + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_UINT_LEN); + } + + /* Add frequency/channel */ + iwe.cmd = SIOCGIWFREQ; +/* iwe.u.freq.m = ieee80211_frequency(network->channel, network->mode); + iwe.u.freq.e = 3; */ + iwe.u.freq.m = network->channel; + iwe.u.freq.e = 0; + iwe.u.freq.i = 0; + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_FREQ_LEN); + + /* Add encryption capability */ + iwe.cmd = SIOCGIWENCODE; + if (network->capability & WLAN_CAPABILITY_PRIVACY) + iwe.u.data.flags = IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags = IW_ENCODE_DISABLED; + iwe.u.data.length = 0; + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + + /* Add basic and extended rates */ + max_rate = 0; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), " Rates (Mb/s): "); + for (i = 0, j = 0; i < network->rates_len; ) { + if (j < network->rates_ex_len && + ((network->rates_ex[j] & 0x7F) < + (network->rates[i] & 0x7F))) + rate = network->rates_ex[j++] & 0x7F; + else + rate = network->rates[i++] & 0x7F; + if (rate > max_rate) + max_rate = rate; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + } + for (; j < network->rates_ex_len; j++) { + rate = network->rates_ex[j] & 0x7F; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + if (rate > max_rate) + max_rate = rate; + } + + iwe.cmd = SIOCGIWRATE; + iwe.u.bitrate.fixed = iwe.u.bitrate.disabled = 0; + iwe.u.bitrate.value = max_rate * 500000; + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_PARAM_LEN); + + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + /* Add quality statistics */ + /* TODO: Fix these values... */ + iwe.cmd = IWEVQUAL; + iwe.u.qual.qual = network->stats.signal; + iwe.u.qual.level = network->stats.rssi; + iwe.u.qual.noise = network->stats.noise; + iwe.u.qual.updated = network->stats.mask & IEEE80211_STATMASK_WEMASK; + if (!(network->stats.mask & IEEE80211_STATMASK_RSSI)) + iwe.u.qual.updated |= IW_QUAL_LEVEL_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_NOISE)) + iwe.u.qual.updated |= IW_QUAL_NOISE_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_SIGNAL)) + iwe.u.qual.updated |= IW_QUAL_QUAL_INVALID; + + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_QUAL_LEN); + + iwe.cmd = IWEVCUSTOM; + p = custom; + + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + if (ieee->wpa_enabled && network->wpa_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "wpa_ie="); + for (i = 0; i < network->wpa_ie_len; i++) { + p += sprintf(p, "%02x", network->wpa_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + + if (ieee->wpa_enabled && network->rsn_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "rsn_ie="); + for (i = 0; i < network->rsn_ie_len; i++) { + p += sprintf(p, "%02x", network->rsn_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + + /* Add EXTRA: Age to display seconds since last beacon/probe response + * for given network. */ + iwe.cmd = IWEVCUSTOM; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Last beacon: %lums ago", (jiffies - network->last_scanned) / (HZ / 100)); + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + + return start; +} + +int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *extra) +{ + struct ieee80211_network *network; + unsigned long flags; + + char *ev = extra; + char *stop = ev + IW_SCAN_MAX_DATA; + int i = 0; + + IEEE80211_DEBUG_WX("Getting scan\n"); + + spin_lock_irqsave(&ieee->lock, flags); + + list_for_each_entry(network, &ieee->network_list, list) { + i++; + if (ieee->scan_age == 0 || + time_after(network->last_scanned + ieee->scan_age, jiffies)) + ev = ipw2100_translate_scan(ieee, ev, stop, network); + else + IEEE80211_DEBUG_SCAN( + "Not showing network '%s (" + MAC_FMT ")' due to age (%lums).\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid), + (jiffies - network->last_scanned) / (HZ / 100)); + } + + spin_unlock_irqrestore(&ieee->lock, flags); + + wrqu->data.length = ev - extra; + wrqu->data.flags = 0; + + IEEE80211_DEBUG_WX("exit: %d networks returned.\n", i); + + return 0; +} + +int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); + struct net_device *dev = ieee->dev; + struct ieee80211_security sec = { + .flags = 0 + }; + int i, key, key_provided, len; + struct ieee80211_crypt_data **crypt; + + IEEE80211_DEBUG_WX("SET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + key_provided = 1; + } else { + key_provided = 0; + key = ieee->tx_keyidx; + } + + IEEE80211_DEBUG_WX("Key: %d [%s]\n", key, key_provided ? + "provided" : "default"); + + crypt = &ieee->crypt[key]; + + if (erq->flags & IW_ENCODE_DISABLED) { + if (key_provided && *crypt) { + IEEE80211_DEBUG_WX("Disabling encryption on key %d.\n", + key); + ieee80211_crypt_delayed_deinit(ieee, crypt); + } else + IEEE80211_DEBUG_WX("Disabling encryption.\n"); + + /* Check all the keys to see if any are still configured, + * and if no key index was provided, de-init them all */ + for (i = 0; i < WEP_KEYS; i++) { + if (ieee->crypt[i] != NULL) { + if (key_provided) + break; + ieee80211_crypt_delayed_deinit( + ieee, &ieee->crypt[i]); + } + } + + if (i == WEP_KEYS) { + sec.enabled = 0; + sec.level = SEC_LEVEL_0; + sec.flags |= SEC_ENABLED | SEC_LEVEL; + } + + goto done; + } + + + + sec.enabled = 1; + sec.flags |= SEC_ENABLED; + + if (*crypt != NULL && (*crypt)->ops != NULL && + strcmp((*crypt)->ops->name, "WEP") != 0) { + /* changing to use WEP; deinit previously used algorithm + * on this key */ + ieee80211_crypt_delayed_deinit(ieee, crypt); + } + + if (*crypt == NULL) { + struct ieee80211_crypt_data *new_crypt; + + /* take WEP into use */ + new_crypt = kmalloc(sizeof(struct ieee80211_crypt_data), + GFP_KERNEL); + if (new_crypt == NULL) + return -ENOMEM; + memset(new_crypt, 0, sizeof(struct ieee80211_crypt_data)); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + if (!new_crypt->ops) { + request_module("ieee80211_crypt_wep"); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + } + + if (new_crypt->ops && try_module_get(new_crypt->ops->owner)) + new_crypt->priv = new_crypt->ops->init(key); + + if (!new_crypt->ops || !new_crypt->priv) { + kfree(new_crypt); + new_crypt = NULL; + + printk(KERN_WARNING "%s: could not initialize WEP: " + "load module ieee80211_crypt_wep\n", + dev->name); + return -EOPNOTSUPP; + } + *crypt = new_crypt; + } + + /* If a new key was provided, set it up */ + if (erq->length > 0) { + len = erq->length <= 5 ? 5 : 13; + memcpy(sec.keys[key], keybuf, erq->length); + if (len > erq->length) + memset(sec.keys[key] + erq->length, 0, + len - erq->length); + IEEE80211_DEBUG_WX("Setting key %d to '%s' (%d:%d bytes)\n", + key, escape_essid(sec.keys[key], len), + erq->length, len); + sec.key_sizes[key] = len; + (*crypt)->ops->set_key(sec.keys[key], len, NULL, + (*crypt)->priv); + sec.flags |= (1 << key); + /* This ensures a key will be activated if no key is + * explicitely set */ + if (key == sec.active_key) + sec.flags |= SEC_ACTIVE_KEY; + } else { + len = (*crypt)->ops->get_key(sec.keys[key], WEP_KEY_LEN, + NULL, (*crypt)->priv); + if (len == 0) { + /* Set a default key of all 0 */ + IEEE80211_DEBUG_WX("Setting key %d to all zero.\n", + key); + memset(sec.keys[key], 0, 13); + (*crypt)->ops->set_key(sec.keys[key], 13, NULL, + (*crypt)->priv); + sec.key_sizes[key] = 13; + sec.flags |= (1 << key); + } + + /* No key data - just set the default TX key index */ + if (key_provided) { + IEEE80211_DEBUG_WX( + "Setting key %d to default Tx key.\n", key); + ieee->tx_keyidx = key; + sec.active_key = key; + sec.flags |= SEC_ACTIVE_KEY; + } + } + + done: + ieee->open_wep = !(erq->flags & IW_ENCODE_RESTRICTED); + sec.auth_mode = ieee->open_wep ? WLAN_AUTH_OPEN : WLAN_AUTH_SHARED_KEY; + sec.flags |= SEC_AUTH_MODE; + IEEE80211_DEBUG_WX("Auth: %s\n", sec.auth_mode == WLAN_AUTH_OPEN ? + "OPEN" : "SHARED KEY"); + + /* For now we just support WEP, so only set that security level... + * TODO: When WPA is added this is one place that needs to change */ + sec.flags |= SEC_LEVEL; + sec.level = SEC_LEVEL_1; /* 40 and 104 bit WEP */ + + if (ieee->set_security) + ieee->set_security(dev, &sec); + + /* Do not reset port if card is in Managed mode since resetting will + * generate new IEEE 802.11 authentication which may end up in looping + * with IEEE 802.1X. If your hardware requires a reset after WEP + * configuration (for example... Prism2), implement the reset_port in + * the callbacks structures used to initialize the 802.11 stack. */ + if (ieee->reset_on_keychange && + ieee->iw_mode != IW_MODE_INFRA && + ieee->reset_port && ieee->reset_port(dev)) { + printk(KERN_DEBUG "%s: reset_port failed\n", dev->name); + return -EINVAL; + } + return 0; +} + +int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); + int len, key; + struct ieee80211_crypt_data *crypt; + + IEEE80211_DEBUG_WX("GET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + } else + key = ieee->tx_keyidx; + + crypt = ieee->crypt[key]; + erq->flags = key + 1; + + if (crypt == NULL || crypt->ops == NULL) { + erq->length = 0; + erq->flags |= IW_ENCODE_DISABLED; + return 0; + } + + if (strcmp(crypt->ops->name, "WEP") != 0) { + /* only WEP is supported with wireless extensions, so just + * report that encryption is used */ + erq->length = 0; + erq->flags |= IW_ENCODE_ENABLED; + return 0; + } + + len = crypt->ops->get_key(keybuf, WEP_KEY_LEN, NULL, crypt->priv); + erq->length = (len >= 0 ? len : 0); + + erq->flags |= IW_ENCODE_ENABLED; + + if (ieee->open_wep) + erq->flags |= IW_ENCODE_OPEN; + else + erq->flags |= IW_ENCODE_RESTRICTED; + + return 0; +} + +EXPORT_SYMBOL(ieee80211_wx_get_scan); +EXPORT_SYMBOL(ieee80211_wx_set_encode); +EXPORT_SYMBOL(ieee80211_wx_get_encode); --------------040200080309090603080508 Content-Type: text/plain; name="TODO" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TODO" ------- From Randy Dunlap: 3. +static int __init ieee80211_crypto_init(void) + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); That register call can fail, so I'd rather see it checked, as in all of the other similar register calls. 6. +struct ieee80211_ccmp_data { + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; Are these MIB-mandated names? otherwise the studlyCaps should go. 7. +static int ieee80211_ccmp_decrypt() Does anything care about the various negative/error case return values? 8. What calls the .print_stats functions? static char * ieee80211_ccmp_print_stats() Is it possible to use seq_file there instead of sprintf(), or is this in /sysfs (so seq_file is not possible)? Are there any overflow possibilities? Enough for tonight... Here are a few more comments. 1. No need to check ptr for NULL before kfree(ptr), so several places like this can be simplified: +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } 3. +static inline int ieee80211_network_init() is more than 200 lines. Somebody likes huge inline functions. ------------------------- From Stephen Hemminger 1. You can get rid of the /proc interface altogether since now with sysfs module parameters can be made accessible via module_param 2. Include files need to be moved and factored better: include/linux/ieee80211.h for anything exposed to utilities and general API related include/net/ieee80211.h for interfaces other drivers would use. drivers/net/wireless/iee80211/iee80211_xxx.h for stuff that only gets used internally. 4. Don't put data in .h files like eap_types[] Maybe just move eap_get_type() to .c fle 5. Use C99 initializers for tags arrays like eap_types[] i.e static const char *eap_types[] = { [EAP_PACKET] = "EAP-Packet", ... 5. Move is_broadcast_addr and is_multicast_addr to etherdevice.h besides is_muliticast_addr(x) has extra uneeded test. 6. Don't put format type stuff in .h file MAC_FMT, MAC_ARG, etc... 8. Patch if_ether.h rather than stuff like: #ifndef ETH_P_80211_RAW #define ETH_P_80211_RAW (ETH_P_ECONET + 1) #endif 9. Isn't SNAP generic and not part of just wireless, LLC and other places like ATM have the similar stuff, maybe one set of routines and definitions? 10. Do we really need another set of statistics? Already have ethtool, net_stats, wireless, ...? 11. Does ieee->scans need to be atomic? 12. offset_in_page() shouldn't be here and is defined elsewhere. The basic philosophy changes as this gets incorporated in mailine kernel. You need to feel free to patch in several existing header files rather than standing alone as required in an out of tree driver. ---- From Jouni Malinen >When you look through the patch you'll likely notice the #ifdef >> NOTYET/#endif sequences surrounding portions of code from the hostap >> project. Portions of this subsystem were based on an earlier version of >> the hostap project. Those areas that weren't directly supported by the >> ipw* projects weren't ported to be completely hardware independent >> (since I don't have the hardware to test it), and so are still wrapped >> in the ifdefs. These sections mainly cover support for MASTER and WDS >> modes. We will need to take care of these areas in order to be able to call this "generic IEEE 802.11 networking stack".. I would like to be able to test replacing the upper level code in Host AP driver with this and verify that all functionality is still available. Another useful test case would be to go through what needs to be done to make this work with the madwifi driver (i.e., merge some parts of net80211 code with this and make the low-level parts of the driver use the combination for IEEE 802.11 processing). >+static void * ieee80211_ccmp_init(int key_idx) >> +{ >> + struct ieee80211_ccmp_data *priv; >> + >> + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); You do not seem to include try_module_get(THIS_MODULE) here (and matching module_put in deinit) like the version in Host AP driver is using. What is protecting the CCMP/TKIP modules from being unloaded when they are still used? --------------040200080309090603080508-- From davem@davemloft.net Thu Feb 10 17:07:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 17:07:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B17UDl026627 for ; Thu, 10 Feb 2005 17:07:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzPGR-00049l-00; Thu, 10 Feb 2005 17:06:31 -0800 Date: Thu, 10 Feb 2005 17:06:31 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Message-Id: <20050210170631.65d33139.davem@davemloft.net> In-Reply-To: <20050211.092916.50162307.yoshfuji@linux-ipv6.org> References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <20050210122523.41276d5a.davem@davemloft.net> <20050211.092916.50162307.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1B17UDl026627 X-archive-position: 1499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 293 Lines: 10 On Fri, 11 Feb 2005 09:29:16 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Okay, I'll try to solve it: > 1) catch NETDEV_CHANGEADDR > 2) (try to) add new link-local address and deprecate old one. > 3) (when DAD finishes) RS will be sent. Sounds perfect. From davem@davemloft.net Thu Feb 10 17:18:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 17:18:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B1IJrg027242 for ; Thu, 10 Feb 2005 17:18:20 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzPPo-0004EW-00; Thu, 10 Feb 2005 17:16:12 -0800 Date: Thu, 10 Feb 2005 17:16:12 -0800 From: "David S. Miller" To: Rick Jones Cc: hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050210171612.3bd2d8c6.davem@davemloft.net> In-Reply-To: <420BE1F8.1080500@hp.com> References: <0523RGW12@server5.heliogroup.fr> <420BE1F8.1080500@hp.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2139 Lines: 70 On Thu, 10 Feb 2005 14:36:40 -0800 Rick Jones wrote: > Hubert Tonneau wrote: > > It does not seem to solve the problem: > > . Linux 2.6.9 takes 15 seconds to copy 105 MB to the Mac OSX > > . Linux 2.6.10 with the TCP patch still takes 325 seconds. > > > is there a packet trace somewhere? I know what's wrong, no trace needed, Stephen's patch misses tcp_push_one() and similar. He only added the PSH bit setting to tcp_write_xmit(). Hubert, try this patch instead. ===== net/ipv4/tcp_output.c 1.77 vs edited ===== --- 1.77/net/ipv4/tcp_output.c 2005-01-18 12:23:36 -08:00 +++ edited/net/ipv4/tcp_output.c 2005-02-10 16:42:42 -08:00 @@ -408,6 +408,16 @@ sk->sk_send_head = skb; } +static inline void tcp_tso_set_push(struct sk_buff *skb) +{ + /* Force push to be on for any TSO frames to workaround + * problems with busted implementations like Mac OS-X that + * hold off socket reveive wakeups until push is seen. + */ + if (tcp_skb_pcount(skb) > 1) + TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; +} + /* Send _single_ skb sitting at the send head. This function requires * true push pending frames to setup probe timer etc. */ @@ -419,6 +429,7 @@ if (tcp_snd_test(tp, skb, cur_mss, TCP_NAGLE_PUSH)) { /* Send it out now. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { sk->sk_send_head = NULL; tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; @@ -755,6 +766,7 @@ } TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) break; @@ -1096,6 +1108,7 @@ * is still in somebody's hands, else make a clone. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, (skb_cloned(skb) ? pskb_copy(skb, GFP_ATOMIC): @@ -1668,6 +1681,7 @@ TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); if (!err) { update_send_head(sk, tp, skb); From davem@davemloft.net Thu Feb 10 17:33:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 17:33:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B1WxJ2028264 for ; Thu, 10 Feb 2005 17:33:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzPf7-0004KA-00; Thu, 10 Feb 2005 17:32:01 -0800 Date: Thu, 10 Feb 2005 17:32:01 -0800 From: "David S. Miller" To: Pablo Neira Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/4] [NETLINK] fix broken indentation in netlink.h Message-Id: <20050210173201.21da89e5.davem@davemloft.net> In-Reply-To: <420BF8C3.3050305@eurodev.net> References: <420BF8C3.3050305@eurodev.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 654 Lines: 26 On Fri, 11 Feb 2005 01:13:55 +0100 Pablo Neira wrote: > the subject says all Don't split up lines like from: extern int func(...); into: extern int func(...); That's just gross and means that when I run grep on the tree I won't see the function's return type for hits, I'll only see the args. Just keep the long declarations. Why don't you bypass all the cleanup diffs and just do the functionality change instead? When you mix whitespace and coding style cleanups with real changes, it puts your real changes at risk if we think your cleanups are ugly or bogus since you've created a patch dependency. One thing at a time. From rick.jones2@hp.com Thu Feb 10 17:40:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 17:40:26 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B1eMkU028827 for ; Thu, 10 Feb 2005 17:40:23 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id D50981C0B08F; Thu, 10 Feb 2005 17:40:21 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA18446; Thu, 10 Feb 2005 17:40:21 -0800 (PST) Message-ID: <420C0D05.6020408@hp.com> Date: Thu, 10 Feb 2005 17:40:21 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: davem@davemloft.net, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts References: <20050210002356.500401f7.akpm@osdl.org> <20050210.182225.07335127.yoshfuji@linux-ipv6.org> <20050210122523.41276d5a.davem@davemloft.net> <20050211.092916.50162307.yoshfuji@linux-ipv6.org> In-Reply-To: <20050211.092916.50162307.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 831 Lines: 20 >>I guess this causes problems for ipv6 local addresses, it >>will need to catch some callback to handle these events and >>thus adjust the local address properly. > > > Okay, I'll try to solve it: > 1) catch NETDEV_CHANGEADDR > 2) (try to) add new link-local address and deprecate old one. > 3) (when DAD finishes) RS will be sent. At present, for IPv4 if someone changes the MAC address of an interface, existing TCP connections don't really care right? The ARP caches will be updated with a new IPv4 to MAC translation and happiness and joy ensues. So, what would happen to TCP connections over IPv6 using link-local addresses? If the old address is taken away (deprecated), and a new address generated, doesn't that mean that TCP connections (using link-local addresses anyway) will fail on a MAC change? rick jones From yoshfuji@linux-ipv6.org Thu Feb 10 18:16:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 18:16:55 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B2Ghvd032199 for ; Thu, 10 Feb 2005 18:16:44 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9D6B633CC2; Fri, 11 Feb 2005 11:17:49 +0900 (JST) Date: Fri, 11 Feb 2005 11:17:48 +0900 (JST) Message-Id: <20050211.111748.15372366.yoshfuji@linux-ipv6.org> To: rick.jones2@hp.com Cc: netdev@oss.sgi.com, davem@davemloft.net, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, yoshfuji@linux-ipv6.org Subject: Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <420C0D05.6020408@hp.com> References: <20050210122523.41276d5a.davem@davemloft.net> <20050211.092916.50162307.yoshfuji@linux-ipv6.org> <420C0D05.6020408@hp.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1503 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: 674 Lines: 14 In article <420C0D05.6020408@hp.com> (at Thu, 10 Feb 2005 17:40:21 -0800), Rick Jones says: > At present, for IPv4 if someone changes the MAC address of an interface, > existing TCP connections don't really care right? The ARP caches will be > updated with a new IPv4 to MAC translation and happiness and joy ensues. > > So, what would happen to TCP connections over IPv6 using link-local addresses? > If the old address is taken away (deprecated), and a new address generated, > doesn't that mean that TCP connections (using link-local addresses anyway) will > fail on a MAC change? One thing: we won't delete it but deprecate it. --yoshfuji From tgraf@suug.ch Thu Feb 10 19:24:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:24:40 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3OX67001551 for ; Thu, 10 Feb 2005 19:24:34 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3E6D6F; Fri, 11 Feb 2005 04:24:05 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BEE1F1C0EA; Fri, 11 Feb 2005 04:24:48 +0100 (CET) Date: Fri, 11 Feb 2005 04:24:48 +0100 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH 2/4] [NETLINK] introduce netlink_check_skb function Message-ID: <20050211032448.GD31837@postel.suug.ch> References: <420BF8CB.6080005@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420BF8CB.6080005@eurodev.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1212 Lines: 33 * Pablo Neira <420BF8CB.6080005@eurodev.net> 2005-02-11 01:14 > This patch introduces a new function called netlink_check_skb that does > the sanity checkings for received messages. The patch description doesn't really match the patch itself. > ===== net/netlink/af_netlink.c 1.69 vs edited ===== > --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 > +++ edited/net/netlink/af_netlink.c 2005-02-10 00:37:57 +01:00 > @@ -1201,6 +1201,42 @@ > netlink_unicast(in_skb->sk, skb, NETLINK_CB(in_skb).pid, MSG_DONTWAIT); > } > > +/* > + * Process one packet of messages. > + * Malformed skbs with wrong lengths of messages are discarded silently. > + */ > +int netlink_process_skb(struct sk_buff *skb, > + int (*process_msg)(struct sk_buff *skb, > + struct nlmsghdr *nlh, > + int *err)) > +{ > + int err; > + struct nlmsghdr * nlh; > + > + while (skb->len >= NLMSG_SPACE(0)) { While you're at it, change that to NLMSG_LENGTH(0) or even to NLMSG_ALIGN(sizeof(*nlh)) to make it more readable. NLMSG_SPACE() represents the total size of a netlink message in the byte stream including the padding to payload in order to enforce proper alignement for successive netlink message header. From fubar@us.ibm.com Thu Feb 10 19:41:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:41:38 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3fWIZ002774 for ; Thu, 10 Feb 2005 19:41:32 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.10) with ESMTP id j1B3fQ3B016484 for ; Thu, 10 Feb 2005 22:41:26 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B3fQ6Z219794 for ; Thu, 10 Feb 2005 22:41:26 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B3fPT8030882 for ; Thu, 10 Feb 2005 22:41:26 -0500 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B3fM60030813; Thu, 10 Feb 2005 22:41:25 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B2eUNn001696; Thu, 10 Feb 2005 18:40:50 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B2eTj3001689; Thu, 10 Feb 2005 18:40:30 -0800 Message-Id: <200502110240.j1B2eTj3001689@death.nxdomain.ibm.com> To: "David S. Miller" cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts In-Reply-To: Message from "David S. Miller" of "Thu, 10 Feb 2005 12:27:45 PST." <20050210122745.16ca7cb3.davem@davemloft.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Feb 2005 18:40:29 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1213 Lines: 30 David S. Miller wrote: >On Thu, 10 Feb 2005 10:17:06 -0800 >Jay Vosburgh wrote: > >> The model used by the bridge device is probably a better way to >> go, particularly given that IPv6 link local addresses are created at >> "ifconfig up" time. > >IPv6 should catch an event when MAC addresses change, to reassign >to correct link local address. I don't think the bonding driver >needs to change at all. Except that most of the bonding internal MAC changes won't generate any events (presuming you mean a NETDEV_CHANGEADDR). The bonding driver calls the slave's dev->set_mac_address directly; the NETDEV_CHANGEADDR is generated by dev_ifsioc() (which isn't exported). Now that I'm looking for it, there are some other cases of bonding calling other dev->functions directly, e.g., change_mtu, that have wrappers that generate events; I need to fix that. Would you have a problem with putting the SIOCSIFHWADDR code from dev_ifsioc() into a separate exported function, similarly to how dev_set_mtu() is done? I can probably whip that up along with the appropriate bonding changes this evening. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From davem@davemloft.net Thu Feb 10 19:45:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:46:01 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3juNS003288 for ; Thu, 10 Feb 2005 19:45:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzRji-0004us-00; Thu, 10 Feb 2005 19:44:54 -0800 Date: Thu, 10 Feb 2005 19:44:54 -0800 From: "David S. Miller" To: Jay Vosburgh Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, ikebe.takashi@lab.ntt.co.jp, akpm@osdl.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts Message-Id: <20050210194454.015f3d98.davem@davemloft.net> In-Reply-To: <200502110240.j1B2eTj3001689@death.nxdomain.ibm.com> References: <20050210122745.16ca7cb3.davem@davemloft.net> <200502110240.j1B2eTj3001689@death.nxdomain.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 889 Lines: 18 On Thu, 10 Feb 2005 18:40:29 -0800 Jay Vosburgh wrote: > Except that most of the bonding internal MAC changes won't > generate any events (presuming you mean a NETDEV_CHANGEADDR). The > bonding driver calls the slave's dev->set_mac_address directly; the > NETDEV_CHANGEADDR is generated by dev_ifsioc() (which isn't exported). > Now that I'm looking for it, there are some other cases of bonding > calling other dev->functions directly, e.g., change_mtu, that have > wrappers that generate events; I need to fix that. > > Would you have a problem with putting the SIOCSIFHWADDR code > from dev_ifsioc() into a separate exported function, similarly to how > dev_set_mtu() is done? I can probably whip that up along with the > appropriate bonding changes this evening. That would be a great idea, as I read your first paragraph I was going to suggest exactly this. From davem@davemloft.net Thu Feb 10 19:48:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:48:40 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3mYBt003787 for ; Thu, 10 Feb 2005 19:48:34 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzRlh-0004vB-00; Thu, 10 Feb 2005 19:46:57 -0800 Date: Thu, 10 Feb 2005 19:46:57 -0800 From: "David S. Miller" To: Herbert Xu Cc: wa@almesberger.net, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050210194657.41fc2907.davem@davemloft.net> In-Reply-To: <20050210045647.GA15552@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> <20050210012304.E25338@almesberger.net> <20050210045647.GA15552@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 493 Lines: 15 On Thu, 10 Feb 2005 15:56:47 +1100 Herbert Xu wrote: > > ? If yes, is this a good idea ? > > Dave mentioned that on sparc64, atomic_inc_and_test is much more > expensive than the second variant. Actually, besides the memory barriers themselves, all variants are equally expensive. On old i386 chips, the test variants are indeed more expensive. Linus told me this and there is a note about this in the atomic_ops.txt file if you look at the current copy :-) From davem@davemloft.net Thu Feb 10 19:51:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:51:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3plX1004287 for ; Thu, 10 Feb 2005 19:51:47 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzRp4-0004vY-00; Thu, 10 Feb 2005 19:50:26 -0800 Date: Thu, 10 Feb 2005 19:50:26 -0800 From: "David S. Miller" To: Werner Almesberger Cc: herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050210195026.09b507e7.davem@davemloft.net> In-Reply-To: <20050210012304.E25338@almesberger.net> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> <20050210012304.E25338@almesberger.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1804 Lines: 53 On Thu, 10 Feb 2005 01:23:04 -0300 Werner Almesberger wrote: > David S. Miller wrote: > > Unlike the above routines, it is required that explicit memory > > barriers are performed before and after the operation. It must > > be done such that all memory operations before and after the > > atomic operation calls are strongly ordered with respect to the > > atomic operation itself. > > Hmm, given that this description will not only be read by implementers > of atomic functions, but also by users, the "explicit memory barriers" > may be confusing. Absolutely, I agree. My fingers even itched as I typed those lines in. I didn't change the wording because I couldn't come up with anything better. > In fact, I would call them "implicit", because they're hidden in the > atomic_foo functions :-) That's confusing to the implementer :-) > s/smb_/smp/ :-) Good catch, fixed in my local copy. > Do they also work for atomic_add and atomic_sub, or do we have to > fall back to smb_mb or atomic_add_return (see below) there ? Macros for the other routines don't exist simply because nobody ever had a use for them. In practice they will just work. > What happens if the operation could return a value, but the user > ignores it ? E.g. if I don't like smp_mb__*, could I just use > > atomic_inc_and_test(foo); You still get the memory barrier, whether you read the return value or not. > > These routines, like the atomic_t counter operations returning > > values, require explicit memory barrier semantics around their > > execution. > > Very confusing: the barriers aren't around the routines (that > is something the user would be doing), but around whatever does > the atomic stuff inside them. Yeah, it's the whole implicit/explicit wording issue discussed above. From davem@davemloft.net Thu Feb 10 19:52:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 19:52:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3qjV0004389 for ; Thu, 10 Feb 2005 19:52:45 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzRqL-0004vr-00; Thu, 10 Feb 2005 19:51:45 -0800 Date: Thu, 10 Feb 2005 19:51:45 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Use TASK_COMM_LEN macro. Message-Id: <20050210195145.23f2b679.davem@davemloft.net> In-Reply-To: <20050210.135916.65691686.yoshfuji@linux-ipv6.org> References: <20050210.135916.65691686.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1B3qjV0004389 X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 253 Lines: 9 On Thu, 10 Feb 2005 13:59:16 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Use TASK_COMM_LEN macro instead of magic number 16. > > Signed-off-by: Hideaki YOSHIFUJI Applied, thanks a lot. From werner@almesberger.net Thu Feb 10 20:29:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 20:29:10 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.238] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B4T5IE009120 for ; Thu, 10 Feb 2005 20:29:05 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.12.8/8.9.3) with ESMTP id j1B4RoAS018308; Thu, 10 Feb 2005 20:27:57 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id j1B4Ra401770; Fri, 11 Feb 2005 01:27:36 -0300 Date: Fri, 11 Feb 2005 01:27:36 -0300 From: Werner Almesberger To: "David S. Miller" Cc: herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050211012736.A25529@almesberger.net> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> <20050210012304.E25338@almesberger.net> <20050210195026.09b507e7.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050210195026.09b507e7.davem@davemloft.net>; from davem@davemloft.net on Thu, Feb 10, 2005 at 07:50:26PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 1369 Lines: 36 David S. Miller wrote: > Absolutely, I agree. My fingers even itched as I typed those lines > in. I didn't change the wording because I couldn't come up with > anything better. How about something like: Unlike the above routines, atomic_???_return are required to perform memory barriers [...] I think "implicit" and "explicit" here are just confusing, because you don't define them, and there's no intuitively correct meaning either. Perhaps a little warning could also be useful for the reader who wasn't paying close attention to whose role is described: Note: this means that a caller of atomic_add, etc., who needs a memory barrier before or after that call has to code the memory barrier explicitly, whereas a caller of atomic_???_return can rely on said functions to provide the barrier without further ado. For the implementor of the atomic functions, the roles are reversed. > You still get the memory barrier, whether you read the return > value or not. That might be something worth mentioning. Not that a construct is used that gcc can optimize away when nobody cares about the return value. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From dtor_core@ameritech.net Thu Feb 10 21:04:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Feb 2005 21:04:17 -0800 (PST) Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1B54DdM010617 for ; Thu, 10 Feb 2005 21:04:14 -0800 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.78.5.39 with plain) by smtp807.mail.sc5.yahoo.com with SMTP; 11 Feb 2005 05:04:13 -0000 From: Dmitry Torokhov To: "David S. Miller" Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Date: Fri, 11 Feb 2005 00:04:11 -0500 User-Agent: KMail/1.7.2 Cc: Werner Almesberger , herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050131102920.GC4170@suse.de> <20050210012304.E25338@almesberger.net> <20050210195026.09b507e7.davem@davemloft.net> In-Reply-To: <20050210195026.09b507e7.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200502110004.12133.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1B54DdM010617 X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 999 Lines: 25 On Thursday 10 February 2005 22:50, David S. Miller wrote: > > > Unlike the above routines, it is required that explicit memory > > > barriers are performed before and after the operation.  It must > > > be done such that all memory operations before and after the > > > atomic operation calls are strongly ordered with respect to the > > > atomic operation itself. > > > > Hmm, given that this description will not only be read by implementers > > of atomic functions, but also by users, the "explicit memory barriers" > > may be confusing. > > Absolutely, I agree.  My fingers even itched as I typed those lines > in.  I didn't change the wording because I couldn't come up with > anything better. What about the following: Unlike the routines above, these functions should always perform memory barriers before and after the operation in question so that all memory accesses before and after the atomic operation are strongly ordered with respect to the atomic operation itself. -- Dmitry From fubar@us.ibm.com Fri Feb 11 01:16:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:16:45 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9Ge32019782 for ; Fri, 11 Feb 2005 01:16:41 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.10) with ESMTP id j1B9GZD0007420 for ; Fri, 11 Feb 2005 04:16:35 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9GZvj190800 for ; Fri, 11 Feb 2005 04:16:35 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9GZD6023647 for ; Fri, 11 Feb 2005 04:16:35 -0500 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9GY7x023630; Fri, 11 Feb 2005 04:16:35 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9GVNn003665; Fri, 11 Feb 2005 01:16:31 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9GV6q003659; Fri, 11 Feb 2005 01:16:31 -0800 Message-Id: <200502110916.j1B9GV6q003659@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" Subject: [PATCH 2.6.11-rc3 2/5]: bonding: use wrappers to change mtu and MAC X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:16:31 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4918 Lines: 138 This updates the bonding driver to use the dev_set_mtu() and dev_set_mac_address() wrapper functions. Signed-off-by: Jay Vosburgh Index: linux-2611-rc3/drivers/net/bonding/bond_main.c =================================================================== RCS file: /sda7/CVS/linux-2611-rc3/linux-2611-rc3/drivers/net/bonding/bond_main.c,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 bond_main.c --- linux-2611-rc3/drivers/net/bonding/bond_main.c 11 Feb 2005 04:50:54 -0000 1.1.1.1 +++ linux-2611-rc3/drivers/net/bonding/bond_main.c 11 Feb 2005 06:20:08 -0000 @@ -1719,7 +1719,7 @@ */ memcpy(addr.sa_data, bond_dev->dev_addr, bond_dev->addr_len); addr.sa_family = slave_dev->type; - res = slave_dev->set_mac_address(slave_dev, &addr); + res = dev_set_mac_address(slave_dev, &addr); if (res) { dprintk("Error %d calling set_mac_address\n", res); goto err_free; @@ -1991,7 +1991,7 @@ err_restore_mac: memcpy(addr.sa_data, new_slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); err_free: kfree(new_slave); @@ -2171,7 +2171,7 @@ /* restore original ("permanent") mac address */ memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); } /* restore the original state of the @@ -2262,7 +2262,7 @@ /* restore original ("permanent") mac address*/ memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); } /* restore the original state of the IFF_NOARP flag that might have @@ -3898,12 +3898,7 @@ bond_for_each_slave(bond, slave, i) { dprintk("s %p s->p %p c_m %p\n", slave, slave->prev, slave->dev->change_mtu); - if (slave->dev->change_mtu) { - res = slave->dev->change_mtu(slave->dev, new_mtu); - } else { - slave->dev->mtu = new_mtu; - res = 0; - } + res = dev_set_mtu(slave->dev, new_mtu); if (res) { /* If we failed to set the slave's mtu to the new value @@ -3929,14 +3924,10 @@ bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { int tmp_res; - if (slave->dev->change_mtu) { - tmp_res = slave->dev->change_mtu(slave->dev, bond_dev->mtu); - if (tmp_res) { - dprintk("unwind err %d dev %s\n", tmp_res, - slave->dev->name); - } - } else { - slave->dev->mtu = bond_dev->mtu; + tmp_res = dev_set_mtu(slave->dev, bond_dev->mtu); + if (tmp_res) { + dprintk("unwind err %d dev %s\n", tmp_res, + slave->dev->name); } } @@ -3988,7 +3979,7 @@ goto unwind; } - res = slave->dev->set_mac_address(slave->dev, addr); + res = dev_set_mac_address(slave->dev, addr); if (res) { /* TODO: consider downing the slave * and retry ? @@ -4014,7 +4005,7 @@ bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { int tmp_res; - tmp_res = slave->dev->set_mac_address(slave->dev, &tmp_sa); + tmp_res = dev_set_mac_address(slave->dev, &tmp_sa); if (tmp_res) { dprintk("unwind err %d dev %s\n", tmp_res, slave->dev->name); Index: linux-2611-rc3/drivers/net/bonding/bond_alb.c =================================================================== RCS file: /sda7/CVS/linux-2611-rc3/linux-2611-rc3/drivers/net/bonding/bond_alb.c,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 bond_alb.c --- linux-2611-rc3/drivers/net/bonding/bond_alb.c 11 Feb 2005 04:50:54 -0000 1.1.1.1 +++ linux-2611-rc3/drivers/net/bonding/bond_alb.c 11 Feb 2005 06:16:32 -0000 @@ -954,9 +954,9 @@ /* each slave will receive packets destined to a different mac */ memcpy(s_addr.sa_data, addr, dev->addr_len); s_addr.sa_family = dev->type; - if (dev->set_mac_address(dev, &s_addr)) { + if (dev_set_mac_address(dev, &s_addr)) { printk(KERN_ERR DRV_NAME - ": Error: dev->set_mac_address of dev %s failed! ALB " + ": Error: dev_set_mac_address of dev %s failed! ALB " "mode requires that the base driver support setting " "the hw address also when the network device's " "interface is open\n", @@ -1209,7 +1209,7 @@ /* save net_device's current hw address */ memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - res = slave->dev->set_mac_address(slave->dev, addr); + res = dev_set_mac_address(slave->dev, addr); /* restore net_device's hw address */ memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); @@ -1229,7 +1229,7 @@ stop_at = slave; bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - slave->dev->set_mac_address(slave->dev, &sa); + dev_set_mac_address(slave->dev, &sa); memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); } From fubar@us.ibm.com Fri Feb 11 01:16:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:16:07 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9G3w0019485 for ; Fri, 11 Feb 2005 01:16:03 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1B9FviK619106 for ; Fri, 11 Feb 2005 04:15:57 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9Fu3c414412 for ; Fri, 11 Feb 2005 02:15:56 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9FurU004328 for ; Fri, 11 Feb 2005 02:15:56 -0700 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9FuR4004318; Fri, 11 Feb 2005 02:15:56 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9FoNn003652; Fri, 11 Feb 2005 01:15:50 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9Fo2v003646; Fri, 11 Feb 2005 01:15:50 -0800 Message-Id: <200502110915.j1B9Fo2v003646@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" Subject: [PATCH 2.6.11-rc3 1/5]: net/core: move set MAC into separate function X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:15:50 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2702 Lines: 82 This moves the SIOCSIFHWADDR code from dev_ifsioc() into a separate new function, dev_set_mac_address(). This provides a single entry point for all callers performing MAC address changes. Signed-off-by: Jay Vosburgh Index: linux-2611-rc3/net/core/dev.c =================================================================== RCS file: /sda7/CVS/linux-2611-rc3/linux-2611-rc3/net/core/dev.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -u -r1.1.1.1 -r1.2 --- linux-2611-rc3/net/core/dev.c 11 Feb 2005 04:50:49 -0000 1.1.1.1 +++ linux-2611-rc3/net/core/dev.c 11 Feb 2005 05:54:32 -0000 1.2 @@ -2299,6 +2299,21 @@ return err; } +int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa) +{ + int err; + + if (!dev->set_mac_address) + return -EOPNOTSUPP; + if (sa->sa_family != dev->type) + return -EINVAL; + if (!netif_device_present(dev)) + return -ENODEV; + err = dev->set_mac_address(dev, sa); + if (!err) + notifier_call_chain(&netdev_chain, NETDEV_CHANGEADDR, dev); + return err; +} /* * Perform the SIOCxIFxxx calls. @@ -2345,17 +2360,7 @@ return 0; case SIOCSIFHWADDR: - if (!dev->set_mac_address) - return -EOPNOTSUPP; - if (ifr->ifr_hwaddr.sa_family != dev->type) - return -EINVAL; - if (!netif_device_present(dev)) - return -ENODEV; - err = dev->set_mac_address(dev, &ifr->ifr_hwaddr); - if (!err) - notifier_call_chain(&netdev_chain, - NETDEV_CHANGEADDR, dev); - return err; + return dev_set_mac_address(dev, &ifr->ifr_hwaddr); case SIOCSIFHWBROADCAST: if (ifr->ifr_hwaddr.sa_family != dev->type) @@ -3322,6 +3327,7 @@ EXPORT_SYMBOL(dev_set_promiscuity); EXPORT_SYMBOL(dev_change_flags); EXPORT_SYMBOL(dev_set_mtu); +EXPORT_SYMBOL(dev_set_mac_address); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); EXPORT_SYMBOL(netdev_set_master); Index: linux-2611-rc3/include/linux/netdevice.h =================================================================== RCS file: /sda7/CVS/linux-2611-rc3/linux-2611-rc3/include/linux/netdevice.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -u -r1.1.1.1 -r1.2 --- linux-2611-rc3/include/linux/netdevice.h 11 Feb 2005 04:51:23 -0000 1.1.1.1 +++ linux-2611-rc3/include/linux/netdevice.h 11 Feb 2005 05:54:25 -0000 1.2 @@ -678,6 +678,8 @@ extern int dev_change_flags(struct net_device *, unsigned); extern int dev_change_name(struct net_device *, char *); extern int dev_set_mtu(struct net_device *, int); +extern int dev_set_mac_address(struct net_device *, + struct sockaddr *); extern void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev); extern void dev_init(void); From fubar@us.ibm.com Fri Feb 11 01:15:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:15:48 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9FbFX019432 for ; Fri, 11 Feb 2005 01:15:44 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.10) with ESMTP id j1B9FWE1017367 for ; Fri, 11 Feb 2005 04:15:32 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9FWvj187184 for ; Fri, 11 Feb 2005 04:15:32 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9FVLG022081 for ; Fri, 11 Feb 2005 04:15:32 -0500 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9FVQ4022061; Fri, 11 Feb 2005 04:15:31 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9FLNn003640; Fri, 11 Feb 2005 01:15:23 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9FKC0003633; Fri, 11 Feb 2005 01:15:20 -0800 Message-Id: <200502110915.j1B9FKC0003633@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" Subject: [PATCH 2.6.11-rc3 0/5] bonding: bonding and related updates X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:15:19 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 541 Lines: 16 Some bonding updates. The first two implement the dev_set_mac_address business discussed earlier on netdev. The rest are some bonding documentation and message updates unrelated to the MAC address changes. 1/5 Move SIOCSIFHWADDR code into new function 2/5 Update bonding to use previous as well as dev_set_mtu 3/5 Fix a misleading warning message in bonding 4/5 Update to Kconfig bonding description 5/5 Update/rewrite of Documentation/networking/bonding.txt -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From fubar@us.ibm.com Fri Feb 11 01:17:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:17:36 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9HWlx020459 for ; Fri, 11 Feb 2005 01:17:32 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1B9HQCI192770 for ; Fri, 11 Feb 2005 04:17:26 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9HQ6H202904 for ; Fri, 11 Feb 2005 02:17:26 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9HP9b006244 for ; Fri, 11 Feb 2005 02:17:26 -0700 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9HPu9006229; Fri, 11 Feb 2005 02:17:25 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9HMNn003678; Fri, 11 Feb 2005 01:17:22 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9HMtN003672; Fri, 11 Feb 2005 01:17:22 -0800 Message-Id: <200502110917.j1B9HMtN003672@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" Subject: [PATCH 2.6.11-rc3 3/5] bonding: change misleading warning X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:17:22 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1169 Lines: 26 This updates a warning message that the bonding driver issues when some modes are unable to determine the link speed of a slave device. The old message led users to believe that bonding was slowing their gigabit devices to 100 Mb/sec. Signed-off-by: Jay Vosburgh Index: linux-2611-rc3/drivers/net/bonding/bond_main.c =================================================================== RCS file: /sda7/CVS/linux-2611-rc3/linux-2611-rc3/drivers/net/bonding/bond_main.c,v retrieving revision 1.2 diff -u -u -r1.2 bond_main.c --- linux-2611-rc3/drivers/net/bonding/bond_main.c 11 Feb 2005 06:57:08 -0000 1.2 +++ linux-2611-rc3/drivers/net/bonding/bond_main.c 11 Feb 2005 07:00:02 -0000 @@ -1849,8 +1849,8 @@ if (bond_update_speed_duplex(new_slave) && (new_slave->link != BOND_LINK_DOWN)) { printk(KERN_WARNING DRV_NAME - ": Warning: failed to get speed/duplex from %s, speed " - "forced to 100Mbps, duplex forced to Full.\n", + ": Warning: failed to get speed and duplex from %s, " + "assumed to be 100Mb/sec and Full.\n", new_slave->dev->name); if (bond->params.mode == BOND_MODE_8023AD) { From fubar@us.ibm.com Fri Feb 11 01:17:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:17:58 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9HqTx020607 for ; Fri, 11 Feb 2005 01:17:52 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1B9Hk6L130786 for ; Fri, 11 Feb 2005 04:17:46 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9Hk3c453410 for ; Fri, 11 Feb 2005 02:17:46 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9Hk5X006771 for ; Fri, 11 Feb 2005 02:17:46 -0700 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9Hjv6006748; Fri, 11 Feb 2005 02:17:45 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9HgNn003690; Fri, 11 Feb 2005 01:17:42 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9HgGi003684; Fri, 11 Feb 2005 01:17:42 -0800 Message-Id: <200502110917.j1B9HgGi003684@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" , Mitch Williams Subject: [PATCH 2.6.11-rc3 4/5] bonding: Update kconfig description X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:17:42 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1729 Lines: 36 This patch updates the very-outdated Kconfig description for bonding. Users reading the help text in menuconfig or xconfig would see text that implied that bonding only supports static link aggregation, and required a specific switch to make it work. The new description mentions multiple bonding modes and points the user to the bonding.txt documentation. Signed-off-by: Mitch Williams Signed-off-by: Jay Vosburgh diff -urpN -X dontdiff linux-2.6.10-clean/drivers/net/Kconfig linux-2.6.10/drivers/net/Kconfig --- linux-2.6.10-clean/drivers/net/Kconfig 2004-12-24 13:35:25.000000000 -0800 +++ linux-2.6.10/drivers/net/Kconfig 2005-02-08 14:05:06.000000000 -0800 @@ -47,16 +47,13 @@ config BONDING ---help--- Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet Channels together. This is called 'Etherchannel' by Cisco, - 'Trunking' by Sun, and 'Bonding' in Linux. + 'Trunking' by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux. - If you have two Ethernet connections to some other computer, you can - make them behave like one double speed connection using this driver. - Naturally, this has to be supported at the other end as well, either - with a similar Bonding Linux driver, a Cisco 5500 switch or a - SunTrunking SunSoft driver. - - This is similar to the EQL driver, but it merges Ethernet segments - instead of serial lines. + The driver supports multiple bonding modes to allow for both high + perfomance and high availability operation. + + Refer to for more + information. To compile this driver as a module, choose M here: the module will be called bonding. From fubar@us.ibm.com Fri Feb 11 01:18:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:19:15 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9Ivq2021672 for ; Fri, 11 Feb 2005 01:18:58 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.10) with ESMTP id j1B9Iokv027722 for ; Fri, 11 Feb 2005 04:18:50 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1B9Io6Z266786 for ; Fri, 11 Feb 2005 04:18:50 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9InT3027445 for ; Fri, 11 Feb 2005 04:18:50 -0500 Received: from death.nxdomain.ibm.com (sig-9-49-136-239.mts.ibm.com [9.49.136.239]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1B9IjUb027389; Fri, 11 Feb 2005 04:18:45 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1B9IgNn003702; Fri, 11 Feb 2005 01:18:42 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1B9If7r003696; Fri, 11 Feb 2005 01:18:41 -0800 Message-Id: <200502110918.j1B9If7r003696@death.nxdomain.ibm.com> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Cc: "David S. Miller" Subject: [PATCH 2.6.11-rc3 5/5] bonding: Update/rewrite bonding.txt X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 01:18:41 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 104717 Lines: 2331 This is a complete overhaul of the bonding.txt documentation. Signed-off-by: Jay Vosburgh --- linux-2611-rc3/Documentation/networking/bonding.txt 2004-04-05 11:55:06.000000000 -0700 +++ linux-2611-rc3-docupdate/Documentation/networking/bonding.txt 2005-02-11 01:44:37.000000000 -0800 @@ -1,5 +1,5 @@ - Linux Ethernet Bonding Driver mini-howto + Linux Ethernet Bonding Driver HOWTO Initial release : Thomas Davis Corrections, HA extensions : 2000/10/03-15 : @@ -9,8 +9,11 @@ - Janice Girouard - Jay Vosburgh +Reorganized and updated Feb 2005 by Jay Vosburgh + Note : ------ + The bonding driver originally came from Donald Becker's beowulf patches for kernel 2.0. It has changed quite a bit since, and the original tools from extreme-linux and beowulf sites will not work with this version of the driver. @@ -18,218 +21,190 @@ For new versions of the driver, patches for older kernels and the updated userspace tools, please follow the links at the end of this file. - Table of Contents ================= -Installation -Bond Configuration -Module Parameters -Configuring Multiple Bonds -Switch Configuration -Verifying Bond Configuration -Frequently Asked Questions -High Availability -Promiscuous Sniffing notes -8021q VLAN support -Limitations -Resources and Links - - -Installation -============ - -1) Build kernel with the bonding driver ---------------------------------------- -For the latest version of the bonding driver, use kernel 2.4.12 or above -(otherwise you will need to apply a patch). - -Configure kernel with `make menuconfig/xconfig/config', and select "Bonding -driver support" in the "Network device support" section. It is recommended -to configure the driver as module since it is currently the only way to -pass parameters to the driver and configure more than one bonding device. - -Build and install the new kernel and modules. - -2) Get and install the userspace tools --------------------------------------- -This version of the bonding driver requires updated ifenslave program. The -original one from extreme-linux and beowulf will not work. Kernels 2.4.12 -and above include the updated version of ifenslave.c in -Documentation/networking directory. For older kernels, please follow the -links at the end of this file. - -IMPORTANT!!! If you are running on Redhat 7.1 or greater, you need -to be careful because /usr/include/linux is no longer a symbolic link -to /usr/src/linux/include/linux. If you build ifenslave while this is -true, ifenslave will appear to succeed but your bond won't work. The purpose -of the -I option on the ifenslave compile line is to make sure it uses -/usr/src/linux/include/linux/if_bonding.h instead of the version from -/usr/include/linux. - -To install ifenslave.c, do: - # gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave - # cp ifenslave /sbin/ifenslave +1. Bonding Driver Installation +2. Bonding Driver Options -Bond Configuration -================== +3. Configuring Bonding Devices +3.1 Configuration with sysconfig support +3.2 Configuration with initscripts support +3.3 Configuring Bonding Manually +3.4 Configuring Multiple Bonds -You will need to add at least the following line to /etc/modprobe.conf -so the bonding driver will automatically load when the bond0 interface is -configured. Refer to the modprobe.conf manual page for specific modprobe.conf -syntax details. The Module Parameters section of this document describes each -bonding driver parameter. - - alias bond0 bonding - -Use standard distribution techniques to define the bond0 network interface. For -example, on modern Red Hat distributions, create an ifcfg-bond0 file in -the /etc/sysconfig/network-scripts directory that resembles the following: +5. Querying Bonding Configuration +5.1 Bonding Configuration +5.2 Network Configuration -DEVICE=bond0 -IPADDR=192.168.1.1 -NETMASK=255.255.255.0 -NETWORK=192.168.1.0 -BROADCAST=192.168.1.255 -ONBOOT=yes -BOOTPROTO=none -USERCTL=no +6. Switch Configuration -(use appropriate values for your network above) +7. 802.1q VLAN Support -All interfaces that are part of a bond should have SLAVE and MASTER -definitions. For example, in the case of Red Hat, if you wish to make eth0 and -eth1 a part of the bonding interface bond0, their config files (ifcfg-eth0 and -ifcfg-eth1) should resemble the following: +8. Link Monitoring +8.1 ARP Monitor Operation +8.2 Configuring Multiple ARP Targets +8.3 MII Monitor Operation -DEVICE=eth0 -USERCTL=no -ONBOOT=yes -MASTER=bond0 -SLAVE=yes -BOOTPROTO=none +9. Potential Trouble Sources +9.1 Adventures in Routing +9.2 Ethernet Device Renaming +9.3 Painfully Slow Or No Failed Link Detection By Miimon -Use DEVICE=eth1 in the ifcfg-eth1 config file. If you configure a second -bonding interface (bond1), use MASTER=bond1 in the config file to make the -network interface be a slave of bond1. - -Restart the networking subsystem or just bring up the bonding device if your -administration tools allow it. Otherwise, reboot. On Red Hat distros you can -issue `ifup bond0' or `/etc/rc.d/init.d/network restart'. - -If the administration tools of your distribution do not support -master/slave notation in configuring network interfaces, you will need to -manually configure the bonding device with the following commands: - - # /sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0 \ - broadcast 192.168.1.255 up - - # /sbin/ifenslave bond0 eth0 - # /sbin/ifenslave bond0 eth1 - -(use appropriate values for your network above) - -You can then create a script containing these commands and place it in the -appropriate rc directory. - -If you specifically need all network drivers loaded before the bonding driver, -adding the following line to modprobe.conf will cause the network driver for -eth0 and eth1 to be loaded before the bonding driver. - -install bond0 /sbin/modprobe -a eth0 eth1 && /sbin/modprobe bonding - -Be careful not to reference bond0 itself at the end of the line, or modprobe -will die in an endless recursive loop. - -If running SNMP agents, the bonding driver should be loaded before any network -drivers participating in a bond. This requirement is due to the the interface -index (ipAdEntIfIndex) being associated to the first interface found with a -given IP address. That is, there is only one ipAdEntIfIndex for each IP -address. For example, if eth0 and eth1 are slaves of bond0 and the driver for -eth0 is loaded before the bonding driver, the interface for the IP address -will be associated with the eth0 interface. This configuration is shown below, -the IP address 192.168.1.1 has an interface index of 2 which indexes to eth0 -in the ifDescr table (ifDescr.2). +10. SNMP agents - interfaces.ifTable.ifEntry.ifDescr.1 = lo - interfaces.ifTable.ifEntry.ifDescr.2 = eth0 - interfaces.ifTable.ifEntry.ifDescr.3 = eth1 - interfaces.ifTable.ifEntry.ifDescr.4 = eth2 - interfaces.ifTable.ifEntry.ifDescr.5 = eth3 - interfaces.ifTable.ifEntry.ifDescr.6 = bond0 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 +11. Promiscuous mode -This problem is avoided by loading the bonding driver before any network -drivers participating in a bond. Below is an example of loading the bonding -driver first, the IP address 192.168.1.1 is correctly associated with -ifDescr.2. +12. High Availability Information +12.1 High Availability in a Single Switch Topology +12.1.1 Bonding Mode Selection for Single Switch Topology +12.1.2 Link Monitoring for Single Switch Topology +12.2 High Availability in a Multiple Switch Topology +12.2.1 Bonding Mode Selection for Multiple Switch Topology +12.2.2 Link Monitoring for Multiple Switch Topology +12.3 Switch Behavior Issues for High Availability - interfaces.ifTable.ifEntry.ifDescr.1 = lo - interfaces.ifTable.ifEntry.ifDescr.2 = bond0 - interfaces.ifTable.ifEntry.ifDescr.3 = eth0 - interfaces.ifTable.ifEntry.ifDescr.4 = eth1 - interfaces.ifTable.ifEntry.ifDescr.5 = eth2 - interfaces.ifTable.ifEntry.ifDescr.6 = eth3 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 +13. Hardware Specific Considerations +13.1 IBM BladeCenter -While some distributions may not report the interface name in ifDescr, -the association between the IP address and IfIndex remains and SNMP -functions such as Interface_Scan_Next will report that association. +14. Frequently Asked Questions +15. Resources and Links -Module Parameters -================= -Optional parameters for the bonding driver can be supplied as command line -arguments to the insmod command. Typically, these parameters are specified in -the file /etc/modprobe.conf (see the manual page for modprobe.conf). The -available bonding driver parameters are listed below. If a parameter is not -specified the default value is used. When initially configuring a bond, it -is recommended "tail -f /var/log/messages" be run in a separate window to -watch for bonding driver error messages. - -It is critical that either the miimon or arp_interval and arp_ip_target -parameters be specified, otherwise serious network degradation will occur -during link failures. +1. Bonding Driver Installation +============================== + + Most popular distro kernels ship with the bonding driver +already available as a module and the ifenslave user level control +program installed and ready for use. If your distro does not, or you +have need to compile bonding from source (e.g., configuring and +installing a mainline kernel from kernel.org), you'll need to perform +the following steps: + +1.1 Configure and build the kernel with bonding +----------------------------------------------- + + The latest version of the bonding driver is available in the +drivers/net/bonding subdirectory of the most recent kernel source +(which is available on http://kernel.org). + + Prior to the 2.4.11 kernel, the bonding driver was maintained +largely outside the kernel tree; patches for some earlier kernels are +available on the bonding sourceforge site, although those patches are +still several years out of date. Most users will want to use either +the most recent kernel from kernel.org or whatever kernel came with +their distro. + + Configure kernel with "make menuconfig" (or "make xconfig" or +"make config"), then select "Bonding driver support" in the "Network +device support" section. It is recommended that you configure the +driver as module since it is currently the only way to pass parameters +to the driver or configure more than one bonding device. + + Build and install the new kernel and modules, then proceed to +step 2. + +1.2 Install ifenslave Control Utility +------------------------------------- + + The ifenslave user level control program is included in the +kernel source tree, in the file Documentation/networking/ifenslave.c. +It is generally recommended that you use the ifenslave that +corresponds to the kernel that you are using (either from the same +source tree or supplied with the distro), however, ifenslave +executables from older kernels should function (but features newer +than the ifenslave release are not supported). Running an ifenslave +that is newer than the kernel is not supported, and may or may not +work. + + To install ifenslave, do the following: + +# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave +# cp ifenslave /sbin/ifenslave + + If your kernel source is not in "/usr/src/linux," then replace +"/usr/src/linux/include" in the above with the location of your kernel +source include directory. + + You may wish to back up any existing /sbin/ifenslave, or, for +testing or informal use, tag the ifenslave to the kernel version +(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10). + +IMPORTANT NOTE: + + If you omit the "-I" or specify an incorrect directory, you +may end up with an ifenslave that is incompatible with the kernel +you're trying to build it for. Some distros (e.g., Red Hat from 7.1 +onwards) do not have /usr/include/linux symbolically linked to the +default kernel source include directory. + + +2. Bonding Driver Options +========================= + + Options for the bonding driver are supplied as parameters to +the bonding module at load time. They may be given as command line +arguments to the insmod or modprobe command, but are usually specified +in either the /etc/modprobe.conf configuration file, or in a +distro-specific configuration file (some of which are detailed in the +next section). + + The available bonding driver parameters are listed below. If a +parameter is not specified the default value is used. When initially +configuring a bond, it is recommended "tail -f /var/log/messages" be +run in a separate window to watch for bonding driver error messages. + + It is critical that either the miimon or arp_interval and +arp_ip_target parameters be specified, otherwise serious network +degradation will occur during link failures. Very few devices do not +support at least miimon, so there is really no reason not to use it. + + Options with textual values will accept either the text name + or, for backwards compatibility, the option value. E.g., + "mode=802.3ad" and "mode=4" set the same mode. + + The parameters are as follows: arp_interval - Specifies the ARP monitoring frequency in milli-seconds. - If ARP monitoring is used in a load-balancing mode (mode 0 or 2), the - switch should be configured in a mode that evenly distributes packets - across all links - such as round-robin. If the switch is configured to - distribute the packets in an XOR fashion, all replies from the ARP - targets will be received on the same link which could cause the other - team members to fail. ARP monitoring should not be used in conjunction - with miimon. A value of 0 disables ARP monitoring. The default value - is 0. + Specifies the ARP monitoring frequency in milli-seconds. If + ARP monitoring is used in a load-balancing mode (mode 0 or 2), + the switch should be configured in a mode that evenly + distributes packets across all links - such as round-robin. If + the switch is configured to distribute the packets in an XOR + fashion, all replies from the ARP targets will be received on + the same link which could cause the other team members to + fail. ARP monitoring should not be used in conjunction with + miimon. A value of 0 disables ARP monitoring. The default + value is 0. arp_ip_target - Specifies the ip addresses to use when arp_interval is > 0. These - are the targets of the ARP request sent to determine the health of - the link to the targets. Specify these values in ddd.ddd.ddd.ddd - format. Multiple ip adresses must be seperated by a comma. At least - one ip address needs to be given for ARP monitoring to work. The - maximum number of targets that can be specified is set at 16. + Specifies the ip addresses to use when arp_interval is > 0. + These are the targets of the ARP request sent to determine the + health of the link to the targets. Specify these values in + ddd.ddd.ddd.ddd format. Multiple ip adresses must be + seperated by a comma. At least one IP address must be given + for ARP monitoring to function. The maximum number of targets + that can be specified is 16. The default value is no IP + addresses. downdelay - Specifies the delay time in milli-seconds to disable a link after a - link failure has been detected. This should be a multiple of miimon - value, otherwise the value will be rounded. The default value is 0. + Specifies the time, in milliseconds, to wait before disabling + a slave after a link failure has been detected. This option + is only valid for the miimon link monitor. The downdelay + value should be a multiple of the miimon value; if not, it + will be rounded down to the nearest multiple. The default + value is 0. lacp_rate - Option specifying the rate in which we'll ask our link partner to - transmit LACPDU packets in 802.3ad mode. Possible values are: + Option specifying the rate in which we'll ask our link partner + to transmit LACPDU packets in 802.3ad mode. Possible values + are: slow or 0 Request partner to transmit LACPDUs every 30 seconds (default) @@ -246,69 +221,76 @@ miimon - Specifies the frequency in milli-seconds that MII link monitoring - will occur. A value of zero disables MII link monitoring. A value - of 100 is a good starting point. See High Availability section for - additional information. The default value is 0. + Specifies the frequency in milli-seconds that MII link + monitoring will occur. A value of zero disables MII link + monitoring. A value of 100 is a good starting point. The + use_carrier option, below, affects how the link state is + determined. See the High Availability section for additional + information. The default value is 0. mode Specifies one of the bonding policies. The default is - round-robin (balance-rr). Possible values are (you can use - either the text or numeric option): + balance-rr (round robin). Possible values are: balance-rr or 0 - Round-robin policy: Transmit in a sequential order - from the first available slave through the last. This - mode provides load balancing and fault tolerance. + Round-robin policy: Transmit packets in sequential + order from the first available slave through the + last. This mode provides load balancing and fault + tolerance. active-backup or 1 Active-backup policy: Only one slave in the bond is - active. A different slave becomes active if, and only - if, the active slave fails. The bond's MAC address is + active. A different slave becomes active if, and only + if, the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides - fault tolerance. + fault tolerance. The primary option affects the + behavior of this mode. balance-xor or 2 XOR policy: Transmit based on [(source MAC address - XOR'd with destination MAC address) modula slave - count]. This selects the same slave for each - destination MAC address. This mode provides load + XOR'd with destination MAC address) modulo slave + count]. This selects the same slave for each + destination MAC address. This mode provides load balancing and fault tolerance. broadcast or 3 Broadcast policy: transmits everything on all slave - interfaces. This mode provides fault tolerance. + interfaces. This mode provides fault tolerance. 802.3ad or 4 - IEEE 802.3ad Dynamic link aggregation. Creates aggregation - groups that share the same speed and duplex settings. - Transmits and receives on all slaves in the active - aggregator. + IEEE 802.3ad Dynamic link aggregation. Creates + aggregation groups that share the same speed and + duplex settings. Utilizes all slaves in the active + aggregator according to the 802.3ad specification. Pre-requisites: - 1. Ethtool support in the base drivers for retrieving the - speed and duplex of each slave. + 1. Ethtool support in the base drivers for retrieving + the speed and duplex of each slave. 2. A switch that supports IEEE 802.3ad Dynamic link aggregation. + Most switches will require some type of configuration + to enable 802.3ad mode. + balance-tlb or 5 - Adaptive transmit load balancing: channel bonding that does - not require any special switch support. The outgoing - traffic is distributed according to the current load - (computed relative to the speed) on each slave. Incoming - traffic is received by the current slave. If the receiving - slave fails, another slave takes over the MAC address of - the failed receiving slave. + Adaptive transmit load balancing: channel bonding that + does not require any special switch support. The + outgoing traffic is distributed according to the + current load (computed relative to the speed) on each + slave. Incoming traffic is received by the current + slave. If the receiving slave fails, another slave + takes over the MAC address of the failed receiving + slave. Prerequisite: @@ -317,205 +299,452 @@ balance-alb or 6 - Adaptive load balancing: includes balance-tlb + receive - load balancing (rlb) for IPV4 traffic and does not require - any special switch support. The receive load balancing is - achieved by ARP negotiation. The bonding driver intercepts - the ARP Replies sent by the server on their way out and - overwrites the src hw address with the unique hw address of - one of the slaves in the bond such that different clients - use different hw addresses for the server. - - Receive traffic from connections created by the server is - also balanced. When the server sends an ARP Request the - bonding driver copies and saves the client's IP information - from the ARP. When the ARP Reply arrives from the client, - its hw address is retrieved and the bonding driver - initiates an ARP reply to this client assigning it to one - of the slaves in the bond. A problematic outcome of using - ARP negotiation for balancing is that each time that an ARP - request is broadcasted it uses the hw address of the - bond. Hence, clients learn the hw address of the bond and - the balancing of receive traffic collapses to the current - salve. This is handled by sending updates (ARP Replies) to - all the clients with their assigned hw address such that - the traffic is redistributed. Receive traffic is also - redistributed when a new slave is added to the bond and - when an inactive slave is re-activated. The receive load is - distributed sequentially (round robin) among the group of - highest speed slaves in the bond. - - When a link is reconnected or a new slave joins the bond - the receive traffic is redistributed among all active - slaves in the bond by intiating ARP Replies with the - selected mac address to each of the clients. The updelay - modeprobe parameter must be set to a value equal or greater - than the switch's forwarding delay so that the ARP Replies - sent to the clients will not be blocked by the switch. + Adaptive load balancing: includes balance-tlb plus + receive load balancing (rlb) for IPV4 traffic, and + does not require any special switch support. The + receive load balancing is achieved by ARP negotiation. + The bonding driver intercepts the ARP Replies sent by + the local system on their way out and overwrites the + source hardware address with the unique hardware + address of one of the slaves in the bond such that + different peers use different hardware addresses for + the server. + + Receive traffic from connections created by the server + is also balanced. When the local system sends an ARP + Request the bonding driver copies and saves the peer's + IP information from the ARP packet. When the ARP + Reply arrives from the peer, its hardware address is + retrieved and the bonding driver initiates an ARP + reply to this peer assigning it to one of the slaves + in the bond. A problematic outcome of using ARP + negotiation for balancing is that each time that an + ARP request is broadcast it uses the hardware address + of the bond. Hence, peers learn the hardware address + of the bond and the balancing of receive traffic + collapses to the current slave. This is handled by + sending updates (ARP Replies) to all the peers with + their individually assigned hardware address such that + the traffic is redistributed. Receive traffic is also + redistributed when a new slave is added to the bond + and when an inactive slave is re-activated. The + receive load is distributed sequentially (round robin) + among the group of highest speed slaves in the bond. + + When a link is reconnected or a new slave joins the + bond the receive traffic is redistributed among all + active slaves in the bond by intiating ARP Replies + with the selected mac address to each of the + clients. The updelay parameter (detailed below) must + be set to a value equal or greater than the switch's + forwarding delay so that the ARP Replies sent to the + peers will not be blocked by the switch. Prerequisites: - 1. Ethtool support in the base drivers for retrieving the - speed of each slave. + 1. Ethtool support in the base drivers for retrieving + the speed of each slave. - 2. Base driver support for setting the hw address of a - device also when it is open. This is required so that there - will always be one slave in the team using the bond hw - address (the curr_active_slave) while having a unique hw - address for each slave in the bond. If the curr_active_slave - fails it's hw address is swapped with the new curr_active_slave - that was chosen. + 2. Base driver support for setting the hardware + address of a device while it is open. This is + required so that there will always be one slave in the + team using the bond hardware address (the + curr_active_slave) while having a unique hardware + address for each slave in the bond. If the + curr_active_slave fails its hardware address is + swapped with the new curr_active_slave that was + chosen. primary - A string (eth0, eth2, etc) to equate to a primary device. If this - value is entered, and the device is on-line, it will be used first - as the output media. Only when this device is off-line, will - alternate devices be used. Otherwise, once a failover is detected - and a new default output is chosen, it will remain the output media - until it too fails. This is useful when one slave was preferred - over another, i.e. when one slave is 1000Mbps and another is - 100Mbps. If the 1000Mbps slave fails and is later restored, it may - be preferred the faster slave gracefully become the active slave - - without deliberately failing the 100Mbps slave. Specifying a - primary is only valid in active-backup mode. + A string (eth0, eth2, etc) specifying which slave is the + primary device. The specified device will always be the + active slave while it is available. Only when the primary is + off-line will alternate devices be used. This is useful when + one slave is preferred over another, e.g., when one slave has + higher throughput than another. + + The primary option is only valid for active-backup mode. updelay - Specifies the delay time in milli-seconds to enable a link after a - link up status has been detected. This should be a multiple of miimon - value, otherwise the value will be rounded. The default value is 0. + Specifies the time, in milliseconds, to wait before enabling a + slave after a link recovery has been detected. This option is + only valid for the miimon link monitor. The updelay value + should be a multiple of the miimon value; if not, it will be + rounded down to the nearest multiple. The default value is 0. use_carrier - Specifies whether or not miimon should use MII or ETHTOOL - ioctls vs. netif_carrier_ok() to determine the link status. - The MII or ETHTOOL ioctls are less efficient and utilize a - deprecated calling sequence within the kernel. The - netif_carrier_ok() relies on the device driver to maintain its - state with netif_carrier_on/off; at this writing, most, but - not all, device drivers support this facility. - - If bonding insists that the link is up when it should not be, - it may be that your network device driver does not support - netif_carrier_on/off. This is because the default state for - netif_carrier is "carrier on." In this case, disabling - use_carrier will cause bonding to revert to the MII / ETHTOOL - ioctl method to determine the link state. - - A value of 1 enables the use of netif_carrier_ok(), a value of - 0 will use the deprecated MII / ETHTOOL ioctls. The default - value is 1. - - -Configuring Multiple Bonds -========================== - -If several bonding interfaces are required, either specify the max_bonds -parameter (described above), or load the driver multiple times. Using -the max_bonds parameter is less complicated, but has the limitation that -all bonding instances created will have the same options. Loading the -driver multiple times allows each instance of the driver to have differing -options. - -For example, to configure two bonding interfaces, one with mii link -monitoring performed every 100 milliseconds, and one with ARP link -monitoring performed every 200 milliseconds, the /etc/conf.modules should -resemble the following: + Specifies whether or not miimon should use MII or ETHTOOL + ioctls vs. netif_carrier_ok() to determine the link + status. The MII or ETHTOOL ioctls are less efficient and + utilize a deprecated calling sequence within the kernel. The + netif_carrier_ok() relies on the device driver to maintain its + state with netif_carrier_on/off; at this writing, most, but + not all, device drivers support this facility. + + If bonding insists that the link is up when it should not be, + it may be that your network device driver does not support + netif_carrier_on/off. The default state for netif_carrier is + "carrier on," so if a driver does not support netif_carrier, + it will appear as if the link is always up. In this case, + setting use_carrier to 0 will cause bonding to revert to the + MII / ETHTOOL ioctl method to determine the link state. + + A value of 1 enables the use of netif_carrier_ok(), a value of + 0 will use the deprecated MII / ETHTOOL ioctls. The default + value is 1. + + + +3. Configuring Bonding Devices +============================== + + There are, essentially, two methods for configuring bonding: +with support from the distro's network initialization scripts, and +without. Distros generally use one of two packages for the network +initialization scripts: initscripts or sysconfig. Recent versions of +these packages have support for bonding, while older versions do not. + + We will first describe the options for configuring bonding for +distros using versions of initscripts and sysconfig with full or +partial support for bonding, then provide information on enabling +bonding without support from the network initialization scripts (i.e., +older versions of initscripts or sysconfig). + + If you're unsure whether your distro uses sysconfig or +initscripts, or don't know if it's new enough, have no fear. +Determining this is fairly straightforward. + + First, issue the command: + +$ rpm -qf /sbin/ifup + + It will respond with a line of text starting with either +"initscripts" or "sysconfig," followed by some numbers. This is the +package that provides your network initialization scripts. + + Next, to determine if your installation supports bonding, +issue the command: + +$ grep ifenslave /sbin/ifup + + If this returns any matches, then your initscripts or +sysconfig has support for bonding. + +3.1 Configuration with sysconfig support +---------------------------------------- + + This section applies to distros using a version of sysconfig +with bonding support, for example, SuSE Linux Enterprise Server 9. + + SuSE SLES 9's networking configuration system does support +bonding, however, at this writing, the YaST system configuration +frontend does not provide any means to work with bonding devices. +Bonding devices can be managed by hand, however, as follows. + + First, if they have not already been configured, configure the +slave devices. On SLES 9, this is most easily done by running the +yast2 sysconfig configuration utility. The goal is for to create an +ifcfg-id file for each slave device. The simplest way to accomplish +this is to configure the devices for DHCP. The name of the +configuration file for each device will be of the form: + +ifcfg-id-xx:xx:xx:xx:xx:xx + + Where the "xx" portion will be replaced with the digits from +the device's permanent MAC address. + + Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been +created, it is necessary to edit the configuration files for the slave +devices (the MAC addresses correspond to those of the slave devices). +Before editing, the file will contain muliple lines, and will look +something like this: + +BOOTPROTO='dhcp' +STARTMODE='on' +USERCTL='no' +UNIQUE='XNzu.WeZGOGF+4wE' +_nm_name='bus-pci-0001:61:01.0' + + Change the BOOTPROTO and STARTMODE lines to the following: + +BOOTPROTO='none' +STARTMODE='off' + + Do not alter the UNIQUE or _nm_name lines. Remove any other +lines (USERCTL, etc). + + Once the ifcfg-id-xx:xx:xx:xx:xx:xx files have been modified, +it's time to create the configuration file for the bonding device +itself. This file is named ifcfg-bondX, where X is the number of the +bonding device to create, starting at 0. The first such file is +ifcfg-bond0, the second is ifcfg-bond1, and so on. The sysconfig +network configuration system will correctly start multiple instances +of bonding. + + The contents of the ifcfg-bondX file is as follows: + +BOOTPROTO="static" +BROADCAST="10.0.2.255" +IPADDR="10.0.2.10" +NETMASK="255.255.0.0" +NETWORK="10.0.2.0" +REMOTE_IPADDR="" +STARTMODE="onboot" +BONDING_MASTER="yes" +BONDING_MODULE_OPTS="mode=active-backup miimon=100" +BONDING_SLAVE0="eth0" +BONDING_SLAVE1="eth1" + + Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK +values with the appropriate values for your network. + + Note that configuring the bonding device with BOOTPROTO='dhcp' +does not work; the scripts attempt to obtain the device address from +DHCP prior to adding any of the slave devices. Without active slaves, +the DHCP requests are not sent to the network. + + The STARTMODE specifies when the device is brought online. +The possible values are: + + onboot: The device is started at boot time. If you're not + sure, this is probably what you want. + + manual: The device is started only when ifup is called + manually. Bonding devices may be configured this + way if you do not wish them to start automatically + at boot for some reason. + + hotplug: The device is started by a hotplug event. This is not + a valid choice for a bonding device. + + off or ignore: The device configuration is ignored. + + The line BONDING_MASTER='yes' indicates that the device is a +bonding master device. The only useful value is "yes." + + The contents of BONDING_MODULE_OPTS are supplied to the +instance of the bonding module for this device. Specify the options +for the bonding mode, link monitoring, and so on here. Do not include +the max_bonds bonding parameter; this will confuse the configuration +system if you have multiple bonding devices. + + Finally, supply one BONDING_SLAVEn="ethX" for each slave, +where "n" is an increasing value, one for each slave, and "ethX" is +the name of the slave device (eth0, eth1, etc). + + When all configuration files have been modified or created, +networking must be restarted for the configuration changes to take +effect. This can be accomplished via the following: + +# /etc/init.d/network restart + + Note that the network control script (/sbin/ifdown) will +remove the bonding module as part of the network shutdown processing, +so it is not necessary to remove the module by hand if, e.g., the +module paramters have changed. + + Also, at this writing, YaST/YaST2 will not manage bonding +devices (they do not show bonding interfaces on its list of network +devices). It is necessary to edit the configuration file by hand to +change the bonding configuration. + + Additional general options and details of the ifcfg file +format can be found in an example ifcfg template file: + +/etc/sysconfig/network/ifcfg.template + + Note that the template does not document the various BONDING_ +settings described above, but does describe many of the other options. + +3.2 Configuration with initscripts support +------------------------------------------ + + This section applies to distros using a version of initscripts +with bonding support, for example, Red Hat Linux 9 or Red Hat +Enterprise Linux version 3. On these systems, the network +initialization scripts have some knowledge of bonding, and can be +configured to control bonding devices. + + These distros will not automatically load the network adapter +driver unless the ethX device is configured with an IP address. +Because of this constraint, users must manually configure a +network-script file for all physical adapters that will be members of +a bondX link. Network script files are located in the directory: + +/etc/sysconfig/network-scripts + + The file name must be prefixed with "ifcfg-eth" and suffixed +with the adapter's physical adapter number. For example, the script +for eth0 would be named /etc/sysconfig/network-scripts/ifcfg-eth0. +Place the following text in the file: -alias bond0 bonding -alias bond1 bonding +DEVICE=eth0 +USERCTL=no +ONBOOT=yes +MASTER=bond0 +SLAVE=yes +BOOTPROTO=none -options bond0 miimon=100 -options bond1 -o bonding1 arp_interval=200 arp_ip_target=10.0.0.1 + The DEVICE= line will be different for every ethX device and +must correspond with the name of the file, i.e., ifcfg-eth1 must have +a device line of DEVICE=eth1. The setting of the MASTER= line will +also depend on the final bonding interface name chosen for your bond. +As with other network devices, these typically start at 0, and go up +one for each device, i.e., the first bonding instance is bond0, the +second is bond1, and so on. + + Next, create a bond network script. The file name for this +script will be /etc/sysconfig/network-scripts/ifcfg-bondX where X is +the number of the bond. For bond0 the file is named "ifcfg-bond0", +for bond1 it is named "ifcfg-bond1", and so on. Within that file, +place the following text: -Configuring Multiple ARP Targets -================================ +DEVICE=bond0 +IPADDR=192.168.1.1 +NETMASK=255.255.255.0 +NETWORK=192.168.1.0 +BROADCAST=192.168.1.255 +ONBOOT=yes +BOOTPROTO=none +USERCTL=no -While ARP monitoring can be done with just one target, it can be useful -in a High Availability setup to have several targets to monitor. In the -case of just one target, the target itself may go down or have a problem -making it unresponsive to ARP requests. Having an additional target (or -several) increases the reliability of the ARP monitoring. + Be sure to change the networking specific lines (IPADDR, +NETMASK, NETWORK and BROADCAST) to match your network configuration. -Multiple ARP targets must be seperated by commas as follows: + Finally, it is necessary to edit /etc/modules.conf to load the +bonding module when the bond0 interface is brought up. The following +sample lines in /etc/modules.conf will load the bonding module, and +select its options: -# example options for ARP monitoring with three targets alias bond0 bonding -options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 +options bond0 mode=balance-alb miimon=100 -For just a single target the options would resemble: + Replace the sample parameters with the appropriate set of +options for your configuration. -# example options for ARP monitoring with one target + Finally run "/etc/rc.d/init.d/network restart" as root. This +will restart the networking subsystem and your bond link should be now +up and running. + + +3.3 Configuring Bonding Manually +-------------------------------- + + This section applies to distros whose network initialization +scripts (the sysconfig or initscripts package) do not have specific +knowledge of bonding. One such distro is SuSE Linux Enterprise Server +version 8. + + The general methodology for these systems is to place the +bonding module parameters into /etc/modprobe.conf, then add modprobe +and/or ifenslave commands to the system's global init script. The +name of the global init script differs; for sysconfig, it is +/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local. + + For example, if you wanted to make a simple bond of two e100 +devices (presumed to be eth0 and eth1), and have it persist across +reboots, edit the appropriate file (/etc/init.d/boot.local or +/etc/rc.d/rc.local), and add the following: + +modprobe bonding -obond0 mode=balance-alb miimon=100 +modprobe e100 +ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up +ifenslave bond0 eth0 +ifenslave bond0 eth1 + + Replace the example bonding module parameters and bond0 +network configuration (IP address, netmask, etc) with the appropriate +values for your configuration. The above example loads the bonding +module with the name "bond0," this simplifies the naming if multiple +bonding modules are loaded (each successive instance of the module is +given a different name, and the module instance names match the +bonding interface names). + + Unfortunately, this method will not provide support for the +ifup and ifdown scripts on the bond devices. To reload the bonding +configuration, it is necessary to run the initialization script, e.g., + +# /etc/init.d/boot.local + + or + +# /etc/rc.d/rc.local + + It may be desirable in such a case to create a separate script +which only initializes the bonding configuration, then call that +separate script from within boot.local. This allows for bonding to be +enabled without re-running the entire global init script. + + To shut down the bonding devices, it is necessary to first +mark the bonding device itself as being down, then remove the +appropriate device driver modules. For our example above, you can do +the following: + +# ifconfig bond0 down +# rmmod bond0 +# rmmod e100 + + Again, for convenience, it may be desirable to create a script +with these commands. + + +3.4 Configuring Multiple Bonds +------------------------------ + + This section contains information on configuring multiple +bonding devices with differing options. If you require multiple +bonding devices, but all with the same options, see the "max_bonds" +module paramter, documented above. + + To create multiple bonding devices with differing options, it +is necessary to load the bonding driver multiple times. Note that +current versions of the sysconfig network initialization scripts +handle this automatically; if your distro uses these scripts, no +special action is needed. See the section Configuring Bonding +Devices, above, if you're not sure about your network initialization +scripts. + + To load multiple instances of the module, it is necessary to +specify a different name for each instance (the module loading system +requires that every loaded module, even multiple instances of the same +module, have a unique name). This is accomplished by supplying +multiple sets of bonding options in /etc/modprobe.conf, for example: + alias bond0 bonding -options bond0 arp_interval=60 arp_ip_target=192.168.0.100 - -Potential Problems When Using ARP Monitor -========================================= +options bond0 -o bond0 mode=balance-rr miimon=100 -1. Driver support - -The ARP monitor relies on the network device driver to maintain two -statistics: the last receive time (dev->last_rx), and the last -transmit time (dev->trans_start). If the network device driver does -not update one or both of these, then the typical result will be that, -upon startup, all links in the bond will immediately be declared down, -and remain that way. A network monitoring tool (tcpdump, e.g.) will -show ARP requests and replies being sent and received on the bonding -device. - -The possible resolutions for this are to (a) fix the device driver, or -(b) discontinue the ARP monitor (using miimon as an alternative, for -example). - -2. Adventures in Routing - -When bonding is set up with the ARP monitor, it is important that the -slave devices not have routes that supercede routes of the master (or, -generally, not have routes at all). For example, suppose the bonding -device bond0 has two slaves, eth0 and eth1, and the routing table is -as follows: - -Kernel IP routing table -Destination Gateway Genmask Flags MSS Window irtt Iface -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 -127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo +alias bond1 bonding +options bond1 -o bond1 mode=balance-alb miimon=50 -In this case, the ARP monitor (and ARP itself) may become confused, -because ARP requests will be sent on one interface (bond0), but the -corresponding reply will arrive on a different interface (eth0). This -reply looks to ARP as an unsolicited ARP reply (because ARP matches -replies on an interface basis), and is discarded. This will likely -still update the receive/transmit times in the driver, but will lose -packets. - -The resolution here is simply to insure that slaves do not have routes -of their own, and if for some reason they must, those routes do not -supercede routes of their master. This should generally be the case, -but unusual configurations or errant manual or automatic static route -additions may cause trouble. + will load the bonding module two times. The first instance is +named "bond0" and creates the bond0 device in balance-rr mode with an +miimon of 100. The second instance is named "bond1" and creates the +bond1 device in balance-alb mode with an miimon of 50. -Switch Configuration -==================== + This may be repeated any number of times, specifying a new and +unique name in place of bond0 or bond1 for each instance. -While the switch does not need to be configured when the active-backup, -balance-tlb or balance-alb policies (mode=1,5,6) are used, it does need to -be configured for the round-robin, XOR, broadcast, or 802.3ad policies -(mode=0,2,3,4). + When the appropriate module paramters are in place, then +configure bonding according to the instructions for your distro. +5. Querying Bonding Configuration +================================= -Verifying Bond Configuration -============================ +5.1 Bonding Configuration +------------------------- -1) Bonding information files ----------------------------- -The bonding driver information files reside in the /proc/net/bonding directory. + Each bonding device has a read-only file residing in the +/proc/net/bonding directory. The file contents include information +about the bonding configuration, options and state of each slave. -Sample contents of /proc/net/bonding/bond0 after the driver is loaded with -parameters of mode=0 and miimon=1000 is shown below. + For example, the contents of /proc/net/bonding/bond0 after the +driver is loaded with parameters of mode=0 and miimon=1000 is +generally as follows: + Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004) Bonding Mode: load balancing (round-robin) Currently Active Slave: eth0 MII Status: up @@ -531,15 +760,23 @@ MII Status: up Link Failure Count: 1 -2) Network verification ------------------------ -The network configuration can be verified using the ifconfig command. In -the example below, the bond0 interface is the master (MASTER) while eth0 and -eth1 are slaves (SLAVE). Notice all slaves of bond0 have the same MAC address -(HWaddr) as bond0 for all modes except TLB and ALB that require a unique MAC -address for each slave. + The precise format and contents will change depending upon the +bonding configuration, state, and version of the bonding driver. + +5.2 Network configuration +------------------------- + + The network configuration can be inspected using the ifconfig +command. Bonding devices will have the MASTER flag set; Bonding slave +devices will have the SLAVE flag set. The ifconfig output does not +contain information on which slaves are associated with which masters. + + In the example below, the bond0 interface is the master +(MASTER) while eth0 and eth1 are slaves (SLAVE). Notice all slaves of +bond0 have the same MAC address (HWaddr) as bond0 for all modes except +TLB and ALB that require a unique MAC address for each slave. -[root]# /sbin/ifconfig +# /sbin/ifconfig bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 @@ -563,430 +800,819 @@ collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1400 +6. Switch Configuration +======================= -Frequently Asked Questions -========================== + For this section, "switch" refers to whatever system the +bonded devices are directly connected to (i.e., where the other end of +the cable plugs into). This may be an actual dedicated switch device, +or it may be another regular system (e.g., another computer running +Linux), + + The active-backup, balance-tlb and balance-alb modes do not +require any specific configuration of the switch. + + The 802.3ad mode requires that the switch have the appropriate +ports configured as an 802.3ad aggregation. The precise method used +to configure this varies from switch to switch, but, for example, a +Cisco 3550 series switch requires that the appropriate ports first be +grouped together in a single etherchannel instance, then that +etherchannel is set to mode "lacp" to enable 802.3ad (instead of +standard EtherChannel). + + The balance-rr, balance-xor and broadcast modes generally +require that the switch have the appropriate ports grouped together. +The nomenclature for such a group differs between switches, it may be +called an "etherchannel" (as in the Cisco example, above), a "trunk +group" or some other similar variation. For these modes, each switch +will also have its own configuration options for the switch's transmit +policy to the bond. Typical choices include XOR of either the MAC or +IP addresses. The transmit policy of the two peers does not need to +match. For these three modes, the bonding mode really selects a +transmit policy for an EtherChannel group; all three will interoperate +with another EtherChannel group. + + +7. 802.1q VLAN Support +====================== + + It is possible to configure VLAN devices over a bond interface +using the 8021q driver. However, only packets coming from the 8021q +driver and passing through bonding will be tagged by default. Self +generated packets, for example, bonding's learning packets or ARP +packets generated by either ALB mode or the ARP monitor mechanism, are +tagged internally by bonding itself. As a result, bonding must +"learn" the VLAN IDs configured above it, and use those IDs to tag +self generated packets. + + For reasons of simplicity, and to support the use of adapters +that can do VLAN hardware acceleration offloding, the bonding +interface declares itself as fully hardware offloaing capable, it gets +the add_vid/kill_vid notifications to gather the necessary +information, and it propagates those actions to the slaves. In case +of mixed adapter types, hardware accelerated tagged packets that +should go through an adapter that is not offloading capable are +"un-accelerated" by the bonding driver so the VLAN tag sits in the +regular location. + + VLAN interfaces *must* be added on top of a bonding interface +only after enslaving at least one slave. The bonding interface has a +hardware address of 00:00:00:00:00:00 until the first slave is added. +If the VLAN interface is created prior to the first enslavement, it +would pick up the all-zeroes hardware address. Once the first slave +is attached to the bond, the bond device itself will pick up the +slave's hardware address, which is then available for the VLAN device. + + Also, be aware that a similar problem can occur if all slaves +are released from a bond that still has one or more VLAN interfaces on +top of it. When a new slave is added, the bonding interface will +obtain its hardware address from the first slave, which might not +match the hardware address of the VLAN interfaces (which was +ultimately copied from an earlier slave). + + There are two methods to insure that the VLAN device operates +with the correct hardware address if all slaves are removed from a +bond interface: + + 1. Remove all VLAN interfaces then recreate them + + 2. Set the bonding interface's hardware address so that it +matches the hardware address of the VLAN interfaces. + + Note that changing a VLAN interface's HW address would set the +underlying device -- i.e. the bonding interface -- to promiscouos +mode, which might not be what you want. -1. Is it SMP safe? - - Yes. The old 2.0.xx channel bonding patch was not SMP safe. - The new driver was designed to be SMP safe from the start. -2. What type of cards will work with it? - - Any Ethernet type cards (you can even mix cards - a Intel - EtherExpress PRO/100 and a 3com 3c905b, for example). - You can even bond together Gigabit Ethernet cards! +8. Link Monitoring +================== -3. How many bonding devices can I have? + The bonding driver at present supports two schemes for +monitoring a slave device's link state: the ARP monitor and the MII +monitor. + + At the present time, due to implementation restrictions in the +bonding driver itself, it is not possible to enable both ARP and MII +monitoring simultaneously. + +8.1 ARP Monitor Operation +------------------------- + + The ARP monitor operates as its name suggests: it sends ARP +queries to one or more designated peer systems on the network, and +uses the response as an indication that the link is operating. This +gives some assurance that traffic is actually flowing to and from one +or more peers on the local network. + + The ARP monitor relies on the device driver itself to verify +that traffic is flowing. In particular, the driver must keep up to +date the last receive time, dev->last_rx, and transmit start time, +dev->trans_start. If these are not updated by the driver, then the +ARP monitor will immediately fail any slaves using that driver, and +those slaves will stay down. If networking monitoring (tcpdump, etc) +shows the ARP requests and replies on the network, then it may be that +your device driver is not updating last_rx and trans_start. - There is no limit. +8.2 Configuring Multiple ARP Targets +------------------------------------ -4. How many slaves can a bonding device have? + While ARP monitoring can be done with just one target, it can +be useful in a High Availability setup to have several targets to +monitor. In the case of just one target, the target itself may go +down or have a problem making it unresponsive to ARP requests. Having +an additional target (or several) increases the reliability of the ARP +monitoring. - Limited by the number of network interfaces Linux supports and/or the - number of network cards you can place in your system. + Multiple ARP targets must be seperated by commas as follows: -5. What happens when a slave link dies? +# example options for ARP monitoring with three targets +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 - If your ethernet cards support MII or ETHTOOL link status monitoring - and the MII monitoring has been enabled in the driver (see description - of module parameters), there will be no adverse consequences. This - release of the bonding driver knows how to get the MII information and - enables or disables its slaves according to their link status. - See section on High Availability for additional information. - - For ethernet cards not supporting MII status, the arp_interval and - arp_ip_target parameters must be specified for bonding to work - correctly. If packets have not been sent or received during the - specified arp_interval duration, an ARP request is sent to the - targets to generate send and receive traffic. If after this - interval, either the successful send and/or receive count has not - incremented, the next slave in the sequence will become the active - slave. - - If neither mii_monitor and arp_interval is configured, the bonding - driver will not handle this situation very well. The driver will - continue to send packets but some packets will be lost. Retransmits - will cause serious degradation of performance (in the case when one - of two slave links fails, 50% packets will be lost, which is a serious - problem for both TCP and UDP). + For just a single target the options would resemble: -6. Can bonding be used for High Availability? +# example options for ARP monitoring with one target +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.100 - Yes, if you use MII monitoring and ALL your cards support MII link - status reporting. See section on High Availability for more - information. -7. Which switches/systems does it work with? +8.3 MII Monitor Operation +------------------------- - In round-robin and XOR mode, it works with systems that support - trunking: + The MII monitor monitors only the carrier state of the local +network interface. It accomplishes this in one of three ways: by +depending upon the device driver to maintain its carrier state, by +querying the device's MII registers, or by making an ethtool query to +the device. + + If the use_carrier module parameter is 1 (the default value), +then the MII monitor will rely on the driver for carrier state +information (via the netif_carrier subsystem). As explained in the +use_carrier parameter information, above, if the MII monitor fails to +detect carrier loss on the device (e.g., when the cable is physically +disconnected), it may be that the driver does not support +netif_carrier. + + If use_carrier is 0, then the MII monitor will first query the +device's (via ioctl) MII registers and check the link state. If that +request fails (not just that it returns carrier down), then the MII +monitor will make an ethtool ETHOOL_GLINK request to attempt to obtain +the same information. If both methods fail (i.e., the driver either +does not support or had some error in processing both the MII register +and ethtool requests), then the MII monitor will assume the link is +up. - * Many Cisco switches and routers (look for EtherChannel support). - * SunTrunking software. - * Alteon AceDirector switches / WebOS (use Trunks). - * BayStack Switches (trunks must be explicitly configured). Stackable - models (450) can define trunks between ports on different physical - units. - * Linux bonding, of course ! - - In 802.3ad mode, it works with with systems that support IEEE 802.3ad - Dynamic Link Aggregation: - - * Extreme networks Summit 7i (look for link-aggregation). - * Many Cisco switches and routers (look for LACP support; this may - require an upgrade to your IOS software; LACP support was added - by Cisco in late 2002). - * Foundry Big Iron 4000 +9. Potential Sources of Trouble +=============================== - In active-backup, balance-tlb and balance-alb modes, it should work - with any Layer-II switch. +9.1 Adventures in Routing +------------------------- + When bonding is configured, it is important that the slave +devices not have routes that supercede routes of the master (or, +generally, not have routes at all). For example, suppose the bonding +device bond0 has two slaves, eth0 and eth1, and the routing table is +as follows: -8. Where does a bonding device get its MAC address from? +Kernel IP routing table +Destination Gateway Genmask Flags MSS Window irtt Iface +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 +127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo - If not explicitly configured with ifconfig, the MAC address of the - bonding device is taken from its first slave device. This MAC address - is then passed to all following slaves and remains persistent (even if - the the first slave is removed) until the bonding device is brought - down or reconfigured. + This routing configuration will likely still update the +receive/transmit times in the driver (needed by the ARP monitor), but +may bypass the bonding driver (because outgoing traffic to, in this +case, another host on network 10 would use eth0 or eth1 before bond0). + + The ARP monitor (and ARP itself) may become confused by this +configuration, because ARP requests (generated by the ARP monitor) +will be sent on one interface (bond0), but the corresponding reply +will arrive on a different interface (eth0). This reply looks to ARP +as an unsolicited ARP reply (because ARP matches replies on an +interface basis), and is discarded. The MII monitor is not affected +by the state of the routing table. + + The solution here is simply to insure that slaves do not have +routes of their own, and if for some reason they must, those routes do +not supercede routes of their master. This should generally be the +case, but unusual configurations or errant manual or automatic static +route additions may cause trouble. - If you wish to change the MAC address, you can set it with ifconfig: +9.2 Ethernet Device Renaming +---------------------------- - # ifconfig bond0 hw ether 00:11:22:33:44:55 + On systems with network configuration scripts that do not +associate physical devices directly with network interface names (so +that the same physical device always has the same "ethX" name), it may +be necessary to add some special logic to either /etc/modules.conf or +/etc/modprobe.conf (depending upon which is installed on the system). - The MAC address can be also changed by bringing down/up the device - and then changing its slaves (or their order): + For example, given a modules.conf containing the following: - # ifconfig bond0 down ; modprobe -r bonding - # ifconfig bond0 .... up - # ifenslave bond0 eth... +alias bond0 bonding +options bond0 mode=some-mode miimon=50 +alias eth0 tg3 +alias eth1 tg3 +alias eth2 e1000 +alias eth3 e1000 + + If neither eth0 and eth1 are slaves to bond0, then when the +bond0 interface comes up, the devices may end up reordered. This +happens because bonding is loaded first, then its slave device's +drivers are loaded next. Since no other drivers have been loaded, +when the e1000 driver loads, it will receive eth0 and eth1 for its +devices, but the bonding configuration tries to enslave eth2 and eth3 +(which may later be assigned to the tg3 devices). + + Adding the following: + +add above bonding e1000 tg3 + + causes modprobe to load e1000 then tg3, in that order, when +bonding is loaded. This command is fully documented in the +modules.conf manual page. + + On systems utilizing modprobe.conf (or modprobe.conf.local), +an equivalent problem can occur. In this case, the following can be +added to modprobe.conf (or modprobe.conf.local, as appropriate), as +follows (all on one line; it has been split here for clarity): + +install bonding /sbin/modprobe tg3; /sbin/modprobe e1000; + /sbin/modprobe --ignore-install bonding + + This will, when loading the bonding module, rather than +performing the normal action, instead execute the provided command. +This command loads the device drivers in the order needed, then calls +modprobe with --ingore-install to cause the normal action to then take +place. Full documentation on this can be found in the modprobe.conf +and modprobe manual pages. + +9.3. Painfully Slow Or No Failed Link Detection By Miimon +--------------------------------------------------------- + + By default, bonding enables the use_carrier option, which +instructs bonding to trust the driver to maintain carrier state. + + As discussed in the options section, above, some drivers do +not support the netif_carrier_on/_off link state tracking system. +With use_carrier enabled, bonding will always see these links as up, +regardless of their actual state. + + Additionally, other drivers do support netif_carrier, but do +not maintain it in real time, e.g., only polling the link state at +some fixed interval. In this case, miimon will detect failures, but +only after some long period of time has expired. If it appears that +miimon is very slow in detecting link failures, try specifying +use_carrier=0 to see if that improves the failure detection time. If +it does, then it may be that the driver checks the carrier state at a +fixed interval, but does not cache the MII register values (so the +use_carrier=0 method of querying the registers directly works). If +use_carrier=0 does not improve the failover, then the driver may cache +the registers, or the problem may be elsewhere. + + Also, remember that miimon only checks for the device's +carrier state. It has no way to determine the state of devices on or +beyond other ports of a switch, or if a switch is refusing to pass +traffic while still maintaining carrier on. + +10. SNMP agents +=============== + + If running SNMP agents, the bonding driver should be loaded +before any network drivers participating in a bond. This requirement +is due to the the interface index (ipAdEntIfIndex) being associated to +the first interface found with a given IP address. That is, there is +only one ipAdEntIfIndex for each IP address. For example, if eth0 and +eth1 are slaves of bond0 and the driver for eth0 is loaded before the +bonding driver, the interface for the IP address will be associated +with the eth0 interface. This configuration is shown below, the IP +address 192.168.1.1 has an interface index of 2 which indexes to eth0 +in the ifDescr table (ifDescr.2). - This method will automatically take the address from the next slave - that will be added. + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = eth0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth1 + interfaces.ifTable.ifEntry.ifDescr.4 = eth2 + interfaces.ifTable.ifEntry.ifDescr.5 = eth3 + interfaces.ifTable.ifEntry.ifDescr.6 = bond0 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 - To restore your slaves' MAC addresses, you need to detach them - from the bond (`ifenslave -d bond0 eth0'). The bonding driver will then - restore the MAC addresses that the slaves had before they were enslaved. + This problem is avoided by loading the bonding driver before +any network drivers participating in a bond. Below is an example of +loading the bonding driver first, the IP address 192.168.1.1 is +correctly associated with ifDescr.2. -9. Which transmit polices can be used? + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = bond0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth0 + interfaces.ifTable.ifEntry.ifDescr.4 = eth1 + interfaces.ifTable.ifEntry.ifDescr.5 = eth2 + interfaces.ifTable.ifEntry.ifDescr.6 = eth3 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 - Round-robin, based on the order of enslaving, the output device - is selected base on the next available slave. Regardless of - the source and/or destination of the packet. + While some distributions may not report the interface name in +ifDescr, the association between the IP address and IfIndex remains +and SNMP functions such as Interface_Scan_Next will report that +association. - Active-backup policy that ensures that one and only one device will - transmit at any given moment. Active-backup policy is useful for - implementing high availability solutions using two hubs (see - section on High Availability). +11. Promiscuous mode +==================== - XOR, based on (src hw addr XOR dst hw addr) % slave count. This - policy selects the same slave for each destination hw address. + When running network monitoring tools, e.g., tcpdump, it is +common to enable promiscuous mode on the device, so that all traffic +is seen (instead of seeing only traffic destined for the local host). +The bonding driver handles promiscuous mode changes to the bonding +master device (e.g., bond0), and propogates the setting to the slave +devices. + + For the balance-rr, balance-xor, broadcast, and 802.3ad modes, +the promiscuous mode setting is propogated to all slaves. + + For the active-backup, balance-tlb and balance-alb modes, the +promiscuous mode setting is propogated only to the active slave. + + For balance-tlb mode, the active slave is the slave currently +receiving inbound traffic. + + For balance-alb mode, the active slave is the slave used as a +"primary." This slave is used for mode-specific control traffic, for +sending to peers that are unassigned or if the load is unbalanced. + + For the active-backup, balance-tlb and balance-alb modes, when +the active slave changes (e.g., due to a link failure), the +promiscuous setting will be propogated to the new active slave. + +12. High Availability Information +================================= + + High Availability refers to configurations that provide +maximum network availability by having redundant or backup devices, +links and switches between the host and the rest of the world. + + There are currently two basic methods for configuring to +maximize availability. They are dependent on the network topology and +the primary goal of the configuration, but in general, a configuration +can be optimized for maximum available bandwidth, or for maximum +network availability. + +12.1 High Availability in a Single Switch Topology +-------------------------------------------------- + + If two hosts (or a host and a switch) are directly connected +via multiple physical links, then there is no network availability +penalty for optimizing for maximum bandwidth: there is only one switch +(or peer), so if it fails, you have no alternative access to fail over +to. - Broadcast policy transmits everything on all slave interfaces. +Example 1 : host to switch (or other host) - 802.3ad, based on XOR but distributes traffic among all interfaces - in the active aggregator. + +----------+ +----------+ + | |eth0 eth0| switch | + | Host A +--------------------------+ or | + | +--------------------------+ other | + | |eth1 eth1| host | + +----------+ +----------+ - Transmit load balancing (balance-tlb) balances the traffic - according to the current load on each slave. The balancing is - clients based and the least loaded slave is selected for each new - client. The load of each slave is calculated relative to its speed - and enables load balancing in mixed speed teams. - Adaptive load balancing (balance-alb) uses the Transmit load - balancing for the transmit load. The receive load is balanced only - among the group of highest speed active slaves in the bond. The - load is distributed with round-robin i.e. next available slave in - the high speed group of active slaves. +12.1.1 Bonding Mode Selection for single switch topology +-------------------------------------------------------- -High Availability -================= + This configuration is the easiest to set up and to understand, +although you will have to decide which bonding mode best suits your +needs. The tradeoffs for each mode are detailed below: + +balance-rr: This mode is the only mode that will permit a single + TCP/IP connection to stripe traffic across multiple + interfaces. It is therefore the only mode that will allow a + single TCP/IP stream to utilize more than one interface's + worth of throughput. This comes at a cost, however: the + striping often results in peer systems receiving packets out + of order, causing TCP/IP's congestion control system to kick + in, often by retransmitting segments. + + It is possible to adjust TCP/IP's congestion limits by + altering the net.ipv4.tcp_reordering sysctl parameter. The + usual default value is 3, and the maximum useful value is 127. + For a four interface balance-rr bond, expect that a single + TCP/IP stream will utilize no more than approximately 2.3 + interface's worth of throughput, even after adjusting + tcp_reordering. + + If you are utilizing protocols other than TCP/IP, UDP for + example, and your application can tolerate out of order + delivery, then this mode can allow for single stream datagram + performance that scales near linearly as interfaces are added + to the bond. + + This mode requires the switch to have the appropriate ports + configured for "etherchannel" or "trunking." + +active-backup: There is not much advantage in this network topology to + the active-backup mode, as the inactive backup devices are all + connected to the same peer as the primary. In this case, a + load balancing mode (with link monitoring) will provide the + same level of network availability, but with increased + available bandwidth. On the plus side, it does not require + any configuration of the switch. + +balance-xor: This mode will limit traffic such that packets destined + for specific peers will always be sent over the same + interface. Since the destination is determined by the MAC + addresses involved, this may be desirable if you have a large + network with many hosts. It is likely to be suboptimal if all + your traffic is passed through a single router, however. As + with balance-rr, the switch ports need to be configured for + "etherchannel" or "trunking." + +broadcast: Like active-backup, there is not much advantage to this + mode in this type of network topology. + +802.3ad: This mode can be a good choice for this type of network + topology. The 802.3ad mode is an IEEE standard, so all peers + that implement 802.3ad should interoperate well. The 802.3ad + protocol includes automatic configuration of the aggregates, + so minimal manual configuration of the switch is needed + (typically only to designate that some set of devices is + usable for 802.3ad). The 802.3ad standard also mandates that + frames be delivered in order (within certain limits), so in + general single connections will not see misordering of + packets. The 802.3ad mode does have some drawbacks: the + standard mandates that all devices in the aggregate operate at + the same speed and duplex. Also, as with all bonding load + balance modes other than balance-rr, no single connection will + be able to utilize more than a single interface's worth of + bandwidth. Additionally, the linux bonding 802.3ad + implementation distributes traffic by peer (using an XOR of + MAC addresses), so in general all traffic to a particular + destination will use the same interface. Finally, the 802.3ad + mode mandates the use of the MII monitor, therefore, the ARP + monitor is not available in this mode. + +balance-tlb: This mode is also a good choice for this type of + topology. It has no special switch configuration + requirements, and balances outgoing traffic by peer, in a + vaguely intelligent manner (not a simple XOR as in balance-xor + or 802.3ad mode), so that unlucky MAC addresses will not all + "bunch up" on a single interface. Interfaces may be of + differing speeds. On the down side, in this mode all incoming + traffic arrives over a single interface, this mode requires + certain ethtool support in the network device driver of the + slave interfaces, and the ARP monitor is not available. + +balance-alb: This mode is everything that balance-tlb is, and more. It + has all of the features (and restrictions) of balance-tlb, and + will also balance incoming traffic from peers (as described in + the Bonding Module Options section, above). The only extra + down side to this mode is that the network device driver must + support changing the hardware address while the device is + open. + +12.1.2 Link Monitoring for Single Switch Topology +------------------------------------------------- + + The choice of link monitoring may largely depend upon which +mode you choose to use. The more advanced load balancing modes do not +support the use of the ARP monitor, and are thus restricted to using +the MII monitor (which does not provide as high a level of assurance +as the ARP monitor). + + +12.2 High Availability in a Multiple Switch Topology +---------------------------------------------------- + + With multiple switches, the configuration of bonding and the +network changes dramatically. In multiple switch topologies, there is +a tradeoff between network availability and usable bandwidth. -To implement high availability using the bonding driver, the driver needs to be -compiled as a module, because currently it is the only way to pass parameters -to the driver. This may change in the future. - -High availability is achieved by using MII or ETHTOOL status reporting. You -need to verify that all your interfaces support MII or ETHTOOL link status -reporting. On Linux kernel 2.2.17, all the 100 Mbps capable drivers and -yellowfin gigabit driver support MII. To determine if ETHTOOL link reporting -is available for interface eth0, type "ethtool eth0" and the "Link detected:" -line should contain the correct link status. If your system has an interface -that does not support MII or ETHTOOL status reporting, a failure of its link -will not be detected! A message indicating MII and ETHTOOL is not supported by -a network driver is logged when the bonding driver is loaded with a non-zero -miimon value. - -The bonding driver can regularly check all its slaves links using the ETHTOOL -IOCTL (ETHTOOL_GLINK command) or by checking the MII status registers. The -check interval is specified by the module argument "miimon" (MII monitoring). -It takes an integer that represents the checking time in milliseconds. It -should not come to close to (1000/HZ) (10 milli-seconds on i386) because it -may then reduce the system interactivity. A value of 100 seems to be a good -starting point. It means that a dead link will be detected at most 100 -milli-seconds after it goes down. - -Example: - - # modprobe bonding miimon=100 - -Or, put the following line in /etc/modprobe.conf: - - options bond0 miimon=100 - -There are currently two policies for high availability. They are dependent on -whether: - - a) hosts are connected to a single host or switch that support trunking - - b) hosts are connected to several different switches or a single switch that - does not support trunking - - -1) High Availability on a single switch or host - load balancing ----------------------------------------------------------------- -It is the easiest to set up and to understand. Simply configure the -remote equipment (host or switch) to aggregate traffic over several -ports (Trunk, EtherChannel, etc.) and configure the bonding interfaces. -If the module has been loaded with the proper MII option, it will work -automatically. You can then try to remove and restore different links -and see in your logs what the driver detects. When testing, you may -encounter problems on some buggy switches that disable the trunk for a -long time if all ports in a trunk go down. This is not Linux, but really -the switch (reboot it to ensure). + Below is a sample network, configured to maximize the +availability of the network: -Example 1 : host to host at twice the speed + | | + |port3 port3| + +-----+----+ +-----+----+ + | |port2 ISL port2| | + | switch A +--------------------------+ switch B | + | | | | + +-----+----+ +-----++---+ + |port1 port1| + | +-------+ | + +-------------+ host1 +---------------+ + eth0 +-------+ eth1 - +----------+ +----------+ - | |eth0 eth0| | - | Host A +--------------------------+ Host B | - | +--------------------------+ | - | |eth1 eth1| | - +----------+ +----------+ + In this configuration, there is a link between the two +switches (ISL, or inter switch link), and multiple ports connecting to +the outside world ("port3" on each switch). There is no technical +reason that this could not be extended to a third switch. + +12.2.1 Bonding Mode Selection for Multiple Switch Topology +---------------------------------------------------------- + + In a topology such as this, the active-backup and broadcast +modes are the only useful bonding modes; the other modes require all +links to terminate on the same peer for them to behave rationally. + +active-backup: This is generally the preferred mode, particularly if + the switches have an ISL and play together well. If the + network configuration is such that one switch is specifically + a backup switch (e.g., has lower capacity, higher cost, etc), + then the primary option can be used to insure that the + preferred link is always used when it is available. + +broadcast: This mode is really a special purpose mode, and is suitable + only for very specific needs. For example, if the two + switches are not connected (no ISL), and the networks beyond + them are totally independant. In this case, if it is + necessary for some specific one-way traffic to reach both + independent networks, then the broadcast mode may be suitable. + +12.2.2 Link Monitoring Selection for Multiple Switch Topology +------------------------------------------------------------- + + The choice of link monitoring ultimately depends upon your +switch. If the switch can reliably fail ports in response to other +failures, then either the MII or ARP monitors should work. For +example, in the above example, if the "port3" link fails at the remote +end, the MII monitor has no direct means to detect this. The ARP +monitor could be configured with a target at the remote end of port3, +thus detecting that failure without switch support. + + In general, however, in a multiple switch topology, the ARP +monitor can provide a higher level of reliability in detecting link +failures. Additionally, it should be configured with multiple targets +(at least one for each switch in the network). This will insure that, +regardless of which switch is active, the ARP monitor has a suitable +target to query. + + +12.3 Switch Behavior Issues for High Availability +------------------------------------------------- + + You may encounter issues with the timing of link up and down +reporting by the switch. + + First, when a link comes up, some switches may indicate that +the link is up (carrier available), but not pass traffic over the +interface for some period of time. This delay is typically due to +some type of autonegotiation or routing protocol, but may also occur +during switch initialization (e.g., during recovery after a switch +failure). If you find this to be a problem, specify an appropriate +value to the updelay bonding module option to delay the use of the +relevant interface(s). + + Second, some switches may "bounce" the link state one or more +times while a link is changing state. This occurs most commonly while +the switch is initializing. Again, an appropriate updelay value may +help, but note that if all links are down, then updelay is ignored +when any link becomes active (the slave closest to completing its +updelay is chosen). + + Note that when a bonding interface has no active links, the +driver will immediately reuse the first link that goes up, even if +updelay parameter was specified. If there are slave interfaces +waiting for the updelay timeout to expire, the interface that first +went into that state will be immediately reused. This reduces down +time of the network if the value of updelay has been overestimated. + + In addition to the concerns about switch timings, if your +switches take a long time to go into backup mode, it may be desirable +to not activate a backup interface immediately after a link goes down. +Failover may be delayed via the downdelay bonding module option. + +13. Hardware Specific Considerations +==================================== + + This section contains additional information for configuring +bonding on specific hardware platforms, or for interfacing bonding +with particular switches or other devices. + +13.1 IBM BladeCenter +-------------------- + + This applies to the JS20 and similar systems. + + On the JS20 blades, the bonding driver supports only +balance-rr, active-backup, balance-tlb and balance-alb modes. This is +largely due to the network topology inside the BladeCenter, detailed +below. + +JS20 network adapter information +-------------------------------- + + All JS20s come with two Broadcom Gigabit Ethernet ports +integrated on the planar. In the BladeCenter chassis, the eth0 port +of all JS20 blades is hard wired to I/O Module #1; similarly, all eth1 +ports are wired to I/O Module #2. An add-on Broadcom daughter card +can be installed on a JS20 to provide two more Gigabit Ethernet ports. +These ports, eth2 and eth3, are wired to I/O Modules 3 and 4, +respectively. + + Each I/O Module may contain either a switch or a passthrough +module (which allows ports to be directly connected to an external +switch). Some bonding modes require a specific BladeCenter internal +network topology in order to function; these are detailed below. - On each host : - # modprobe bonding miimon=100 - # ifconfig bond0 addr - # ifenslave bond0 eth0 eth1 + Additional BladeCenter-specific networking information can be +found in two IBM Redbooks (www.ibm.com/redbooks): -Example 2 : host to switch at twice the speed +"IBM eServer BladeCenter Networking Options" +"IBM eServer BladeCenter Layer 2-7 Network Switching" - +----------+ +----------+ - | |eth0 port1| | - | Host A +--------------------------+ switch | - | +--------------------------+ | - | |eth1 port2| | - +----------+ +----------+ +BladeCenter networking configuration +------------------------------------ - On host A : On the switch : - # modprobe bonding miimon=100 # set up a trunk on port1 - # ifconfig bond0 addr and port2 - # ifenslave bond0 eth0 eth1 + Because a BladeCenter can be configured in a very large number +of ways, this discussion will be confined to describing basic +configurations. + + Normally, Ethernet Switch Modules (ESM) are used in I/O +modules 1 and 2. In this configuration, the eth0 and eth1 ports of a +JS20 will be connected to different internal switches (in the +respective I/O modules). + + An optical passthru module (OPM) connects the I/O module +directly to an external switch. By using OPMs in I/O module #1 and +#2, the eth0 and eth1 interfaces of a JS20 can be redirected to the +outside world and connected to a common external switch. + + Depending upon the mix of ESM and OPM modules, the network +will appear to bonding as either a single switch topology (all OPM +modules) or as a multiple switch topology (one or more ESM modules, +zero or more OPM modules). It is also possible to connect ESM modules +together, resulting in a configuration much like the example in "High +Availability in a multiple switch topology." + +Requirements for specifc modes +------------------------------ + + The balance-rr mode requires the use of OPM modules for +devices in the bond, all connected to an common external switch. That +switch must be configured for "etherchannel" or "trunking" on the +appropriate ports, as is usual for balance-rr. + + The balance-alb and balance-tlb modes will function with +either switch modules or passthrough modules (or a mix). The only +specific requirement for these modes is that all network interfaces +must be able to reach all destinations for traffic sent over the +bonding device (i.e., the network must converge at some point outside +the BladeCenter). + + The active-backup mode has no additional requirements. + +Link monitoring issues +---------------------- + + When an Ethernet Switch Module is in place, only the ARP +monitor will reliably detect link loss to an external switch. This is +nothing unusual, but examination of the BladeCenter cabinet would +suggest that the "external" network ports are the ethernet ports for +the system, when it fact there is a switch between these "external" +ports and the devices on the JS20 system itself. The MII monitor is +only able to detect link failures between the ESM and the JS20 system. + + When a passthrough module is in place, the MII monitor does +detect failures to the "external" port, which is then directly +connected to the JS20 system. + +Other concerns +-------------- + + The Serial Over LAN link is established over the primary +ethernet (eth0) only, therefore, any loss of link to eth0 will result +in losing your SoL connection. It will not fail over with other +network traffic. + + It may be desirable to disable spanning tree on the switch +(either the internal Ethernet Switch Module, or an external switch) to +avoid fail-over delays issues when using bonding. + + +14. Frequently Asked Questions +============================== +1. Is it SMP safe? -2) High Availability on two or more switches (or a single switch without - trunking support) ---------------------------------------------------------------------------- -This mode is more problematic because it relies on the fact that there -are multiple ports and the host's MAC address should be visible on one -port only to avoid confusing the switches. + Yes. The old 2.0.xx channel bonding patch was not SMP safe. +The new driver was designed to be SMP safe from the start. -If you need to know which interface is the active one, and which ones are -backup, use ifconfig. All backup interfaces have the NOARP flag set. +2. What type of cards will work with it? -To use this mode, pass "mode=1" to the module at load time : + Any Ethernet type cards (you can even mix cards - a Intel +EtherExpress PRO/100 and a 3com 3c905b, for example). They need not +be of the same speed. - # modprobe bonding miimon=100 mode=active-backup +3. How many bonding devices can I have? - or: + There is no limit. - # modprobe bonding miimon=100 mode=1 +4. How many slaves can a bonding device have? -Or, put in your /etc/modprobe.conf : + This is limited only by the number of network interfaces Linux +supports and/or the number of network cards you can place in your +system. - options bond0 miimon=100 mode=active-backup +5. What happens when a slave link dies? -Example 1: Using multiple host and multiple switches to build a "no single -point of failure" solution. + If link monitoring is enabled, then the failing device will be +disabled. The active-backup mode will fail over to a backup link, and +other modes will ignore the failed link. The link will continue to be +monitored, and should it recover, it will rejoin the bond (in whatever +manner is appropriate for the mode). See the section on High +Availability for additional information. + + Link monitoring can be enabled via either the miimon or +arp_interval paramters (described in the module paramters section, +above). In general, miimon monitors the carrier state as sensed by +the underlying network device, and the arp monitor (arp_interval) +monitors connectivity to another host on the local network. + + If no link monitoring is configured, the bonding driver will +be unable to detect link failures, and will assume that all links are +always available. This will likely result in lost packets, and a +resulting degredation of performance. The precise performance loss +depends upon the bonding mode and network configuration. +6. Can bonding be used for High Availability? - | | - |port3 port3| - +-----+----+ +-----+----+ - | |port7 ISL port7| | - | switch A +--------------------------+ switch B | - | +--------------------------+ | - | |port8 port8| | - +----++----+ +-----++---+ - port2||port1 port1||port2 - || +-------+ || - |+-------------+ host1 +---------------+| - | eth0 +-------+ eth1 | - | | - | +-------+ | - +--------------+ host2 +----------------+ - eth0 +-------+ eth1 + Yes. See the section on High Availability for details. -In this configuration, there is an ISL - Inter Switch Link (could be a trunk), -several servers (host1, host2 ...) attached to both switches each, and one or -more ports to the outside world (port3...). One and only one slave on each host -is active at a time, while all links are still monitored (the system can -detect a failure of active and backup links). - -Each time a host changes its active interface, it sticks to the new one until -it goes down. In this example, the hosts are negligibly affected by the -expiration time of the switches' forwarding tables. - -If host1 and host2 have the same functionality and are used in load balancing -by another external mechanism, it is good to have host1's active interface -connected to one switch and host2's to the other. Such system will survive -a failure of a single host, cable, or switch. The worst thing that may happen -in the case of a switch failure is that half of the hosts will be temporarily -unreachable until the other switch expires its tables. +7. Which switches/systems does it work with? -Example 2: Using multiple ethernet cards connected to a switch to configure - NIC failover (switch is not required to support trunking). + The full answer to this depends upon the desired mode. + In the basic balance modes (balance-rr and balance-xor), it +works with any system that supports etherchannel (also called +trunking). Most managed switches currently available have such +support, and many unmananged switches as well. + + The advanced balance modes (balance-tlb and balance-alb) do +not have special switch requirements, but do need device drivers that +support specific features (described in the appropriate section under +module paramters, above). + + In 802.3ad mode, it works with with systems that support IEEE +802.3ad Dynamic Link Aggregation. Most managed and many unmanaged +switches currently available support 802.3ad. - +----------+ +----------+ - | |eth0 port1| | - | Host A +--------------------------+ switch | - | +--------------------------+ | - | |eth1 port2| | - +----------+ +----------+ + The active-backup mode should work with any Layer-II switch. - On host A : On the switch : - # modprobe bonding miimon=100 mode=1 # (optional) minimize the time - # ifconfig bond0 addr # for table expiration - # ifenslave bond0 eth0 eth1 +8. Where does a bonding device get its MAC address from? -Each time the host changes its active interface, it sticks to the new one until -it goes down. In this example, the host is strongly affected by the expiration -time of the switch forwarding table. + If not explicitly configured with ifconfig, the MAC address of +the bonding device is taken from its first slave device. This MAC +address is then passed to all following slaves and remains persistent +(even if the the first slave is removed) until the bonding device is +brought down or reconfigured. + + If you wish to change the MAC address, you can set it with +ifconfig: + +# ifconfig bond0 hw ether 00:11:22:33:44:55 + + The MAC address can be also changed by bringing down/up the +device and then changing its slaves (or their order): + +# ifconfig bond0 down ; modprobe -r bonding +# ifconfig bond0 .... up +# ifenslave bond0 eth... + This method will automatically take the address from the next +slave that is added. -3) Adapting to your switches' timing ------------------------------------- -If your switches take a long time to go into backup mode, it may be -desirable not to activate a backup interface immediately after a link goes -down. It is possible to delay the moment at which a link will be -completely disabled by passing the module parameter "downdelay" (in -milliseconds, must be a multiple of miimon). - -When a switch reboots, it is possible that its ports report "link up" status -before they become usable. This could fool a bond device by causing it to -use some ports that are not ready yet. It is possible to delay the moment at -which an active link will be reused by passing the module parameter "updelay" -(in milliseconds, must be a multiple of miimon). - -A similar situation can occur when a host re-negotiates a lost link with the -switch (a case of cable replacement). - -A special case is when a bonding interface has lost all slave links. Then the -driver will immediately reuse the first link that goes up, even if updelay -parameter was specified. (If there are slave interfaces in the "updelay" state, -the interface that first went into that state will be immediately reused.) This -allows to reduce down-time if the value of updelay has been overestimated. - -Examples : - - # modprobe bonding miimon=100 mode=1 downdelay=2000 updelay=5000 - # modprobe bonding miimon=100 mode=balance-rr downdelay=0 updelay=5000 - - -Promiscuous Sniffing notes -========================== - -If you wish to bond channels together for a network sniffing -application --- you wish to run tcpdump, or ethereal, or an IDS like -snort, with its input aggregated from multiple interfaces using the -bonding driver --- then you need to handle the Promiscuous interface -setting by hand. Specifically, when you "ifconfing bond0 up" you -must add the promisc flag there; it will be propagated down to the -slave interfaces at ifenslave time; a full example might look like: - - ifconfig bond0 promisc up - for if in eth1 eth2 ...;do - ifconfig $if up - ifenslave bond0 $if - done - snort ... -i bond0 ... - -Ifenslave also wants to propagate addresses from interface to -interface, appropriately for its design functions in HA and channel -capacity aggregating; but it works fine for unnumbered interfaces; -just ignore all the warnings it emits. + To restore your slaves' MAC addresses, you need to detach them +from the bond (`ifenslave -d bond0 eth0'). The bonding driver will +then restore the MAC addresses that the slaves had before they were +enslaved. +15. Resources and Links +======================= -8021q VLAN support -================== +The latest version of the bonding driver can be found in the latest +version of the linux kernel, found on http://kernel.org -It is possible to configure VLAN devices over a bond interface using the 8021q -driver. However, only packets coming from the 8021q driver and passing through -bonding will be tagged by default. Self generated packets, like bonding's -learning packets or ARP packets generated by either ALB mode or the ARP -monitor mechanism, are tagged internally by bonding itself. As a result, -bonding has to "learn" what VLAN IDs are configured on top of it, and it uses -those IDs to tag self generated packets. - -For simplicity reasons, and to support the use of adapters that can do VLAN -hardware acceleration offloding, the bonding interface declares itself as -fully hardware offloaing capable, it gets the add_vid/kill_vid notifications -to gather the necessary information, and it propagates those actions to the -slaves. -In case of mixed adapter types, hardware accelerated tagged packets that should -go through an adapter that is not offloading capable are "un-accelerated" by the -bonding driver so the VLAN tag sits in the regular location. - -VLAN interfaces *must* be added on top of a bonding interface only after -enslaving at least one slave. This is because until the first slave is added the -bonding interface has a HW address of 00:00:00:00:00:00, which will be copied by -the VLAN interface when it is created. - -Notice that a problem would occur if all slaves are released from a bond that -still has VLAN interfaces on top of it. When later coming to add new slaves, the -bonding interface would get a HW address from the first slave, which might not -match that of the VLAN interfaces. It is recommended that either all VLANs are -removed and then re-added, or to manually set the bonding interface's HW -address so it matches the VLAN's. (Note: changing a VLAN interface's HW address -would set the underlying device -- i.e. the bonding interface -- to promiscouos -mode, which might not be what you want). - - -Limitations -=========== -The main limitations are : - - only the link status is monitored. If the switch on the other side is - partially down (e.g. doesn't forward anymore, but the link is OK), the link - won't be disabled. Another way to check for a dead link could be to count - incoming frames on a heavily loaded host. This is not applicable to small - servers, but may be useful when the front switches send multicast - information on their links (e.g. VRRP), or even health-check the servers. - Use the arp_interval/arp_ip_target parameters to count incoming/outgoing - frames. +Discussions regarding the bonding driver take place primarily on the +bonding-devel mailing list, hosted at sourceforge.net. If you have +questions or problems, post them to the list. +bonding-devel@lists.sourceforge.net +https://lists.sourceforge.net/lists/listinfo/bonding-devel -Resources and Links -=================== +There is also a project site on sourceforge. -Current development on this driver is posted to: - - http://www.sourceforge.net/projects/bonding/ +http://www.sourceforge.net/projects/bonding Donald Becker's Ethernet Drivers and diag programs may be found at : - http://www.scyld.com/network/ -You will also find a lot of information regarding Ethernet, NWay, MII, etc. at -www.scyld.com. - -Patches for 2.2 kernels are at Willy Tarreau's site : - - http://wtarreau.free.fr/pub/bonding/ - - http://www-miaif.lip6.fr/~tarreau/pub/bonding/ - -To get latest informations about Linux Kernel development, please consult -the Linux Kernel Mailing List Archives at : - http://www.ussg.iu.edu/hypermail/linux/kernel/ +You will also find a lot of information regarding Ethernet, NWay, MII, +etc. at www.scyld.com. -- END -- From Stig.Venaas@uninett.no Fri Feb 11 01:21:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:21:12 -0800 (PST) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9L8oN022351 for ; Fri, 11 Feb 2005 01:21:08 -0800 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:e000:0:290:27ff:fe22:7186]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j1B9L7UL027155 for ; Fri, 11 Feb 2005 10:21:07 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.12.11/8.12.9) with ESMTP id j1B9L7LA012458 for ; Fri, 11 Feb 2005 10:21:07 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.12.11/8.12.11/Submit) id j1B9L7eO012457 for netdev@oss.sgi.com; Fri, 11 Feb 2005 10:21:07 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 11 Feb 2005 10:21:07 +0100 From: Stig Venaas To: netdev@oss.sgi.com Subject: Problem with recvmsg() and IPV6_PKTINFO Message-ID: <20050211092107.GB12377@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Stig.Venaas@uninett.no Precedence: bulk X-list: netdev Content-Length: 860 Lines: 24 By setting IPV6_PKTINFO (or IPV6_RECVPKTINFO) on a socket one should be able to use recvmsg() to receive a datagram and get the destination address as ancillary data. I've found that on Linux (checked 2.4, 2.6 and USAGI cvs) this only happens if msg_name in the msghdr structure is set. In kernel's udpv6_recvmsg() you can see that datagram_recv_ctl() is only called if msg->msg_name is set. I don't think one should need to set msg_name for this to work. The specs (RFC 3542 and the Single UNIX Specification) talks about msg_name being optional, it never says that msg_name is needed for this to work. This problem is when receiving UDP on a regular socket, that is: socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP) It works without setting msg_name for IPv4 and also raw sockets. I also checked on FreeBSD. You don't need to set msg_name there either. Stig From yoshfuji@linux-ipv6.org Fri Feb 11 01:38:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 01:38:06 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B9c0m6023195 for ; Fri, 11 Feb 2005 01:38:00 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8E11A33CC2; Fri, 11 Feb 2005 18:39:06 +0900 (JST) Date: Fri, 11 Feb 2005 18:38:59 +0900 (JST) Message-Id: <20050211.183859.77973026.yoshfuji@linux-ipv6.org> To: Stig.Venaas@uninett.no, davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Problem with recvmsg() and IPV6_PKTINFO From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050211092107.GB12377@storhaugen.uninett.no> References: <20050211092107.GB12377@storhaugen.uninett.no> 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1520 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: 1737 Lines: 58 In article <20050211092107.GB12377@storhaugen.uninett.no> (at Fri, 11 Feb 2005 10:21:07 +0100), Stig Venaas says: > I've found that on Linux (checked 2.4, 2.6 and USAGI cvs) this only > happens if msg_name in the msghdr structure is set. In kernel's > udpv6_recvmsg() you can see that datagram_recv_ctl() is only called if > msg->msg_name is set. Please try this. Thanks. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/udp.c 1.80 vs edited ===== --- 1.80/net/ipv6/udp.c 2005-01-11 13:46:44 +09:00 +++ edited/net/ipv6/udp.c 2005-02-11 18:36:08 +09:00 @@ -219,6 +219,7 @@ int noblock, int flags, int *addr_len) { struct ipv6_pinfo *np = inet6_sk(sk); + struct inet_sock *inet = inet_sk(sk); struct sk_buff *skb; size_t copied; int err; @@ -268,21 +269,22 @@ sin6->sin6_flowinfo = 0; sin6->sin6_scope_id = 0; - if (skb->protocol == htons(ETH_P_IP)) { - struct inet_sock *inet = inet_sk(sk); - + if (skb->protocol == htons(ETH_P_IP)) ipv6_addr_set(&sin6->sin6_addr, 0, 0, htonl(0xffff), skb->nh.iph->saddr); - if (inet->cmsg_flags) - ip_cmsg_recv(msg, skb); - } else { + else { ipv6_addr_copy(&sin6->sin6_addr, &skb->nh.ipv6h->saddr); - - if (np->rxopt.all) - datagram_recv_ctl(sk, msg, skb); if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) sin6->sin6_scope_id = IP6CB(skb)->iif; } + + } + if (skb->protocol == htons(ETH_P_IP)) { + if (inet->cmsg_flags) + ip_cmsg_recv(msg, skb); + } else { + if (np->rxopt.all) + datagram_recv_ctl(sk, msg, skb); } err = copied; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ecalicchio@yahoo.it Fri Feb 11 03:03:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 03:03:35 -0800 (PST) Received: from web26806.mail.ukl.yahoo.com (web26806.mail.ukl.yahoo.com [217.146.176.82]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1BB3RDn027246 for ; Fri, 11 Feb 2005 03:03:28 -0800 Received: (qmail 73047 invoked by uid 60001); 11 Feb 2005 11:03:21 -0000 Message-ID: <20050211110321.73045.qmail@web26806.mail.ukl.yahoo.com> Received: from [151.41.232.28] by web26806.mail.ukl.yahoo.com via HTTP; Fri, 11 Feb 2005 12:03:21 CET Date: Fri, 11 Feb 2005 12:03:21 +0100 (CET) From: Emilio Calicchio Subject: questions about ipsec-tools-0.4 and linux kernel 2.6 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ecalicchio@yahoo.it Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 33 I am a student of engineering in first university of Rome (“La Sapienza”) and I’m working to my degree thesis whose title is: “End-to-end real-time applications performance measurements on VPN network (both terrestrial and satellite), blocks encryption algorithms vs stream cipher ones.” Since I have to use a Linux based test bed, I must integrate the stream cipher algorithms (like Scream and Seal cipher algorithm)in the Linux ipsec implementation; at aim I wonder whether you can help me by providing the following information: Architectural description of the ipsec Linux implementation (both tools and kernel modules) the files of kernel version 2.6 and ipsec-tools-0.4 that I should modify in order to add chiper stream algorithm if someone else is facing the same topic. Thanks for your help Best regards CALICCHIO EMILIO ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From tmattox@gmail.com Fri Feb 11 04:49:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 04:49:55 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BCnjt3001537 for ; Fri, 11 Feb 2005 04:49:45 -0800 Received: by rproxy.gmail.com with SMTP id r35so266136rna for ; Fri, 11 Feb 2005 04:49:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gzlgN9t4nJRRPV3h3rFStBhiflMXv9/NjLh3XdnVIzGfU7d5KROKFTbrnzhpmhGPKDQCIBrtSdoNSrquYF1qtoIGAxHyl8gLSYC/YqCzNBwsJNK6p6V1k7Mp6AyWTgjKq1BRuHKMCBKmaXOoBBqquVbaEOZiTcqx6X7ZucmwKdQ= Received: by 10.38.74.27 with SMTP id w27mr154012rna; Fri, 11 Feb 2005 04:49:44 -0800 (PST) Received: by 10.38.76.25 with HTTP; Fri, 11 Feb 2005 04:49:44 -0800 (PST) Message-ID: Date: Fri, 11 Feb 2005 07:49:44 -0500 From: Tim Mattox Reply-To: Tim Mattox To: Jay Vosburgh Subject: Re: [PATCH 2.6.11-rc3 5/5] bonding: Update/rewrite bonding.txt Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <200502110918.j1B9If7r003696@death.nxdomain.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502110918.j1B9If7r003696@death.nxdomain.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@gmail.com Precedence: bulk X-list: netdev Content-Length: 647 Lines: 18 Hi Jay, Are you going to add some text about the original use of bonding in balanced-rr mode with isolated switches that we had discussed at the end of Jan.? This method is still used in Beowulf clusters for high performance as apposed to high availability. BTW - I really like the new detail on configuring bonding for the various Linux distributions. Great work! On Fri, 11 Feb 2005 01:18:41 -0800, Jay Vosburgh wrote: > > This is a complete overhaul of the bonding.txt documentation. > > Signed-off-by: Jay Vosburgh [snip] -- Tim Mattox - tmattox@gmail.com - http://homepage.mac.com/tmattox/ From junk@toutatis.be Fri Feb 11 05:51:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 05:51:43 -0800 (PST) Received: from toutatis.be (212.68.249.80.brutele.be [212.68.249.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1BDpbWs005518 for ; Fri, 11 Feb 2005 05:51:38 -0800 Received: (qmail 6931 invoked from network); 11 Feb 2005 12:39:44 -0000 Received: from localhost (HELO toutatis.be) (127.0.0.1) by 0 with SMTP; 11 Feb 2005 12:39:44 -0000 From: "junk" To: netdev@oss.sgi.com Reply-To: "junk" Subject: ipt_ROUTE and destination MAC address Date: Fri, 11 Feb 2005 13:39:38 +0100 Message-Id: <20050211123718.M74819@toutatis.be> References: X-Mailer: Open WebMail 2.32 20040525 X-OriginatingIP: 195.207.101.27 (junk) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: junk@toutatis.be Precedence: bulk X-list: netdev Content-Length: 729 Lines: 22 Hello, i'm coding a virtual interface. That virtual interface has to receive packets coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can see my packets arriving on red0 (my virtual interface). But there is a problem.. If i send an icmp request to 10.0.1.1 from another computer: The icmp request arrives on the physical interface, ROUTE target makes it arrive on red0 icmp request arriving on red0: 10.0.0.1 The problem is that the destination MAC is the one of eth0, so, it seems the kernel doesn't really deliver the packet to my driver. I can see it in tcpdump but my driver receive function is never called. I tried every -j ROUTE option, --gw or --iif, with --continue, or not.. Any idea? From dan@coverfire.com Fri Feb 11 07:08:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 07:08:08 -0800 (PST) Received: from otis.cyg.net (otis.cyg.net [69.41.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BF82Qq008740 for ; Fri, 11 Feb 2005 07:08:03 -0800 Received: from ganymede.coverfire.com (ganymede.coverfire.com [69.41.199.10]) (authenticated bits=0) by otis.cyg.net (8.12.11/8.12.11) with ESMTP id j1BF7PcM017045; Fri, 11 Feb 2005 10:07:25 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: Dan Siemon To: netdev@oss.sgi.com Cc: hadi@cyberus.ca In-Reply-To: <1106747313.1107.7.camel@jzny.localdomain> References: <20050117165626.GE26856@postel.suug.ch> <1106002197.1046.19.camel@jzny.localdomain> <20050118134406.GR26856@postel.suug.ch> <1106058592.1035.95.camel@jzny.localdomain> <20050118145830.GS26856@postel.suug.ch> <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> Content-Type: text/plain Date: Fri, 11 Feb 2005 10:07:26 -0500 Message-Id: <1108134446.5523.22.camel@ganymede> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dan@coverfire.com Precedence: bulk X-list: netdev Content-Length: 1308 Lines: 30 On Wed, 2005-26-01 at 08:48 -0500, jamal wrote: > Your call really - you are the one who is going to maintain it;-> > As for ease of use and avoiding users from knowing details of how > tlvs are put together etc - i think it doesnt matter how thats done > underneath the hood; it is still doable on top of current libnetlink. In > other words whats required, IMO, is something that hides netlink totaly > so that the programmer/user doesnt even get to see TLVs. (Sorry to join this thread so late.) I'd like to make a little plug for my Linux QoS Library (LQL) [1] project. LQL provides an abstraction of the kernel QoS features. Full API documentation is available from the website. I already have working bindings for one high level language (C# on Mono) [2]. Creating bindings for Python, Perl etc should be quite easy. Someone recently emailed me about starting work on Perl bindings. There is still lots of work to do. Support for more QDiscs and classifiers is needed and the socket handling code needs a rewrite to better handle errors. Work continues and these things will be fixed. [1] - http://www.coverfire.com/lql/ [2] - http://www.coverfire.com/lql-sharp/ -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 From junk@toutatis.be Fri Feb 11 07:29:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 07:29:12 -0800 (PST) Received: from toutatis.be (212.68.249.80.brutele.be [212.68.249.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1BFT5VP009567 for ; Fri, 11 Feb 2005 07:29:05 -0800 Received: (qmail 10928 invoked from network); 11 Feb 2005 14:17:17 -0000 Received: from localhost (HELO toutatis.be) (127.0.0.1) by 0 with SMTP; 11 Feb 2005 14:17:17 -0000 From: "junk" To: netdev@oss.sgi.com Subject: Re: ipt_ROUTE and destination MAC address Date: Fri, 11 Feb 2005 15:17:12 +0100 Message-Id: <20050211140611.M58411@toutatis.be> In-Reply-To: References: <20050210141334.M57687@toutatis.be> X-Mailer: Open WebMail 2.32 20040525 X-OriginatingIP: 195.207.101.27 (junk) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: junk@toutatis.be Precedence: bulk X-list: netdev Content-Length: 2505 Lines: 63 On Fri, 11 Feb 2005 01:07:55 +0100 (CET), Henrik Nordstrom wrote > On Thu, 10 Feb 2005, junk wrote: > > > i'm coding a virtual interface. That virtual interface has to receive packets > > coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can > > see my packets arriving on red0 (my virtual interface). > > > > The problem is that the destination MAC is the one of eth0, so, it seems the > > kernel doesn't really deliver the packet to my driver. I can see it in tcpdump > > but my driver receive function is never called. > > It is not due to the destination MAC, but to what ipt_ROUTE does. > > ipt_ROUTE reoutes the packet as if it came in on the other interface, > all done at the IP layer in the kernel, it does not resubmit the > packet to the driver level. > > The MAC is not modified as this is not relevant to the IP layer, and > there really isn't any reason why it should be modified either. The > MAC used in received skbufs is the MAC the sending station was > addressing the packet to, not the MAC of the receiving interface. > Usually they are the same, but not always. > > Can you give an more detailed example of what it is you are trying > to accomplish or why you need a custom virtual interface driver? It > is possible (or even likely) there is other better tools for the job. > > Also I am a little confused on your virtual interface driver. > Normally virtual interface drivers does not have a receive function, > only a transmit function called when packets are routed to be > transmitted on the interface.. How you make packets arrive at the > interface driver is up to you (emulated hardware or whatever). > > Regards > Henrik > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" > in the body of a message to majordomo@vger.kernel.org More majordomo > info at http://vger.kernel.org/majordomo-info.html The purpose is to run a redundant network. My virtual interface has to duplicate packets it receive from software, and send each copy of it on eth0 and eth1 respectively. From the application, there is only one interface: red0. red0 has to: - duplicate packets having red0 as outgoing interface (real output iface are eth0/eth1) - receive packets from eth0/eth1, discarding the copy (as eth0 and eth1 receive the same data), pass the packet to application - alert userland if eth0 or eth1 comes down The problem is that I want my driver to know about incoming packets, not only the software. From vincent.roqueta@ext.bull.net Fri Feb 11 08:02:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 08:02:28 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BG2JqU011248 for ; Fri, 11 Feb 2005 08:02:22 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 3D50419D906; Fri, 11 Feb 2005 17:02:17 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01829-02; Fri, 11 Feb 2005 17:02:15 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 2DDCC19D908; Fri, 11 Feb 2005 17:02:15 +0100 (CET) Received: from frecb000719.frec.bull.fr ([129.183.101.52]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005021117105826:1703 ; Fri, 11 Feb 2005 17:10:58 +0100 From: Vincent Roqueta Organization: BULL SA To: netdev@oss.sgi.com Subject: IP More Fragements bit problem. Date: Fri, 11 Feb 2005 17:08:16 +0100 User-Agent: KMail/1.6.1 Cc: Trond Myklebust , Tony Reix MIME-Version: 1.0 Message-Id: <200502111708.16024.vincent.roqueta@ext.bull.net> X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 11/02/2005 17:10:58, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 11/02/2005 17:11:00, Serialize complete at 11/02/2005 17:11:00 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent.roqueta@ext.bull.net Precedence: bulk X-list: netdev Content-Length: 874 Lines: 50 Hello all, I am working on NFSv4 and I found an IP problem while doing interoperability testing with AIX. The More Fragements (MF) bits is set on the last packet sent in a list of packets that sould be reassembled For example : If we get the A, B, C, D packets that may be reassembled into ABCD we sould have A + MF B + MF C + MF D On kernel 2.6.10rc2 and laters (last tested is 2.6.11-rc3) we have: A + MF B + MF C + MF D + MF That cause AIX waiting for the last packet with out sending ack So Linux suppose AIX didn't receive all, and re send all packets. So AIX is receiving that: A + MF B + MF C + MF D + MF *DELAY * A + MF B + MF C + MF D + MF *DELAY* A + MF B + MF C + MF D + MF *DELAY* ... After a while AIX destroy first fragments because of the IP fragements life time. Trond Myklebust said me you can do anything for that? Cher, Vincent ROQUETA From fubar@us.ibm.com Fri Feb 11 09:14:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 09:14:40 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BHERG8016700 for ; Fri, 11 Feb 2005 09:14:36 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1BHEMuA827780 for ; Fri, 11 Feb 2005 12:14:22 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1BHEL2x308712 for ; Fri, 11 Feb 2005 10:14:21 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BHELUN028455 for ; Fri, 11 Feb 2005 10:14:21 -0700 Received: from death.nxdomain.ibm.com (sig-9-65-41-190.mts.ibm.com [9.65.41.190]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BHEAc8028085; Fri, 11 Feb 2005 10:14:20 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1BHDcNn005684; Fri, 11 Feb 2005 09:13:47 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1BHDb9P005677; Fri, 11 Feb 2005 09:13:38 -0800 Message-Id: <200502111713.j1BHDb9P005677@death.nxdomain.ibm.com> To: Tim Mattox cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11-rc3 5/5] bonding: Update/rewrite bonding.txt In-Reply-To: Message from Tim Mattox of "Fri, 11 Feb 2005 07:49:44 EST." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Feb 2005 09:13:37 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 539 Lines: 17 Tim Mattox wrote: [...] >Are you going to add some text about the original >use of bonding in balanced-rr mode with isolated >switches that we had discussed at the end of Jan.? >This method is still used in Beowulf clusters for >high performance as apposed to high availability. Yep. I haven't forgotten about it, just haven't written it up yet. I've got a couple of other things to add as well, but all of that can be done as patches later. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From ak@muc.de Fri Feb 11 10:24:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 10:24:49 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BIOi1p019275 for ; Fri, 11 Feb 2005 10:24:44 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id E395FD033E; Fri, 11 Feb 2005 19:24:42 +0100 (CET) To: Vincent Roqueta Cc: Trond Myklebust , Tony Reix , netdev@oss.sgi.com Subject: Re: IP More Fragements bit problem. References: <200502111708.16024.vincent.roqueta@ext.bull.net> From: Andi Kleen Date: Fri, 11 Feb 2005 19:24:42 +0100 In-Reply-To: <200502111708.16024.vincent.roqueta@ext.bull.net> (Vincent Roqueta's message of "Fri, 11 Feb 2005 17:08:16 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1528 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: 952 Lines: 31 Vincent Roqueta writes: > D + MF > *DELAY* > A + MF > B + MF > C + MF > D + MF > *DELAY* > ... > > After a while AIX destroy first fragments because of the IP fragements life > time. Trond Myklebust said me you can do anything for that? Are you sure? I tested 2.6.10rc3 and it works correctly for me with ping. The algorithm in ip_fragment() looks good too from visual inspection. And ping uses the same code to fragment as NFS sunrpc over UDP. 19:15:24.100934 averell > trent: (frag 64564:1480@1480+) 19:15:24.100938 averell > trent: (frag 64564:1480@2960+) 19:15:24.100943 averell > trent: (frag 64564:1480@4440+) 19:15:24.100947 averell > trent: (frag 64564:1480@5920+) 19:15:24.100951 averell > trent: (frag 64564:1480@7400+) 19:15:24.100957 averell > trent: (frag 64564:1128@8880) <--- No MF. Also why are you testing NFSv4 over UDP anyways? I thought everybody was finally running it over TCP now. -Andi From niv@us.ibm.com Fri Feb 11 10:44:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 10:45:02 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BIiqms019912 for ; Fri, 11 Feb 2005 10:44:59 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1BIik6L583990 for ; Fri, 11 Feb 2005 13:44:46 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1BIijHb443894 for ; Fri, 11 Feb 2005 11:44:45 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BIiiVo016431 for ; Fri, 11 Feb 2005 11:44:45 -0700 Received: from [9.47.22.79] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.79]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BIii91016390; Fri, 11 Feb 2005 11:44:44 -0700 Message-ID: <420CFD1F.2060701@us.ibm.com> Date: Fri, 11 Feb 2005 10:44:47 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Roqueta CC: netdev@oss.sgi.com, Trond Myklebust , Tony Reix Subject: Re: IP More Fragements bit problem. References: <200502111708.16024.vincent.roqueta@ext.bull.net> In-Reply-To: <200502111708.16024.vincent.roqueta@ext.bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1529 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: 453 Lines: 24 Vincent Roqueta wrote: > On kernel 2.6.10rc2 and laters (last tested is 2.6.11-rc3) we have: > > A + MF > B + MF > C + MF > D + MF > > That cause AIX waiting for the last packet with out sending ack > So Linux suppose AIX didn't receive all, and re send all packets. > So AIX is receiving that: > A + MF > B + MF > C + MF > D + MF > *DELAY * Silly question, but are you absolutely sure that the original wasn't actually ABCDE? thanks, Nivedita From mchan@broadcom.com Fri Feb 11 12:44:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 12:44:42 -0800 (PST) Received: from MMS3.broadcom.com (mms-nat.broadcom.com [63.70.210.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BKiUYn027299 for ; Fri, 11 Feb 2005 12:44:30 -0800 Received: from 63.70.210.1 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 11 Feb 2005 12:44:10 -0800 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 11 Feb 2005 12:44:16 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AKK60873; Fri, 11 Feb 2005 12:44:11 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA00732; Fri, 11 Feb 2005 12:44:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH] tg3: capacitive coupling detection fix Date: Fri, 11 Feb 2005 12:44:10 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH] tg3: capacitive coupling detection fix thread-index: AcUQenBthEVwCOEDSUG7grDnD7JTOg== From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, "john stultz" X-WSS-ID: 6E13C6902WC2342986-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5107A.707CC563" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2624 Lines: 56 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5107A.707CC563 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This patch fixes the problem reported in: http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D110798711911645&w=3D2 The 5700 link problem was caused by reading uninitialized values in sram = and causing capacitive coupling mode to be enabled by mistake. This patch = fixes the problem by properly validating the sram contents. Signed-off-by: Michael Chan ------_=_NextPart_001_01C5107A.707CC563 Content-Type: application/octet-stream; name=tg3_cap_cpling.patch Content-Transfer-Encoding: base64 Content-Description: tg3_cap_cpling.patch Content-Disposition: attachment; filename=tg3_cap_cpling.patch ZGlmZiAtTnJ1IDIvdGczLmMgMy90ZzMuYwotLS0gMi90ZzMuYwkyMDA1LTAyLTEwIDEwOjIyOjM5 LjAwMDAwMDAwMCAtMDgwMAorKysgMy90ZzMuYwkyMDA1LTAyLTEwIDEwOjI2OjQyLjAwMDAwMDAw MCAtMDgwMApAQCAtNzUxNSwxMiArNzUxNSwxOCBAQAogCXRnM19yZWFkX21lbSh0cCwgTklDX1NS QU1fREFUQV9TSUcsICZ2YWwpOwogCWlmICh2YWwgPT0gTklDX1NSQU1fREFUQV9TSUdfTUFHSUMp IHsKIAkJdTMyIG5pY19jZmcsIGxlZF9jZmc7Ci0JCXUzMiBuaWNfcGh5X2lkLCBjZmcyOworCQl1 MzIgbmljX3BoeV9pZCwgdmVyLCBjZmcyID0gMDsKIAogCQl0ZzNfcmVhZF9tZW0odHAsIE5JQ19T UkFNX0RBVEFfQ0ZHLCAmbmljX2NmZyk7CiAJCXRwLT5uaWNfc3JhbV9kYXRhX2NmZyA9IG5pY19j Zmc7CiAKLQkJdGczX3JlYWRfbWVtKHRwLCBOSUNfU1JBTV9EQVRBX0NGR18yLCAmY2ZnMik7CisJ CXRnM19yZWFkX21lbSh0cCwgTklDX1NSQU1fREFUQV9WRVIsICZ2ZXIpOworCQl2ZXIgPj49IE5J Q19TUkFNX0RBVEFfVkVSX1NISUZUOworCQlpZiAoKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBf cmV2X2lkKSAhPSBBU0lDX1JFVl81NzAwKSAmJgorCQkgICAgKEdFVF9BU0lDX1JFVih0cC0+cGNp X2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzAxKSAmJgorCQkgICAgKEdFVF9BU0lDX1JFVih0 cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzAzKSAmJgorCQkgICAgKHZlciA+IDAp ICYmICh2ZXIgPCAweDEwMCkpCisJCQl0ZzNfcmVhZF9tZW0odHAsIE5JQ19TUkFNX0RBVEFfQ0ZH XzIsICZjZmcyKTsKIAogCQllZXByb21fc2lnbmF0dXJlX2ZvdW5kID0gMTsKIApkaWZmIC1OcnUg Mi90ZzMuaCAzL3RnMy5oCi0tLSAyL3RnMy5oCTIwMDUtMDItMTAgMTA6MjI6NDMuMDAwMDAwMDAw IC0wODAwCisrKyAzL3RnMy5oCTIwMDUtMDItMTAgMTA6MjY6NDQuMDAwMDAwMDAwIC0wODAwCkBA IC0xNDUyLDYgKzE0NTIsOSBAQAogI2RlZmluZSAgTklDX1NSQU1fREFUQV9DRkdfRklCRVJfV09M CQkgMHgwMDAwNDAwMAogI2RlZmluZSAgTklDX1NSQU1fREFUQV9DRkdfTk9fR1BJTzIJCSAweDAw MTAwMDAwCiAKKyNkZWZpbmUgTklDX1NSQU1fREFUQV9WRVIJCQkweDAwMDAwYjVjCisjZGVmaW5l ICBOSUNfU1JBTV9EQVRBX1ZFUl9TSElGVAkJIDE2CisKICNkZWZpbmUgTklDX1NSQU1fREFUQV9Q SFlfSUQJCTB4MDAwMDBiNzQKICNkZWZpbmUgIE5JQ19TUkFNX0RBVEFfUEhZX0lEMV9NQVNLCSAw eGZmZmYwMDAwCiAjZGVmaW5lICBOSUNfU1JBTV9EQVRBX1BIWV9JRDJfTUFTSwkgMHgwMDAwZmZm Zgo= ------_=_NextPart_001_01C5107A.707CC563-- From dcbw@redhat.com Fri Feb 11 13:10:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:10:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BL9wVR028271 for ; Fri, 11 Feb 2005 13:10:02 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1BL9u3M014130; Fri, 11 Feb 2005 16:09:56 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1BL9uO30444; Fri, 11 Feb 2005 16:09:56 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1BL9tZg020990; Fri, 11 Feb 2005 16:09:55 -0500 Subject: [PATCH 2.6.11-rc3] wireless: airo WEXT and quality corrections From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, breed@users.sourceforge.net, davem@davemloft.net Content-Type: text/plain Date: Fri, 11 Feb 2005 16:09:55 -0500 Message-Id: <1108156195.21113.20.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 10327 Lines: 313 This patch brings the airo driver into line with the current WEXT specification of signal quality. It also fixes the values used to determine signal quality and level for MPI & PCMCIA 350 cards. It turns out that BSSListRid.rssi was actually in dBm for 350 series cards, and that we can use the normalized signal strength reported by the card as our "quality" value, on a scale of 0 - 100. Since signal level values are in dBm for this driver, max_qual->level MUST be 0, as specified in the WEXT spec. This patch also uses the IW_QUAL constants new in WEXT version 17. Signed-off-by: Dan Williams ' --- a/drivers/net/wireless/airo.c 2005-02-10 18:36:58.000000000 -0500 +++ a/drivers/net/wireless/airo.c 2005-02-11 15:45:19.000000000 -0500 @@ -754,7 +754,7 @@ u8 zero; u8 ssidLen; u8 ssid[32]; - u16 rssi; + u16 dBm; #define CAP_ESS (1<<0) #define CAP_IBSS (1<<1) #define CAP_PRIVACY (1<<4) @@ -1125,6 +1125,9 @@ static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer *buffer, int len); static int decapsulate(struct airo_info *ai, MICBuffer *mic, etherHead *pPacket, u16 payLen); +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi); +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm); + #include #endif @@ -1714,6 +1717,7 @@ list->fh.dwell = le16_to_cpu(list->fh.dwell); list->dsChannel = le16_to_cpu(list->dsChannel); list->atimWindow = le16_to_cpu(list->atimWindow); + list->dBm = le16_to_cpu(list->dBm); return rc; } @@ -3248,7 +3252,10 @@ wstats.level = 0x100 - apriv->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = apriv->wstats.qual.noise; + wstats.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_QUAL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(dev, sa, &wstats); } @@ -3591,7 +3598,10 @@ wstats.level = 0x100 - ai->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = ai->wstats.qual.noise; + wstats.updated = IW_QUAL_QUAL_UPDATED + | IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(ai->dev, sa, &wstats); } @@ -3682,7 +3692,7 @@ status = PC4500_readrid(ai,RID_RSSI,&rssi_rid,sizeof(rssi_rid),lock); if ( status == SUCCESS ) { if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) != NULL) - memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); + memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); /* Skip RID length member */ } else { if (ai->rssi) { @@ -5351,7 +5361,7 @@ (int)BSSList_rid.bssid[5], (int)BSSList_rid.ssidLen, BSSList_rid.ssid, - (int)BSSList_rid.rssi); + (int)BSSList_rid.dBm); ptr += sprintf(ptr, " channel = %d %s %s %s %s\n", (int)BSSList_rid.dsChannel, BSSList_rid.cap & CAP_ESS ? "ESS" : "", @@ -5596,6 +5606,29 @@ * would not work at all... - Jean II */ +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi) +{ + if( !rssi_rid ) + return 0; + + return (0x100 - rssi_rid[rssi].rssidBm); +} + +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm) +{ + int i; + + if( !rssi_rid ) + return 0; + + for( i = 0; i < 256; i++ ) + if (rssi_rid[i].rssidBm == dbm) + return rssi_rid[i].rssipct; + + return 0; +} + + static int airo_get_quality (StatusRid *status_rid, CapabilityRid *cap_rid) { int quality = 0; @@ -6446,11 +6479,29 @@ } range->num_frequency = k; + range->sensitivity = 65535; + /* Hum... Should put the right values there */ - range->max_qual.qual = airo_get_max_quality(&cap_rid); - range->max_qual.level = 0x100 - 120; /* -120 dBm */ + if (local->rssi) + range->max_qual.qual = 100; /* % */ + else + range->max_qual.qual = airo_get_max_quality(&cap_rid); + range->max_qual.level = 0; /* 0 means we use dBm */ range->max_qual.noise = 0; - range->sensitivity = 65535; + range->max_qual.updated = 0; + + /* Experimental measurements - boundary 11/5.5 Mb/s */ + /* Note : with or without the (local->rssi), results + * are somewhat different. - Jean II */ + if (local->rssi) { + range->avg_qual.qual = 50; /* % */ + range->avg_qual.level = 186; /* -70 dBm */ + } else { + range->avg_qual.qual = airo_get_avg_quality(&cap_rid); + range->avg_qual.level = 176; /* -80 dBm */ + } + range->avg_qual.noise = 0; + range->avg_qual.updated = 0; for(i = 0 ; i < 8 ; i++) { range->bitrate[i] = cap_rid.supportedRates[i] * 500000; @@ -6511,15 +6562,6 @@ range->max_retry = 65535; range->min_r_time = 1024; range->max_r_time = 65535 * 1024; - /* Experimental measurements - boundary 11/5.5 Mb/s */ - /* Note : with or without the (local->rssi), results - * are somewhat different. - Jean II */ - range->avg_qual.qual = airo_get_avg_quality(&cap_rid); - if (local->rssi) - range->avg_qual.level = 186; /* -70 dBm */ - else - range->avg_qual.level = 176; /* -80 dBm */ - range->avg_qual.noise = 0; /* Event capability (kernel + driver) */ range->event_capa[0] = (IW_EVENT_CAPA_K_0 | @@ -6679,12 +6721,18 @@ loseSync = 0; memcpy(address[i].sa_data, BSSList.bssid, ETH_ALEN); address[i].sa_family = ARPHRD_ETHER; - if (local->rssi) - qual[i].level = 0x100 - local->rssi[BSSList.rssi].rssidBm; - else - qual[i].level = (BSSList.rssi + 321) / 2; - qual[i].qual = qual[i].noise = 0; - qual[i].updated = 2; + if (local->rssi) { + qual[i].level = 0x100 - BSSList.dBm; + qual[i].qual = airo_dbm_to_pct( local->rssi, BSSList.dBm ); + qual[i].updated = IW_QUAL_QUAL_UPDATED; + } else { + qual[i].level = (BSSList.dBm + 321) / 2; + qual[i].qual = 0; + qual[i].updated = IW_QUAL_QUAL_INVALID; + } + qual[i].noise = local->wstats.qual.noise; + qual[i].updated |= IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; if (BSSList.index == 0xffff) break; } @@ -6763,7 +6811,7 @@ static inline char *airo_translate_scan(struct net_device *dev, char *current_ev, char *end_buf, - BSSListRid *list) + BSSListRid *bss) { struct airo_info *ai = dev->priv; struct iw_event iwe; /* Temporary buffer */ @@ -6774,22 +6822,22 @@ /* First entry *MUST* be the AP MAC address */ iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; - memcpy(iwe.u.ap_addr.sa_data, list->bssid, ETH_ALEN); + memcpy(iwe.u.ap_addr.sa_data, bss->bssid, ETH_ALEN); current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); /* Other entries will be displayed in the order we give them */ /* Add the ESSID */ - iwe.u.data.length = list->ssidLen; + iwe.u.data.length = bss->ssidLen; if(iwe.u.data.length > 32) iwe.u.data.length = 32; iwe.cmd = SIOCGIWESSID; iwe.u.data.flags = 1; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Add mode */ iwe.cmd = SIOCGIWMODE; - capabilities = le16_to_cpu(list->cap); + capabilities = le16_to_cpu(bss->cap); if(capabilities & (CAP_ESS | CAP_IBSS)) { if(capabilities & CAP_ESS) iwe.u.mode = IW_MODE_MASTER; @@ -6800,19 +6848,25 @@ /* Add frequency */ iwe.cmd = SIOCGIWFREQ; - iwe.u.freq.m = le16_to_cpu(list->dsChannel); + iwe.u.freq.m = le16_to_cpu(bss->dsChannel); iwe.u.freq.m = frequency_list[iwe.u.freq.m] * 100000; iwe.u.freq.e = 1; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); /* Add quality statistics */ iwe.cmd = IWEVQUAL; - if (ai->rssi) - iwe.u.qual.level = 0x100 - ai->rssi[list->rssi].rssidBm; - else - iwe.u.qual.level = (list->rssi + 321) / 2; - iwe.u.qual.noise = 0; - iwe.u.qual.qual = 0; + if (ai->rssi) { + iwe.u.qual.level = 0x100 - bss->dBm; + iwe.u.qual.qual = airo_dbm_to_pct( ai->rssi, bss->dBm ); + iwe.u.qual.updated = IW_QUAL_QUAL_UPDATED; + } else { + iwe.u.qual.level = (bss->dBm + 321) / 2; + iwe.u.qual.qual = 0; + iwe.u.qual.updated = IW_QUAL_QUAL_INVALID; + } + iwe.u.qual.noise = ai->wstats.qual.noise; + iwe.u.qual.updated |= IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); /* Add encryption capability */ @@ -6822,7 +6876,7 @@ else iwe.u.data.flags = IW_ENCODE_DISABLED; iwe.u.data.length = 0; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Rate : stuffing multiple values in a single event require a bit * more of magic - Jean II */ @@ -6834,10 +6888,10 @@ /* Max 8 values */ for(i = 0 ; i < 8 ; i++) { /* NULL terminated */ - if(list->rates[i] == 0) + if(bss->rates[i] == 0) break; /* Bit rate given in 500 kb/s units (+ 0x80) */ - iwe.u.bitrate.value = ((list->rates[i] & 0x7f) * 500000); + iwe.u.bitrate.value = ((bss->rates[i] & 0x7f) * 500000); /* Add new value to event */ current_val = iwe_stream_add_value(current_ev, current_val, end_buf, &iwe, IW_EV_PARAM_LEN); } @@ -7156,18 +7210,22 @@ /* The status */ local->wstats.status = status_rid.mode; - /* Signal quality and co. But where is the noise level ??? */ - local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); - if (local->rssi) - local->wstats.qual.level = 0x100 - local->rssi[status_rid.sigQuality].rssidBm; - else + /* Signal quality and co */ + if (local->rssi) { + local->wstats.qual.level = airo_rssi_to_dbm( local->rssi, status_rid.sigQuality ); + /* normalizedSignalStrength appears to be a percentage */ + local->wstats.qual.qual = status_rid.normalizedSignalStrength; + } else { local->wstats.qual.level = (status_rid.normalizedSignalStrength + 321) / 2; + local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); + } + local->wstats.qual.updated = IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED; if (status_rid.len >= 124) { - local->wstats.qual.noise = 256 - status_rid.noisedBm; - local->wstats.qual.updated = 7; + local->wstats.qual.noise = 0x100 - status_rid.noisedBm; + local->wstats.qual.updated |= IW_QUAL_NOISE_UPDATED; } else { local->wstats.qual.noise = 0; - local->wstats.qual.updated = 3; + local->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } /* Packets discarded in the wireless adapter due to wireless From davem@davemloft.net Fri Feb 11 13:15:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:15:14 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BLF9JH028909 for ; Fri, 11 Feb 2005 13:15:09 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Czi6t-0000Ys-00; Fri, 11 Feb 2005 13:13:55 -0800 Date: Fri, 11 Feb 2005 13:13:55 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, johnstul@us.ibm.com Subject: Re: [PATCH] tg3: capacitive coupling detection fix Message-Id: <20050211131355.5e084004.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 497 Lines: 14 On Fri, 11 Feb 2005 12:44:10 -0800 "Michael Chan" wrote: > This patch fixes the problem reported in: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110798711911645&w=2 > > The 5700 link problem was caused by reading uninitialized values in sram and > causing capacitive coupling mode to be enabled by mistake. This patch fixes > the problem by properly validating the sram contents. > > Signed-off-by: Michael Chan Applied, thanks a lot Michael. From pablo@eurodev.net Fri Feb 11 13:18:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:18:40 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BLIX57029398 for ; Fri, 11 Feb 2005 13:18:34 -0800 Received: from eurodev.net ([85.136.109.126]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211211827.VUAT9125.smtp09.retemail.es@eurodev.net>; Fri, 11 Feb 2005 22:18:27 +0100 Message-ID: <420D2128.5000803@eurodev.net> Date: Fri, 11 Feb 2005 22:18:32 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH] [NETLINK] unify checkings for clean messages References: <420BF8C3.3050305@eurodev.net> <20050210173201.21da89e5.davem@davemloft.net> In-Reply-To: <20050210173201.21da89e5.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------070109050602080708060404" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 6695 Lines: 230 This is a multi-part message in MIME format. --------------070109050602080708060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David S. Miller wrote: >Why don't you bypass all the cleanup diffs and just do the functionality >change instead? When you mix whitespace and coding style cleanups >with real changes, it puts your real changes at risk if we think your >cleanups are ugly or bogus since you've created a patch dependency. > > Ok, sorry for the nuisance. I'll try to avoid such things in future. Thanks davem. Back to what I wanted to introduce... The following patches introduce a new function that check that the netlink messages received are clean. Actually some people performs such checkings, some don't and others simply do some half of them. I think that we must unify the behaviour of a netlink socket when it has to reply to malformed messages. 01process_skb.patch: introduces the new function called netlink_process_skb that does the sanity checkings for received messages. 02xfrm.patch: the modification to make xfrm_user use such new function. 03rtnetlink.patch: same thing for rtnetlink. The 02 and 03 patches are straight forward conversions. If you are ok with this, I could post more patches to make other netlink sockets use this new function. -- Pablo --------------070109050602080708060404 Content-Type: text/x-patch; name="01process_skb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="01process_skb.patch" ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-07 06:59:39 +01:00 +++ edited/include/linux/netlink.h 2005-02-11 21:25:38 +01:00 @@ -116,6 +116,7 @@ #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) +extern int netlink_process_skb(struct sk_buff *skb, int (*process_msg)(struct sk_buff *skb, struct nlmsghdr *nlh, int *err)); extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 +++ edited/net/netlink/af_netlink.c 2005-02-11 21:30:34 +01:00 @@ -1201,6 +1201,42 @@ netlink_unicast(in_skb->sk, skb, NETLINK_CB(in_skb).pid, MSG_DONTWAIT); } +/* + * Process one packet of messages. + * Malformed skbs with wrong lengths of messages are discarded silently. + */ +int netlink_process_skb(struct sk_buff *skb, + int (*process_msg)(struct sk_buff *skb, + struct nlmsghdr *nlh, + int *err)) +{ + int err; + struct nlmsghdr * nlh; + + while (skb->len >= NLMSG_SPACE(0)) { + u32 rlen; + + nlh = (struct nlmsghdr *)skb->data; + if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len) + return 0; + rlen = NLMSG_ALIGN(nlh->nlmsg_len); + if (rlen > skb->len) + rlen = skb->len; + if (process_msg(skb, nlh, &err)) { + /* Not error, but we must interrupt processing here: + * Note, that in this case we do not pull message + * from skb, it will be processed later. + */ + if (err == 0) + return -1; + netlink_ack(skb, nlh, err); + } else if (nlh->nlmsg_flags & NLM_F_ACK) + netlink_ack(skb, nlh, 0); + skb_pull(skb, rlen); + } + + return 0; +} #ifdef CONFIG_PROC_FS struct nl_seq_iter { @@ -1456,6 +1492,7 @@ MODULE_ALIAS_NETPROTO(PF_NETLINK); +EXPORT_SYMBOL(netlink_process_skb); EXPORT_SYMBOL(netlink_ack); EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); --------------070109050602080708060404 Content-Type: text/x-patch; name="02xfrm.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="02xfrm.patch" ===== net/xfrm/xfrm_user.c 1.52 vs edited ===== --- 1.52/net/xfrm/xfrm_user.c 2005-01-26 06:53:19 +01:00 +++ edited/net/xfrm/xfrm_user.c 2005-02-10 00:15:16 +01:00 @@ -980,33 +980,6 @@ return -1; } -static int xfrm_user_rcv_skb(struct sk_buff *skb) -{ - int err; - struct nlmsghdr *nlh; - - while (skb->len >= NLMSG_SPACE(0)) { - u32 rlen; - - nlh = (struct nlmsghdr *) skb->data; - if (nlh->nlmsg_len < sizeof(*nlh) || - skb->len < nlh->nlmsg_len) - return 0; - rlen = NLMSG_ALIGN(nlh->nlmsg_len); - if (rlen > skb->len) - rlen = skb->len; - if (xfrm_user_rcv_msg(skb, nlh, &err) < 0) { - if (err == 0) - return -1; - netlink_ack(skb, nlh, err); - } else if (nlh->nlmsg_flags & NLM_F_ACK) - netlink_ack(skb, nlh, 0); - skb_pull(skb, rlen); - } - - return 0; -} - static void xfrm_netlink_rcv(struct sock *sk, int len) { do { @@ -1015,7 +988,7 @@ down(&xfrm_cfg_sem); while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) { - if (xfrm_user_rcv_skb(skb)) { + if (netlink_process_skb(skb, xfrm_user_rcv_msg)) { if (skb->len) skb_queue_head(&sk->sk_receive_queue, skb); --------------070109050602080708060404 Content-Type: text/x-patch; name="03rtnetlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="03rtnetlink.patch" ===== net/core/rtnetlink.c 1.33 vs edited ===== --- 1.33/net/core/rtnetlink.c 2005-01-10 22:42:22 +01:00 +++ edited/net/core/rtnetlink.c 2005-02-10 00:14:59 +01:00 @@ -570,41 +570,6 @@ return -1; } -/* - * Process one packet of messages. - * Malformed skbs with wrong lengths of messages are discarded silently. - */ - -static inline int rtnetlink_rcv_skb(struct sk_buff *skb) -{ - int err; - struct nlmsghdr * nlh; - - while (skb->len >= NLMSG_SPACE(0)) { - u32 rlen; - - nlh = (struct nlmsghdr *)skb->data; - if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len) - return 0; - rlen = NLMSG_ALIGN(nlh->nlmsg_len); - if (rlen > skb->len) - rlen = skb->len; - if (rtnetlink_rcv_msg(skb, nlh, &err)) { - /* Not error, but we must interrupt processing here: - * Note, that in this case we do not pull message - * from skb, it will be processed later. - */ - if (err == 0) - return -1; - netlink_ack(skb, nlh, err); - } else if (nlh->nlmsg_flags&NLM_F_ACK) - netlink_ack(skb, nlh, 0); - skb_pull(skb, rlen); - } - - return 0; -} - /* * rtnetlink input queue processing routine: * - try to acquire shared lock. If it is failed, defer processing. @@ -622,7 +587,7 @@ return; while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) { - if (rtnetlink_rcv_skb(skb)) { + if (netlink_process_skb(skb, rtnetlink_rcv_msg)) { if (skb->len) skb_queue_head(&sk->sk_receive_queue, skb); --------------070109050602080708060404-- From johnstul@us.ibm.com Fri Feb 11 13:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:19:50 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BLJkTV029887 for ; Fri, 11 Feb 2005 13:19:46 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1BLJeuA021794 for ; Fri, 11 Feb 2005 16:19:40 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1BLJeHb414608 for ; Fri, 11 Feb 2005 14:19:40 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BLJdns006890 for ; Fri, 11 Feb 2005 14:19:40 -0700 Received: from cog.beaverton.ibm.com (cog.beaverton.ibm.com [9.47.21.16]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BLJcd8006832; Fri, 11 Feb 2005 14:19:39 -0700 Subject: Re: [PATCH] tg3: capacitive coupling detection fix From: john stultz To: Michael Chan Cc: "David S. Miller" , netdev@oss.sgi.com, lkml , Chris McDermott , keith maanthey In-Reply-To: References: Content-Type: text/plain Date: Fri, 11 Feb 2005 13:19:37 -0800 Message-Id: <1108156778.11683.212.camel@cog.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnstul@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 470 Lines: 15 On Fri, 2005-02-11 at 12:44 -0800, Michael Chan wrote: > This patch fixes the problem reported in: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110798711911645&w=2 > > > The 5700 link problem was caused by reading uninitialized values in sram and > causing capacitive coupling mode to be enabled by mistake. This patch fixes > the problem by properly validating the sram contents. Verified as working on the x440 I was seeing the trouble with. Thanks! -john From pablo@eurodev.net Fri Feb 11 13:31:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:31:47 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BLVfkQ031192 for ; Fri, 11 Feb 2005 13:31:42 -0800 Received: from eurodev.net ([85.136.109.126]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050211213135.WEHA9125.smtp09.retemail.es@eurodev.net>; Fri, 11 Feb 2005 22:31:35 +0100 Message-ID: <420D243C.4090507@eurodev.net> Date: Fri, 11 Feb 2005 22:31:40 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH 2/4] [NETLINK] introduce netlink_check_skb function References: <420BF8CB.6080005@eurodev.net> <20050211032448.GD31837@postel.suug.ch> In-Reply-To: <20050211032448.GD31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 997 Lines: 33 Thomas Graf wrote: >>+/* >>+ * Process one packet of messages. >>+ * Malformed skbs with wrong lengths of messages are discarded silently. >>+ */ >>+int netlink_process_skb(struct sk_buff *skb, >>+ int (*process_msg)(struct sk_buff *skb, >>+ struct nlmsghdr *nlh, >>+ int *err)) >>+{ >>+ int err; >>+ struct nlmsghdr * nlh; >>+ >>+ while (skb->len >= NLMSG_SPACE(0)) { >> >> > >While you're at it, change that to NLMSG_LENGTH(0) or even to >NLMSG_ALIGN(sizeof(*nlh)) to make it more readable. NLMSG_SPACE() >represents the total size of a netlink message in the byte stream >including the padding to payload in order to enforce proper >alignement for successive netlink message header. > > They are all the same thing. They all return 16 bytes which is the size of a netlink header. If you and someone else think that those are more readable, I'm ok with it, whatever. I just stole that piece of code as is from current checkings done in xfrm and rtnetlink. -- Pablo From jgarzik@pobox.com Fri Feb 11 13:44:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 13:44:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BLiVp8031793 for ; Fri, 11 Feb 2005 13:44:31 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CziaT-0007vK-Fz; Fri, 11 Feb 2005 21:44:29 +0000 Message-ID: <420D272D.9040704@pobox.com> Date: Fri, 11 Feb 2005 16:44:13 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> <20050208042950.GD8366@jm.kir.nu> <420885B6.7090606@linux.intel.com> <42094A6D.9080508@pobox.com> <420C0117.9070603@linux.intel.com> In-Reply-To: <420C0117.9070603@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 25 Lines: 2 applied to wireless-2.6 From jgarzik@pobox.com Fri Feb 11 14:07:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 14:07:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BM7fQh000312 for ; Fri, 11 Feb 2005 14:07:41 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cziwu-0008Uy-6T; Fri, 11 Feb 2005 22:07:40 +0000 Message-ID: <420D2C9D.3090209@pobox.com> Date: Fri, 11 Feb 2005 17:07:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olaf Kirch CC: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi: long cable, short cable References: <20050208141849.GC23971@suse.de> In-Reply-To: <20050208141849.GC23971@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1537 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: 554 Lines: 18 Olaf Kirch wrote: > The current version of the natsemi driver comes with a workaround > for a hardware problem that causes link failures on short cables. > Unfortunately, this workaround causes massive link failures on _long_ > cables (270-300ft). This patch adds a module parameter to disable > the workaround if required. > > Signed-off-by: Olaf Kirch I grudgingly applied this. Hopefully someone will create a private ioctl or ethtool option for this, rather than a module option. This setting needs to be per-interface. Jeff From hubert.tonneau@fullpliant.org Fri Feb 11 14:24:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 14:24:41 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1BMOQoT001078 for ; Fri, 11 Feb 2005 14:24:28 -0800 From: Hubert Tonneau To: "David S. Miller" Cc: shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, Nivedita Singhvi, Rick Jones , netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Fri, 11 Feb 2005 21:55:49 GMT Message-ID: <0525M9211@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 2527 Lines: 82 Sorry, it still does not work, unless I made a mistake: Linux 2.6.9 takes 15 seconds to copy 105 MB to Mac OSX Linux 2.6.10 with the TCP patch below still takes 325 seconds to do the same. You can pick the new tcpdump report, created through: tcpdump -i eth1 ip host 10.107.96.230 -w /tmp/dump-2.6.10-tcp2 at http://fullpliant.org/pliant/browse/file/archive/dump-2.6.10-tcp2.gz Here is the connection summary: Dell PowerEdge 2600 (dual Xeon with hyper threading) running libsmbclient on Linux 2.6.x, IP for eth1 (Intel pro 1000) is 10.107.96.7 (full duplex, flow control is enabled) | | gigabit switch | | 100 Mbps switch | | Mac running Samba server on OSX, IP is 10.107.96.230 David S. Miller wrote: > > Hubert, try this patch instead. > > ===== net/ipv4/tcp_output.c 1.77 vs edited ===== > --- 1.77/net/ipv4/tcp_output.c 2005-01-18 12:23:36 -08:00 > +++ edited/net/ipv4/tcp_output.c 2005-02-10 16:42:42 -08:00 > @@ -408,6 +408,16 @@ > sk->sk_send_head = skb; > } > > +static inline void tcp_tso_set_push(struct sk_buff *skb) > +{ > + /* Force push to be on for any TSO frames to workaround > + * problems with busted implementations like Mac OS-X that > + * hold off socket reveive wakeups until push is seen. > + */ > + if (tcp_skb_pcount(skb) > 1) > + TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; > +} > + > /* Send _single_ skb sitting at the send head. This function requires > * true push pending frames to setup probe timer etc. > */ > @@ -419,6 +429,7 @@ > if (tcp_snd_test(tp, skb, cur_mss, TCP_NAGLE_PUSH)) { > /* Send it out now. */ > TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { > sk->sk_send_head = NULL; > tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; > @@ -755,6 +766,7 @@ > } > > TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) > break; > > @@ -1096,6 +1108,7 @@ > * is still in somebody's hands, else make a clone. > */ > TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > > err = tcp_transmit_skb(sk, (skb_cloned(skb) ? > pskb_copy(skb, GFP_ATOMIC): > @@ -1668,6 +1681,7 @@ > > TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; > TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > err = tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); > if (!err) { > update_send_head(sk, tp, skb); From tgraf@suug.ch Fri Feb 11 14:43:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 14:43:41 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BMhaGS001813 for ; Fri, 11 Feb 2005 14:43:37 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7FFE7F; Fri, 11 Feb 2005 23:43:13 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id CCA791C0EA; Fri, 11 Feb 2005 23:43:54 +0100 (CET) Date: Fri, 11 Feb 2005 23:43:54 +0100 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH 2/4] [NETLINK] introduce netlink_check_skb function Message-ID: <20050211224354.GE31837@postel.suug.ch> References: <420BF8CB.6080005@eurodev.net> <20050211032448.GD31837@postel.suug.ch> <420D243C.4090507@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420D243C.4090507@eurodev.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1152 Lines: 19 > They are all the same thing. They all return 16 bytes which is the size > of a netlink header. If you and someone else think that those are more > readable, I'm ok with it, whatever. I just stole that piece of code as > is from current checkings done in xfrm and rtnetlink. That's absolutely true, my point is that while reading that line of code it reads like while the remaining length in the socket buffer is still greather or equal than the total message size until the next message with a payload of 0, then do something. It looks confusing at a first glance because you're not event interested in the payload just now. A choice of NLMSG_ALIGN(sizeof(*nlh)) or NLMSG_LENGTH(0) clearly points out that you're just checking for enough room regarding the netlink header in order to access it safely and do the real sanity check against the complete message length. Engross that thought a bit further, NLMSG_SPACE could change at some point assuming that it is only used in contexts where the total message size is in question. If you think that's too much of nitpicking, then forget about it. It's technicaly absolutely correct at the moment. From rick.jones2@hp.com Fri Feb 11 14:54:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 14:54:36 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BMsTvi002427 for ; Fri, 11 Feb 2005 14:54:30 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 97BE7131C; Fri, 11 Feb 2005 14:54:29 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA26856; Fri, 11 Feb 2005 14:54:28 -0800 (PST) Message-ID: <420D37A3.6020209@hp.com> Date: Fri, 11 Feb 2005 14:54:27 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hubert Tonneau Cc: "David S. Miller" , shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> In-Reply-To: <0525M9211@server5.heliogroup.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 3800 Lines: 84 Hubert Tonneau wrote: > Sorry, it still does not work, unless I made a mistake: > Linux 2.6.9 takes 15 seconds to copy 105 MB to Mac OSX > Linux 2.6.10 with the TCP patch below still takes 325 seconds to do the same. > > You can pick the new tcpdump report, created through: > tcpdump -i eth1 ip host 10.107.96.230 -w /tmp/dump-2.6.10-tcp2 > at http://fullpliant.org/pliant/browse/file/archive/dump-2.6.10-tcp2.gz > > Here is the connection summary: > > Dell PowerEdge 2600 (dual Xeon with hyper threading) running libsmbclient > on Linux 2.6.x, IP for eth1 (Intel pro 1000) is 10.107.96.7 (full > duplex, flow control is enabled) > | > | > gigabit switch > | > | > 100 Mbps switch > | > | > Mac running Samba server on OSX, > IP is 10.107.96.230 "Cooking" the trace with tcpdump -ttt to give the relative timestamdps makes things look like Mac OSX has an ACK avoidance heuristic in it? I figured there was one in their OX <= 9 stack that came from a third-party, wasn't sure if they put that into their OSX stack - IIRC that one is not from the third-party. FWIW, there are two or three other stacks that have ACK avoidance heuristics as well, it isn't an OSX only thing. 000780 10.107.96.230.139 > 10.107.96.7.32801: P 753:822(69) ack 1556 win 65535 NBT Packet (DF) 000579 10.107.96.7.32801 > 10.107.96.230.139: . 1556:3004(1448) ack 822 win 1460 NBT Packet (DF) 000027 10.107.96.7.32801 > 10.107.96.230.139: . 3004:4452(1448) ack 822 win 1460 NBT Packet (DF) 000005 10.107.96.7.32801 > 10.107.96.230.139: . 4452:5900(1448) ack 822 win 1460 NBT Packet (DF) 074685 10.107.96.230.139 > 10.107.96.7.32801: . ack 5900 win 62268 (DF) delack above 000012 10.107.96.7.32801 > 10.107.96.230.139: . 5900:7348(1448) ack 822 win 1460 NBT Packet (DF) 000003 10.107.96.7.32801 > 10.107.96.230.139: . 7348:8796(1448) ack 822 win 1460 NBT Packet (DF) 000002 10.107.96.7.32801 > 10.107.96.230.139: . 8796:10244(1448) ack 822 win 1460 NBT Packet (DF) 000002 10.107.96.7.32801 > 10.107.96.230.139: . 10244:11692(1448) ack 822 win 1460 NBT Packet (DF) 200024 10.107.96.230.139 > 10.107.96.7.32801: . ack 11692 win 56476 (DF) and again above. 000010 10.107.96.7.32801 > 10.107.96.230.139: . 11692:13140(1448) ack 822 win 1460 NBT Packet (DF) 000004 10.107.96.7.32801 > 10.107.96.230.139: . 13140:14588(1448) ack 822 win 1460 NBT Packet (DF) 000002 10.107.96.7.32801 > 10.107.96.230.139: P 14588:16036(1448) ack 822 win 1460 NBT Packet (DF) 000022 10.107.96.7.32801 > 10.107.96.230.139: . 16036:17484(1448) ack 822 win 1460 NBT Packet (DF) 000004 10.107.96.7.32801 > 10.107.96.230.139: P 17484:18192(708) ack 822 win 1460 NBT Packet (DF) 000994 10.107.96.230.139 > 10.107.96.7.32801: . ack 18192 win 65535 (DF) 0 And then other cases where the ACK seems to take a rather long time to arrive, seems to correlate a bit with slowly increasing numbers of segments before the ACK is sent, and something along the lines of a 200 millisecond delayed ACK timer. In some cases at least if the sender does not completely fill cwnd the ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the sender does not always fill cwnd. hth, rick jones From shemminger@osdl.org Fri Feb 11 15:05:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:05:06 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BN4xKJ003166 for ; Fri, 11 Feb 2005 15:05:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1BN48l11560; Fri, 11 Feb 2005 15:04:08 -0800 Date: Fri, 11 Feb 2005 15:04:20 -0800 From: Stephen Hemminger To: Hubert Tonneau Cc: "David S. Miller" , romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, Nivedita Singhvi, Rick Jones , netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050211150420.74737b2e@dxpl.pdx.osdl.net> In-Reply-To: <0525M9211@server5.heliogroup.fr> References: <0525M9211@server5.heliogroup.fr> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1541 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: 3181 Lines: 44 On Fri, 11 Feb 2005 21:55:49 GMT Hubert Tonneau wrote: > Sorry, it still does not work, unless I made a mistake: > Linux 2.6.9 takes 15 seconds to copy 105 MB to Mac OSX > Linux 2.6.10 with the TCP patch below still takes 325 seconds to do the same. > > You can pick the new tcpdump report, created through: > tcpdump -i eth1 ip host 10.107.96.230 -w /tmp/dump-2.6.10-tcp2 > at http://fullpliant.org/pliant/browse/file/archive/dump-2.6.10-tcp2.gz Still not setting Push sufficiently to keep MacOSX happy. 13:40:35.027124 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: P 924:975(51) ack 67344 win 50728 13:40:35.027186 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 67344 win 65535 13:40:35.027328 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: P 975:1026(51) ack 67344 win 65535 13:40:35.027363 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 67344:68792(1448) ack 1026 win 1460 13:40:35.027367 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 68792:70240(1448) ack 1026 win 1460 13:40:35.027370 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 70240:71688(1448) ack 1026 win 1460 13:40:35.027373 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 71688:73136(1448) ack 1026 win 1460 13:40:35.027375 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 73136:74584(1448) ack 1026 win 1460 13:40:35.027378 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 74584:76032(1448) ack 1026 win 1460 13:40:35.027381 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 76032:77480(1448) ack 1026 win 1460 13:40:35.027384 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 77480:78928(1448) ack 1026 win 1460 13:40:35.027387 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 78928:80376(1448) ack 1026 win 1460 13:40:35.027390 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 80376:81824(1448) ack 1026 win 1460 13:40:35.027393 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 81824:83272(1448) ack 1026 win 1460 13:40:35.027397 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: P 83272:83980(708) ack 1026 win 1460 okay burst with push 13:40:35.034930 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: P 1179:1230(51) ack 133132 win 65535 13:40:35.035304 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 133132:134580(1448) ack 1230 win 1460 13:40:35.035312 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 134580:136028(1448) ack 1230 win 1460 Big gap... because of missing P 13:40:35.219175 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 136028 win 63716 13:40:35.219193 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 136028:137476(1448) ack 1230 win 1460 13:40:35.219197 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 137476:138924(1448) ack 1230 win 1460 13:40:35.419193 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 138924 win 60820 13:40:35.419202 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 138924:140372(1448) ack 1230 win 1460 13:40:35.419205 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 140372:141820(1448) ack 1230 win 1460 13:40:35.419207 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 141820:143268(1448) ack 1230 win 1460 From niv@us.ibm.com Fri Feb 11 15:09:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:09:20 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BN9FDR003713 for ; Fri, 11 Feb 2005 15:09:15 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1BN99uA791836 for ; Fri, 11 Feb 2005 18:09:09 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1BN99Hb446816 for ; Fri, 11 Feb 2005 16:09:09 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BN98Dn009705 for ; Fri, 11 Feb 2005 16:09:09 -0700 Received: from [9.47.22.79] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.79]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BN97Jc009674; Fri, 11 Feb 2005 16:09:07 -0700 Message-ID: <420D3B17.3040506@us.ibm.com> Date: Fri, 11 Feb 2005 15:09:11 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Jones CC: Hubert Tonneau , "David S. Miller" , shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> In-Reply-To: <420D37A3.6020209@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1542 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: 1624 Lines: 35 Rick Jones wrote: > 000010 10.107.96.7.32801 > 10.107.96.230.139: . 11692:13140(1448) ack > 822 win 1460 NBT Packet (DF) > 000004 10.107.96.7.32801 > 10.107.96.230.139: . 13140:14588(1448) ack > 822 win 1460 NBT Packet (DF) > 000002 10.107.96.7.32801 > 10.107.96.230.139: P 14588:16036(1448) ack > 822 win 1460 NBT Packet (DF) > 000022 10.107.96.7.32801 > 10.107.96.230.139: . 16036:17484(1448) ack > 822 win 1460 NBT Packet (DF) > 000004 10.107.96.7.32801 > 10.107.96.230.139: P 17484:18192(708) ack 822 > win 1460 NBT Packet (DF) > 000994 10.107.96.230.139 > 10.107.96.7.32801: . ack 18192 win 65535 > (DF) > 0 > > And then other cases where the ACK seems to take a rather long time to > arrive, seems to correlate a bit with slowly increasing numbers of > segments before the ACK is sent, and something along the lines of a 200 > millisecond delayed ACK timer. > > In some cases at least if the sender does not completely fill cwnd the > ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the > sender does not always fill cwnd. Er, how is this compliant with 2581 (yes, I know, it's only a SHOULD, not a MUST) - an ACK should be generated for at least every second full-sized segment received? Don't see that happening. In many cases it's receiving quite a few more packets. It should not be waiting for the delayed ack timer to go off, surely? thanks, Nivedita From rick.jones2@hp.com Fri Feb 11 15:40:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:40:26 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNeLNj004916 for ; Fri, 11 Feb 2005 15:40:22 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 5468D40CB6E; Fri, 11 Feb 2005 15:40:21 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA27154; Fri, 11 Feb 2005 15:40:20 -0800 (PST) Message-ID: <420D4264.6030400@hp.com> Date: Fri, 11 Feb 2005 15:40:20 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: Hubert Tonneau , shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <420D3B17.3040506@us.ibm.com> In-Reply-To: <420D3B17.3040506@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1623 Lines: 30 > Er, how is this compliant with 2581 (yes, I know, it's only a SHOULD, not a > MUST) - an ACK should be generated for at least every second full-sized > segment received? Don't see that happening. In many cases it's receiving > quite a few more packets. It should not be waiting for the delayed ack timer > to go off, surely? Certainly it would make for an interesting disuscion. Indeed it is a SHOULD which leaves-open the door to compliance of other ACK policies. Those might result in an ACK for more than two segments, or even an ACK for fewer than two segments, and there are folks in either camp/faction/sect/pick your favorite term. I would say that it is still compliant with 2581. The must there is that no matter what, an ACK must be generated within 500 milliseconds. I suspect that had a full cwnd's worth of data been sent there would have been no lengthy delay in ACKs even with fewer than ACK-every-other. I suspect that had TSO been disabled the full cwnd would have been sent and these delayed ACKs would not have happened and the transfer speed would have been happiness and joy. FWIW, as the industry has added features such as CKO (ChecKsum Offload), copy-avoidance, and now TSO, the pie chart of time spent has been shifting more and more to ACK processing. If we go back far enough, the writeups talk about how delayed ACK to increase ACK piggybacking was added in the first place - specifically (IIRC) for the purpose of minimizing ACK overhead. rick jones BTW, I'd be happy to trim emails that are already on netdev to avoid message duplications, is netdev a "closed" list? From romieu@fr.zoreil.com Fri Feb 11 15:43:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:43:18 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNh7UE005438 for ; Fri, 11 Feb 2005 15:43:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1BNdNh7013642; Sat, 12 Feb 2005 00:39:23 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1BNdIe0013641; Sat, 12 Feb 2005 00:39:18 +0100 Date: Sat, 12 Feb 2005 00:39:18 +0100 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, jdmason@us.ibm.com, netdev@oss.sgi.com Subject: [patch 2.6.11-rc3 1/5] r8169: endianness fixes Message-ID: <20050211233918.GB8792@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2043 Lines: 56 Endianness fixes - rtl8169_rx_csum() forgot to convert the descriptor to cpu order, - same thing for rtl8169_rx_vlan_skb() but this one is more tricky as the layout of the (u32) word in the 8169 descriptor calls for a second level of swap at the vlan tag level (u16). The old code only did the second part (in an endian-dependant way, how fun). - rtl8169_tx_vlan_tag(): this time the (u32 descriptor level) cpu_to_le32 is issued in rtl8169_start_xmit but the (u16 vlan tag level) cpu_to_be16 is not right any more. Summary: avoid even calls to cpu_to_{b/l}eXX on a given piece of data. The change has no effect on x86. Now sparc64 talks to x86. Pinpointed-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-350 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-350 2005-02-05 21:04:12.000000000 +0100 +++ b/drivers/net/r8169.c 2005-02-12 00:25:12.992726954 +0100 @@ -698,7 +698,7 @@ static inline u32 rtl8169_tx_vlan_tag(st struct sk_buff *skb) { return (tp->vlgrp && vlan_tx_tag_present(skb)) ? - TxVlanTag | cpu_to_be16(vlan_tx_tag_get(skb)) : 0x00; + TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00; } static void rtl8169_vlan_rx_register(struct net_device *dev, @@ -733,12 +733,12 @@ static void rtl8169_vlan_rx_kill_vid(str static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc, struct sk_buff *skb) { - u32 opts2 = desc->opts2; + u32 opts2 = le32_to_cpu(desc->opts2); int ret; if (tp->vlgrp && (opts2 & RxVlanTag)) { rtl8169_rx_hwaccel_skb(skb, tp->vlgrp, - be16_to_cpu(opts2 & 0xffff)); + swab16(opts2 & 0xffff)); ret = 0; } else ret = -1; @@ -2084,7 +2084,7 @@ rtl8169_tx_interrupt(struct net_device * static inline void rtl8169_rx_csum(struct sk_buff *skb, struct RxDesc *desc) { - u32 opts1 = desc->opts1; + u32 opts1 = le32_to_cpu(desc->opts1); u32 status = opts1 & RxProtoMask; if (((status == RxProtoTCP) && !(opts1 & TCPFail)) || _ From romieu@fr.zoreil.com Fri Feb 11 15:43:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:43:18 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNh7hN005440 for ; Fri, 11 Feb 2005 15:43:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1BNfH5l013660; Sat, 12 Feb 2005 00:41:17 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1BNf6GZ013659; Sat, 12 Feb 2005 00:41:06 +0100 Date: Sat, 12 Feb 2005 00:41:06 +0100 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, netdev@oss.sgi.com Subject: [patch 2.6.11-rc3 2/5] r8169: merge of Realtek's code Message-ID: <20050211234106.GA13644@electric-eye.fr.zoreil.com> References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211233918.GB8792@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1545 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: 5001 Lines: 152 Merge of Realtek's code - code dedicated to a new phy (spotted by Richard Dawe); - C+ register fiddling seems required for both RTL_GIGA_MAC_VER_{D/E}; - apart from being reserved, register at address 0xe2 is named 'IntrMitigate'; - bump version number. A bunch of people do not use the vanilla kernel module simply because Realtek's driver has a higher revision number. This is not an issue per se but their driver is buggy due to some partial merge of in-kernel code. Signed-off-by: Francois Romieu Signed-off-by: Richard Dawe diff -puN drivers/net/r8169.c~r8169-360 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-360 2005-02-05 21:04:17.000000000 +0100 +++ b/drivers/net/r8169.c 2005-02-12 00:25:10.895067209 +0100 @@ -41,6 +41,13 @@ VERSION 1.6LK <2004/04/14> - Suspend/resume - Endianness - Misc Rx/Tx bugs + +VERSION 2.2LK <2005/01/25> + + - RX csum, TX csum/SG, TSO + - VLAN + - baby (< 7200) Jumbo frames support + - Merge of Realtek's version 2.2 (new phy) */ #include @@ -62,7 +69,7 @@ VERSION 1.6LK <2004/04/14> #include #include -#define RTL8169_VERSION "1.6LK" +#define RTL8169_VERSION "2.2LK" #define MODULENAME "r8169" #define PFX MODULENAME ": " @@ -149,6 +156,7 @@ enum phy_version { RTL_GIGA_PHY_VER_E = 0x05, /* PHY Reg 0x03 bit0-3 == 0x0000 */ RTL_GIGA_PHY_VER_F = 0x06, /* PHY Reg 0x03 bit0-3 == 0x0001 */ RTL_GIGA_PHY_VER_G = 0x07, /* PHY Reg 0x03 bit0-3 == 0x0002 */ + RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */ }; @@ -162,7 +170,8 @@ const static struct { } rtl_chip_info[] = { _R("RTL8169", RTL_GIGA_MAC_VER_B, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_D, 0xff7e1880), - _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880) + _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880), + _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_X, 0xff7e1880), }; #undef _R @@ -208,6 +217,7 @@ enum RTL8169_registers { PHYstatus = 0x6C, RxMaxSize = 0xDA, CPlusCmd = 0xE0, + IntrMitigate = 0xE2, RxDescAddrLow = 0xE4, RxDescAddrHigh = 0xE8, EarlyTxThres = 0xEC, @@ -407,7 +417,7 @@ struct rtl8169_private { struct work_struct task; }; -MODULE_AUTHOR("Realtek"); +MODULE_AUTHOR("Realtek and the Linux r8169 crew "); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); module_param_array(media, int, &num_media, 0); module_param(rx_copybreak, int, 0); @@ -1002,7 +1012,7 @@ static void rtl8169_hw_phy_config(struct if (tp->mac_version <= RTL_GIGA_MAC_VER_B) return; - if (tp->phy_version >= RTL_GIGA_PHY_VER_F) + if (tp->phy_version >= RTL_GIGA_PHY_VER_H) return; dprintk("MAC version != 0 && PHY version == 0 or 1\n"); @@ -1010,6 +1020,18 @@ static void rtl8169_hw_phy_config(struct /* Shazam ! */ + if (tp->mac_version == RTL_GIGA_MAC_VER_X) { + mdio_write(ioaddr, 31, 0x0001); + mdio_write(ioaddr, 9, 0x273a); + mdio_write(ioaddr, 14, 0x7bfb); + mdio_write(ioaddr, 27, 0x841e); + + mdio_write(ioaddr, 31, 0x0002); + mdio_write(ioaddr, 1, 0x90d0); + mdio_write(ioaddr, 31, 0x0000); + return; + } + // phy config for RTL8169s mac_version C chip mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1 mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000 @@ -1038,7 +1060,7 @@ static void rtl8169_phy_timer(unsigned l unsigned long timeout = RTL8169_PHY_TIMEOUT; assert(tp->mac_version > RTL_GIGA_MAC_VER_B); - assert(tp->phy_version < RTL_GIGA_PHY_VER_G); + assert(tp->phy_version < RTL_GIGA_PHY_VER_H); if (!(tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) return; @@ -1073,7 +1095,7 @@ static inline void rtl8169_delete_timer( struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) + (tp->phy_version >= RTL_GIGA_PHY_VER_H)) return; del_timer_sync(timer); @@ -1085,7 +1107,7 @@ static inline void rtl8169_request_timer struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) + (tp->phy_version >= RTL_GIGA_PHY_VER_H)) return; init_timer(timer); @@ -1563,13 +1585,20 @@ rtl8169_hw_start(struct net_device *dev) tp->cp_cmd |= RTL_R16(CPlusCmd); RTL_W16(CPlusCmd, tp->cp_cmd); - if (tp->mac_version == RTL_GIGA_MAC_VER_D) { + if ((tp->mac_version == RTL_GIGA_MAC_VER_D) || + (tp->mac_version == RTL_GIGA_MAC_VER_E)) { dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " "Bit-3 and bit-14 MUST be 1\n"); tp->cp_cmd |= (1 << 14) | PCIMulRW; RTL_W16(CPlusCmd, tp->cp_cmd); } + /* + * Undocumented corner. Supposedly: + * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets + */ + RTL_W16(IntrMitigate, 0x0000); + 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)); _ From romieu@fr.zoreil.com Fri Feb 11 15:43:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:43:19 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNh7Yd005439 for ; Fri, 11 Feb 2005 15:43:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1BNgfw5013672; Sat, 12 Feb 2005 00:42:41 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1BNgaHI013671; Sat, 12 Feb 2005 00:42:36 +0100 Date: Sat, 12 Feb 2005 00:42:36 +0100 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, jdmason@us.ibm.com, netdev@oss.sgi.com Subject: [patch 2.6.11-rc3 3/5] r8169: typo in debugging code Message-ID: <20050211234236.GB13644@electric-eye.fr.zoreil.com> References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> <20050211234106.GA13644@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211234106.GA13644@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1546 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: 684 Lines: 18 Typo in debugging code. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-370 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-370 2005-02-05 21:04:22.000000000 +0100 +++ b/drivers/net/r8169.c 2005-02-12 00:25:04.364126556 +0100 @@ -79,7 +79,7 @@ VERSION 2.2LK <2005/01/25> printk( "Assertion failed! %s,%s,%s,line=%d\n", \ #expr,__FILE__,__FUNCTION__,__LINE__); \ } -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args) } while (0) +#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0) #else #define assert(expr) do {} while (0) #define dprintk(fmt, args...) do {} while (0) _ From romieu@fr.zoreil.com Fri Feb 11 15:47:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:47:15 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNl81f006949 for ; Fri, 11 Feb 2005 15:47:11 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1BNjSd1013784; Sat, 12 Feb 2005 00:45:28 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1BNjM3g013783; Sat, 12 Feb 2005 00:45:22 +0100 Date: Sat, 12 Feb 2005 00:45:22 +0100 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, jdmason@us.ibm.com, netdev@oss.sgi.com Subject: [patch 2.6.11-rc3 5/5] r8169: synchronization and balancing when the device is closed Message-ID: <20050211234522.GD13644@electric-eye.fr.zoreil.com> References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> <20050211234106.GA13644@electric-eye.fr.zoreil.com> <20050211234236.GB13644@electric-eye.fr.zoreil.com> <20050211234403.GC13644@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211234403.GC13644@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1548 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: 994 Lines: 32 rtl8169_close synchronization and balancing - use synchronize_kernel() to sync with the xmit thread (kindly suggested by davem); - balance the netif_poll_disable issued in rtl8169_down. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-390 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-390 2005-02-12 00:06:40.381648524 +0100 +++ b/drivers/net/r8169.c 2005-02-12 00:06:48.015420988 +0100 @@ -2382,8 +2382,7 @@ static void rtl8169_down(struct net_devi netif_poll_disable(dev); /* Give a racing hard_start_xmit a few cycles to complete. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(1); + synchronize_kernel(); rtl8169_tx_clear(tp); @@ -2399,6 +2398,8 @@ static int rtl8169_close(struct net_devi free_irq(dev->irq, dev); + netif_poll_enable(dev); + pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, tp->RxPhyAddr); pci_free_consistent(pdev, R8169_TX_RING_BYTES, tp->TxDescArray, _ From romieu@fr.zoreil.com Fri Feb 11 15:47:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 15:47:12 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BNl7fD006948 for ; Fri, 11 Feb 2005 15:47:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1BNi9a6013769; Sat, 12 Feb 2005 00:44:09 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1BNi3fG013768; Sat, 12 Feb 2005 00:44:04 +0100 Date: Sat, 12 Feb 2005 00:44:03 +0100 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, jdmason@us.ibm.com, netdev@oss.sgi.com Subject: [patch 2.6.11-rc3 4/5] r8169: screaming irq when the device is closed Message-ID: <20050211234403.GC13644@electric-eye.fr.zoreil.com> References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> <20050211234106.GA13644@electric-eye.fr.zoreil.com> <20050211234236.GB13644@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211234236.GB13644@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1547 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: 2797 Lines: 105 Close the race for a screaming irq when the device is closed. - rtl8169_interrupt() try to properly IRQ_HANDLE an interrupt even when the network device is going down. As a benefit, rtl8169_poll() does not need to care about the close race any more; - factor code with rtl8169_irq_mask_and_ack(); - rtl8169_init_board(): mitigate some really unexpected events. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-380 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-380 2005-02-05 21:04:32.000000000 +0100 +++ b/drivers/net/r8169.c 2005-02-12 00:25:00.002833963 +0100 @@ -490,6 +490,13 @@ static int mdio_read(void __iomem *ioadd return value; } +static void rtl8169_irq_mask_and_ack(void __iomem *ioaddr) +{ + RTL_W16(IntrMask, 0x0000); + + RTL_W16(IntrStatus, 0xffff); +} + static unsigned int rtl8169_tbi_reset_pending(void __iomem *ioaddr) { return RTL_R32(TBICSR) & TBIReset; @@ -1234,6 +1241,9 @@ rtl8169_init_board(struct pci_dev *pdev, goto err_out_free_res; } + // Unneeded ? Don't mess with Mrs. Murphy. + rtl8169_irq_mask_and_ack(ioaddr); + // Soft reset the chip. RTL_W8(ChipCmd, CmdReset); @@ -1540,7 +1550,7 @@ err_free_irq: static void rtl8169_hw_reset(void __iomem *ioaddr) { /* Disable interrupts */ - RTL_W16(IntrMask, 0x0000); + rtl8169_irq_mask_and_ack(ioaddr); /* Reset the chipset */ RTL_W8(ChipCmd, CmdReset); @@ -1824,9 +1834,7 @@ static void rtl8169_wait_for_quiescence( /* Wait for any pending NAPI task to complete */ netif_poll_disable(dev); - RTL_W16(IntrMask, 0x0000); - - RTL_W16(IntrStatus, 0xffff); + rtl8169_irq_mask_and_ack(ioaddr); netif_poll_enable(dev); } @@ -2244,12 +2252,9 @@ rtl8169_interrupt(int irq, void *dev_ins struct rtl8169_private *tp = netdev_priv(dev); int boguscnt = max_interrupt_work; void __iomem *ioaddr = tp->mmio_addr; - int status = 0; + int status; int handled = 0; - if (unlikely(!netif_running(dev))) - goto out; - do { status = RTL_R16(IntrStatus); @@ -2259,6 +2264,9 @@ rtl8169_interrupt(int irq, void *dev_ins handled = 1; + if (unlikely(!netif_running(dev))) + goto out_asic_stop; + status &= tp->intr_mask; RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); @@ -2306,6 +2314,12 @@ rtl8169_interrupt(int irq, void *dev_ins } out: return IRQ_RETVAL(handled); + +out_asic_stop: + RTL_W8(ChipCmd, 0x00); + rtl8169_irq_mask_and_ack(ioaddr); + RTL_R16(CPlusCmd); + goto out; } #ifdef CONFIG_R8169_NAPI @@ -2321,7 +2335,7 @@ static int rtl8169_poll(struct net_devic *budget -= work_done; dev->quota -= work_done; - if ((work_done < work_to_do) || !netif_running(dev)) { + if (work_done < work_to_do) { netif_rx_complete(dev); tp->intr_mask = 0xffff; /* _ From romieu@fr.zoreil.com Fri Feb 11 16:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 16:11:05 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C0Aux7008465 for ; Fri, 11 Feb 2005 16:10:57 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1C07bdL014387; Sat, 12 Feb 2005 01:07:37 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1C07WcH014386; Sat, 12 Feb 2005 01:07:32 +0100 Date: Sat, 12 Feb 2005 01:07:32 +0100 From: Francois Romieu To: Richard Dawe Cc: netdev@oss.sgi.com Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow Message-ID: <20050212000732.GC8792@electric-eye.fr.zoreil.com> References: <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> <20050205204135.GA13986@electric-eye.fr.zoreil.com> <420944AB.5090501@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420944AB.5090501@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1549 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: 497 Lines: 18 Richard Dawe : [...] > I find that the "ip link set dev eth0 down" command hangs, consuming > most of the CPU time (~99%). Note that I issued the "network" commands > with about a second's delay between each command. @#$*%! Patch against 2.6.11-rc3: http://www.fr.zoreil.com/people/francois/misc/20050211-2.6.11-rc3-r8169-test.patch Better ? Up-to-date patch-script version is available at: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc3/r8169 -- Ueimor From davem@davemloft.net Fri Feb 11 17:10:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 17:10:20 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C1AEcY013476 for ; Fri, 11 Feb 2005 17:10:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Czll7-0001ab-00; Fri, 11 Feb 2005 17:07:41 -0800 Date: Fri, 11 Feb 2005 17:07:40 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050211170740.2608419b.davem@davemloft.net> In-Reply-To: <20050211150420.74737b2e@dxpl.pdx.osdl.net> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 516 Lines: 15 On Fri, 11 Feb 2005 15:04:20 -0800 Stephen Hemminger wrote: > Still not setting Push sufficiently to keep MacOSX happy. I don't think it's the kernel's fault in this case. This set of data frames you quoted are all full, and are tightly interspaced. It looks exactly like a TSO frame, which we certainly set PSH on, but the TSO engine is dropping it aparently. I guess this is e1000. Any e1000 internals experts reading here who can comment on how e1000's TSO engine treats the PSH flag? From davem@davemloft.net Fri Feb 11 17:10:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 17:10:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C1AciU013629 for ; Fri, 11 Feb 2005 17:10:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Czlli-0001b8-00; Fri, 11 Feb 2005 17:08:18 -0800 Date: Fri, 11 Feb 2005 17:08:17 -0800 From: "David S. Miller" To: Nivedita Singhvi Cc: rick.jones2@hp.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050211170817.39d581b5.davem@davemloft.net> In-Reply-To: <420D3B17.3040506@us.ibm.com> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <420D3B17.3040506@us.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 278 Lines: 8 On Fri, 11 Feb 2005 15:09:11 -0800 Nivedita Singhvi wrote: > Er, how is this compliant with 2581 (yes, I know, it's only > a SHOULD, not a MUST) - an ACK should be generated for at > least every second full-sized segment received? It's compliant but stupid. From davem@davemloft.net Fri Feb 11 17:11:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 17:11:48 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C1BgDq014266 for ; Fri, 11 Feb 2005 17:11:42 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CzlnL-0001bM-00; Fri, 11 Feb 2005 17:09:59 -0800 Date: Fri, 11 Feb 2005 17:09:58 -0800 From: "David S. Miller" To: Rick Jones Cc: hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050211170958.17fcde21.davem@davemloft.net> In-Reply-To: <420D37A3.6020209@hp.com> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 369 Lines: 11 On Fri, 11 Feb 2005 14:54:27 -0800 Rick Jones wrote: > In some cases at least if the sender does not completely fill cwnd the > ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the > sender does not always fill cwnd. At a maximum, "1/tcp_tso_win_divisor" of the cwnd will ever be left empty. By default, this is 1/8 of the cwnd. From kaber@trash.net Fri Feb 11 17:17:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 17:17:12 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C1H80W014978 for ; Fri, 11 Feb 2005 17:17:09 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1Czlu7-00064F-Li; Sat, 12 Feb 2005 02:16:59 +0100 Message-ID: <420D590B.9040404@trash.net> Date: Sat, 12 Feb 2005 02:16:59 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] [NETLINK] unify checkings for clean messages References: <420BF8C3.3050305@eurodev.net> <20050210173201.21da89e5.davem@davemloft.net> <420D2128.5000803@eurodev.net> In-Reply-To: <420D2128.5000803@eurodev.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 455 Lines: 17 Pablo Neira wrote: > 01process_skb.patch: > introduces the new function called netlink_process_skb that does > the sanity checkings for received messages. > 02xfrm.patch: > the modification to make xfrm_user use such new function. > 03rtnetlink.patch: > same thing for rtnetlink. They all look good to me. Depending on what happens with the loginuid patch, audit_receive_skb might be another candidate for replacement. Regards Patrick From chrisw@osdl.org Fri Feb 11 19:06:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 19:06:30 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C36OmI017544 for ; Fri, 11 Feb 2005 19:06:25 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C36El15790; Fri, 11 Feb 2005 19:06:14 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C36Dk05032; Fri, 11 Feb 2005 19:06:13 -0800 Date: Fri, 11 Feb 2005 19:06:13 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] remove unused ethertap_mc support Message-ID: <20050211190613.S24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 4338 Lines: 155 There is no Kconfig option to enable CONFIG_ETHERTAP_MC, and if you could the resulting source would not build. That code uses the obsolete protinfo union, then further pokes into a privately defined netlink structure to setup the groups. Remove this broken code altogether. It'd be nice to remove ethertap altogether in favor of tun/tap, but at lest remove the bits that won't build in case ethertap is still used. Signed-off-by: Chris Wright drivers/net/ethertap.c | 84 ------------------------------------------------- 1 files changed, 84 deletions(-) ===== drivers/net/ethertap.c 1.15 vs edited ===== --- 1.15/drivers/net/ethertap.c 2004-10-28 16:32:42 -07:00 +++ edited/drivers/net/ethertap.c 2005-02-11 18:53:25 -08:00 @@ -38,9 +38,6 @@ static int ethertap_start_xmit(struct s static int ethertap_close(struct net_device *dev); static struct net_device_stats *ethertap_get_stats(struct net_device *dev); static void ethertap_rx(struct sock *sk, int len); -#ifdef CONFIG_ETHERTAP_MC -static void set_multicast_list(struct net_device *dev); -#endif static int ethertap_debug; @@ -57,9 +54,6 @@ static struct net_device **tap_map; /* R struct net_local { struct sock *nl; -#ifdef CONFIG_ETHERTAP_MC - __u32 groups; -#endif struct net_device_stats stats; }; @@ -96,9 +90,6 @@ static int __init ethertap_probe(int un dev->hard_start_xmit = ethertap_start_xmit; dev->stop = ethertap_close; dev->get_stats = ethertap_get_stats; -#ifdef CONFIG_ETHERTAP_MC - dev->set_multicast_list = set_multicast_list; -#endif dev->tx_queue_len = 0; dev->flags|=IFF_NOARP; @@ -134,41 +125,6 @@ static int ethertap_open(struct net_devi return 0; } -#ifdef CONFIG_ETHERTAP_MC -static unsigned ethertap_mc_hash(__u8 *dest) -{ - unsigned idx = 0; - idx ^= dest[0]; - idx ^= dest[1]; - idx ^= dest[2]; - idx ^= dest[3]; - idx ^= dest[4]; - idx ^= dest[5]; - return 1U << (idx&0x1F); -} - -static void set_multicast_list(struct net_device *dev) -{ - unsigned groups = ~0; - struct net_local *lp = netdev_priv(dev); - - if (!(dev->flags&(IFF_NOARP|IFF_PROMISC|IFF_ALLMULTI))) { - struct dev_mc_list *dmi; - - groups = ethertap_mc_hash(dev->broadcast); - - for (dmi=dev->mc_list; dmi; dmi=dmi->next) { - if (dmi->dmi_addrlen != 6) - continue; - groups |= ethertap_mc_hash(dmi->dmi_addr); - } - } - lp->groups = groups; - if (lp->nl) - lp->nl->protinfo.af_netlink.groups = groups; -} -#endif - /* * We transmit by throwing the packet at netlink. We have to clone * it for 2.0 so that we dev_kfree_skb() the locked original. @@ -177,9 +133,6 @@ static void set_multicast_list(struct ne static int ethertap_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct net_local *lp = netdev_priv(dev); -#ifdef CONFIG_ETHERTAP_MC - struct ethhdr *eth = (struct ethhdr*)skb->data; -#endif if (skb_headroom(skb) < 2) { static int once; @@ -213,31 +166,13 @@ static int ethertap_start_xmit(struct sk lp->stats.tx_bytes+=skb->len; lp->stats.tx_packets++; -#ifndef CONFIG_ETHERTAP_MC netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC); -#else - if (dev->flags&IFF_NOARP) { - netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC); - return 0; - } - - if (!(eth->h_dest[0]&1)) { - /* Unicast packet */ - __u32 pid; - memcpy(&pid, eth->h_dest+2, 4); - netlink_unicast(lp->nl, skb, ntohl(pid), MSG_DONTWAIT); - } else - netlink_broadcast(lp->nl, skb, 0, ethertap_mc_hash(eth->h_dest), GFP_ATOMIC); -#endif return 0; } static __inline__ int ethertap_rx_skb(struct sk_buff *skb, struct net_device *dev) { struct net_local *lp = netdev_priv(dev); -#ifdef CONFIG_ETHERTAP_MC - struct ethhdr *eth = (struct ethhdr*)(skb->data + 2); -#endif int len = skb->len; if (len < 16) { @@ -250,25 +185,6 @@ static __inline__ int ethertap_rx_skb(st kfree_skb(skb); return -EPERM; } - -#ifdef CONFIG_ETHERTAP_MC - if (!(dev->flags&(IFF_NOARP|IFF_PROMISC))) { - int drop = 0; - - if (eth->h_dest[0]&1) { - if (!(ethertap_mc_hash(eth->h_dest)&lp->groups)) - drop = 1; - } else if (memcmp(eth->h_dest, dev->dev_addr, 6) != 0) - drop = 1; - - if (drop) { - if (ethertap_debug > 3) - printk(KERN_DEBUG "%s : not for us\n", dev->name); - kfree_skb(skb); - return -EINVAL; - } - } -#endif if (skb_shared(skb)) { struct sk_buff *skb2 = skb; From chrisw@osdl.org Fri Feb 11 19:55:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Feb 2005 19:55:34 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C3tRgE018865 for ; Fri, 11 Feb 2005 19:55:27 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C3tLl23153; Fri, 11 Feb 2005 19:55:21 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C3tK806223; Fri, 11 Feb 2005 19:55:20 -0800 Date: Fri, 11 Feb 2005 19:55:20 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] remove unused netlink NL_EMULATE_DEV code Message-ID: <20050211195520.T24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1948 Lines: 71 NL_EMULATE_DEV handler functions can't ever be set, so let's rip them out too. I realize the other half (netlink_attach()) just came out in 2.6.11-rc1, but what's left behind can't be used at all. Signed-off-by: Chris Wright af_netlink.c | 24 +----------------------- 1 files changed, 1 insertion(+), 23 deletions(-) ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00 +++ edited/net/netlink/af_netlink.c 2005-02-11 19:47:08 -08:00 @@ -55,10 +55,6 @@ #define Nprintk(a...) -#if defined(CONFIG_NETLINK_DEV) || defined(CONFIG_NETLINK_DEV_MODULE) -#define NL_EMULATE_DEV -#endif - struct netlink_opt { u32 pid; @@ -66,7 +62,6 @@ struct netlink_opt u32 dst_pid; unsigned int dst_groups; unsigned long state; - int (*handler)(int unit, struct sk_buff *skb); wait_queue_head_t wait; struct netlink_callback *cb; spinlock_t cb_lock; @@ -596,10 +591,6 @@ int netlink_attachskb(struct sock *sk, s nlk = nlk_sk(sk); -#ifdef NL_EMULATE_DEV - 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); @@ -639,14 +630,6 @@ int netlink_sendskb(struct sock *sk, str 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); @@ -711,12 +694,7 @@ retry: static __inline__ int netlink_broadcast_deliver(struct sock *sk, struct sk_buff *skb) { struct netlink_opt *nlk = nlk_sk(sk); -#ifdef NL_EMULATE_DEV - if (nlk->handler) { - nlk->handler(sk->sk_protocol, skb); - return 0; - } else -#endif + if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && !test_bit(0, &nlk->state)) { skb_set_owner_r(skb, sk); From chrisw@osdl.org Sat Feb 12 01:01:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 01:01:44 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C91Vm4032526 for ; Sat, 12 Feb 2005 01:01:31 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C919l24316; Sat, 12 Feb 2005 01:01:09 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C919X19043; Sat, 12 Feb 2005 01:01:09 -0800 Date: Sat, 12 Feb 2005 01:01:09 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: [RFC][PATCH 0/3] netlink check sender Message-ID: <20050212010109.V24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1055 Lines: 23 The following patches are for comment. They introduce a new callback to enable netlink messages to be validated in the sender's context, and then convert a couple kernel netlink receivers to use this callback. This eliminates the need to copy the sender's effective capabilities into the netlink control buffer. It also allows the audit system to manage the loginuid in the kernel without adding more fields to netlink_skb_parms or requiring special case netlink code. I think this would obsolete the security_netlink_recv hook, and simplify the security_netlink_send hook. Currently I've only hooked the unicast messages, because I didn't think any of the kernel netlink input functions would be processing broadcast messages (perhaps I missed something). I didn't move the logic that simply ignores messages (e.g. type < RTM_BASE), but I did move the logic that looks for invalid messages (e.g. type > RTM_MAX) to the check_sender callback. Thoughts? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From chrisw@osdl.org Sat Feb 12 01:02:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 01:03:03 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C92wR6000385 for ; Sat, 12 Feb 2005 01:02:58 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C92hl24619; Sat, 12 Feb 2005 01:02:43 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C92ho19062; Sat, 12 Feb 2005 01:02:43 -0800 Date: Sat, 12 Feb 2005 01:02:43 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: [RFC][PATCH 1/3] netlink check sender Message-ID: <20050212010243.W24171@build.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050212010109.V24171@build.pdx.osdl.net>; from chrisw@osdl.org on Sat, Feb 12, 2005 at 01:01:09AM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 3112 Lines: 83 * Add check_sender callback to struct netlink_opt. * Add netlink_kernel_create_check() to register that callback, and turn netlink_kernel_create() into a simple wrapper around that. * Invoke callback when set to verify sender in sender's context. ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00 +++ edited/net/netlink/af_netlink.c 2005-02-11 18:05:59 -08:00 @@ -71,6 +71,7 @@ struct netlink_opt struct netlink_callback *cb; spinlock_t cb_lock; void (*data_ready)(struct sock *sk, int bytes); + int (*check_sender)(struct sk_buff *skb); }; #define nlk_sk(__sk) ((struct netlink_opt *)(__sk)->sk_protinfo) @@ -636,9 +637,17 @@ int netlink_attachskb(struct sock *sk, s int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) { struct netlink_opt *nlk; - int len = skb->len; - + int err, len = skb->len; + nlk = nlk_sk(sk); + + printk("%s: %s(%d) send_check %p\n", __FUNCTION__, current->comm, current->pid, nlk->check_sender); + if (nlk->check_sender) + if ((err = nlk->check_sender(skb))) { + netlink_detachskb(sk, skb); + return err; + } + #ifdef NL_EMULATE_DEV if (nlk->handler) { skb_orphan(skb); @@ -1033,7 +1042,8 @@ static void netlink_data_ready(struct so */ struct sock * -netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) +netlink_kernel_create_check(int unit, void (*input)(struct sock *sk, int len), + int (*check)(struct sk_buff *skb)) { struct socket *sock; struct sock *sk; @@ -1053,8 +1063,10 @@ netlink_kernel_create(int unit, void (*i } sk = sock->sk; sk->sk_data_ready = netlink_data_ready; - if (input) + if (input) { nlk_sk(sk)->data_ready = input; + nlk_sk(sk)->check_sender = check; + } if (netlink_insert(sk, 0)) { sock_release(sock); @@ -1459,7 +1471,7 @@ MODULE_ALIAS_NETPROTO(PF_NETLINK); EXPORT_SYMBOL(netlink_ack); EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); -EXPORT_SYMBOL(netlink_kernel_create); +EXPORT_SYMBOL(netlink_kernel_create_check); EXPORT_SYMBOL(netlink_register_notifier); EXPORT_SYMBOL(netlink_set_err); EXPORT_SYMBOL(netlink_set_nonroot); ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-06 21:59:39 -08:00 +++ edited/include/linux/netlink.h 2005-02-11 14:56:23 -08:00 @@ -116,7 +116,11 @@ struct netlink_skb_parms #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) -extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern struct sock *netlink_kernel_create_check(int unit, void (*input)(struct sock *sk, int len), int (*check)(struct sk_buff *skb)); +static inline struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) +{ + return netlink_kernel_create_check(unit, input, NULL); +} extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, From chrisw@osdl.org Sat Feb 12 01:05:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 01:05:25 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C95LFk001195 for ; Sat, 12 Feb 2005 01:05:22 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C956l24851; Sat, 12 Feb 2005 01:05:06 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C954A19114; Sat, 12 Feb 2005 01:05:04 -0800 Date: Sat, 12 Feb 2005 01:05:04 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050212010504.X24171@build.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050212010243.W24171@build.pdx.osdl.net>; from chrisw@osdl.org on Sat, Feb 12, 2005 at 01:02:43AM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 2031 Lines: 73 Add audit_check_sender() function for audit netlink messages. This can also be used to set the loginuid, although I left that off for the moment. ===== kernel/audit.c 1.9 vs edited ===== --- 1.9/kernel/audit.c 2005-01-30 22:33:47 -08:00 +++ edited/kernel/audit.c 2005-02-11 22:25:33 -08:00 @@ -309,27 +309,36 @@ nlmsg_failure: /* Used by NLMSG_PUT */ * Check for appropriate CAP_AUDIT_ capabilities on incoming audit * control messages. */ -static int audit_netlink_ok(kernel_cap_t eff_cap, u16 msg_type) +static int audit_check_sender(struct sk_buff *skb) { - int err = 0; + struct nlmsghdr *nlh; + u16 msg_type; + int err = -EINVAL; + if (skb->len < NLMSG_LENGTH(0)) + goto out; + + nlh = (struct nlmsghdr *)skb->data; + msg_type = nlh->nlmsg_type; + + err = 0; switch (msg_type) { case AUDIT_GET: case AUDIT_LIST: case AUDIT_SET: case AUDIT_ADD: case AUDIT_DEL: - if (!cap_raised(eff_cap, CAP_AUDIT_CONTROL)) + if (!capable(CAP_AUDIT_CONTROL)) err = -EPERM; break; case AUDIT_USER: - if (!cap_raised(eff_cap, CAP_AUDIT_WRITE)) + if (!capable(CAP_AUDIT_WRITE)) err = -EPERM; break; default: /* bad msg */ err = -EINVAL; } - +out: return err; } @@ -338,14 +347,10 @@ static int audit_receive_msg(struct sk_b u32 uid, pid, seq; void *data; struct audit_status *status_get, status_set; - int err; + int err = 0; struct audit_buffer *ab; u16 msg_type = nlh->nlmsg_type; - err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type); - if (err) - return err; - pid = NETLINK_CREDS(skb)->pid; uid = NETLINK_CREDS(skb)->uid; seq = nlh->nlmsg_seq; @@ -551,7 +556,7 @@ int __init audit_init(void) { printk(KERN_INFO "audit: initializing netlink socket (%s)\n", audit_default ? "enabled" : "disabled"); - audit_sock = netlink_kernel_create(NETLINK_AUDIT, audit_receive); + audit_sock = netlink_kernel_create_check(NETLINK_AUDIT, audit_receive, audit_check_sender); if (!audit_sock) audit_panic("cannot initialize netlink socket"); From chrisw@osdl.org Sat Feb 12 01:06:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 01:07:01 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C96vlV001676 for ; Sat, 12 Feb 2005 01:06:57 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1C96Xl24940; Sat, 12 Feb 2005 01:06:33 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1C96WC19135; Sat, 12 Feb 2005 01:06:32 -0800 Date: Sat, 12 Feb 2005 01:06:32 -0800 From: Chris Wright To: netdev@oss.sgi.com Cc: davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: [RFC][PATCH 3/3] netlink check sender, rtnetlink Message-ID: <20050212010632.Y24171@build.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050212010504.X24171@build.pdx.osdl.net>; from chrisw@osdl.org on Sat, Feb 12, 2005 at 01:05:04AM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 2026 Lines: 74 Add rtnetlink_check_sender() function to validate rtnetlink messages in sender context. Invalid messages (due to content or sender privileges) will be rejected before queued to socket. ===== net/core/rtnetlink.c 1.33 vs edited ===== --- 1.33/net/core/rtnetlink.c 2005-01-10 13:42:22 -08:00 +++ edited/net/core/rtnetlink.c 2005-02-12 00:13:46 -08:00 @@ -462,8 +462,32 @@ static int rtnetlink_done(struct netlink static struct rtattr **rta_buf; static int rtattr_max; -/* Process one rtnetlink message. */ +static int rtnetlink_check_sender(struct sk_buff *skb) +{ + struct nlmsghdr *nlh; + int kind; + int type; + + if (skb->len < NLMSG_LENGTH(0)) + return -EINVAL; + + nlh = (struct nlmsghdr *)skb->data; + type = nlh->nlmsg_type; + + /* Unknown message: reply with EINVAL */ + if (type > RTM_MAX) + return -EINVAL; + + type -= RTM_BASE; + kind = type&3; + if (kind != 2 && !capable(CAP_NET_ADMIN)) + return -EPERM; + + return 0; +} + +/* Process one rtnetlink message. */ static __inline__ int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, int *errp) { @@ -485,10 +509,6 @@ rtnetlink_rcv_msg(struct sk_buff *skb, s if (type < RTM_BASE) return 0; - /* Unknown message: reply with EINVAL */ - if (type > RTM_MAX) - goto err_inval; - type -= RTM_BASE; /* All the messages must have at least 1 byte length */ @@ -509,11 +529,6 @@ rtnetlink_rcv_msg(struct sk_buff *skb, s sz_idx = type>>2; kind = type&3; - if (kind != 2 && security_netlink_recv(skb)) { - *errp = -EPERM; - return -1; - } - if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) { u32 rlen; @@ -690,7 +705,8 @@ void __init rtnetlink_init(void) if (!rta_buf) panic("rtnetlink_init: cannot allocate rta_buf\n"); - rtnl = netlink_kernel_create(NETLINK_ROUTE, rtnetlink_rcv); + rtnl = netlink_kernel_create_check(NETLINK_ROUTE, rtnetlink_rcv, + rtnetlink_check_sender); if (rtnl == NULL) panic("rtnetlink_init: cannot initialize rtnetlink\n"); netlink_set_nonroot(NETLINK_ROUTE, NL_NONROOT_RECV); From ak@muc.de Sat Feb 12 04:11:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 04:11:57 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CCBias008708 for ; Sat, 12 Feb 2005 04:11:45 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id E8BB3D033E; Sat, 12 Feb 2005 13:11:43 +0100 (CET) To: "David S. Miller" Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> From: Andi Kleen Date: Sat, 12 Feb 2005 13:11:43 +0100 In-Reply-To: <20050211170740.2608419b.davem@davemloft.net> (David S. Miller's message of "Fri, 11 Feb 2005 17:07:40 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1561 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: 337 Lines: 12 "David S. Miller" writes: > > I guess this is e1000. Any e1000 internals experts reading > here who can comment on how e1000's TSO engine treats the > PSH flag? If that is the problem it should be easy to test for. Just disable TSO with ethtool -K ethX tso off Hubert, does that make the problem go away? -Andi From hadi@cyberus.ca Sat Feb 12 05:33:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 05:33:08 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CDX1cn013989 for ; Sat, 12 Feb 2005 05:33:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CzxOL-0007qx-Di for netdev@oss.sgi.com; Sat, 12 Feb 2005 08:32:57 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CzxOJ-0001tO-AG; Sat, 12 Feb 2005 08:32:55 -0500 Subject: Re: ipt_ROUTE and destination MAC address From: jamal Reply-To: hadi@cyberus.ca To: junk Cc: netdev@oss.sgi.com In-Reply-To: <20050211123718.M74819@toutatis.be> References: <20050211123718.M74819@toutatis.be> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108215170.1178.106.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Feb 2005 08:32:50 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1562 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: 2485 Lines: 79 Maybe if you describe your purpose it would help more. I dont know what ROUTE or red0 is, but you could essentially use mirred action to mirror or redirect packets to any interface you want; examples (part of iproute/doc): Host A is hooked up to us on eth0 for these examples 1) tc qdisc add dev lo ingress # redirect all packets arriving on ingress of lo to eth0 tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:2 action mirred egress redirect dev eth0 2) #allow every 10th packet to be sent to be copied to eth0 # you could sample better by using netrand insted of determ # tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:2 \ action drop random determ ok 10\ action mirred egress mirror dev eth0 3) # for packets coming from 10.0.0.9: #Redirect packets on egress (to ISP A) if you exceed a certain rate # to eth1 (to ISP B) if you exceed a certain rate # tc qdisc add dev eth0 handle 1:0 root prio tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \ match ip src 10.0.0.9/32 flowid 1:16 \ action police rate 100kbit burst 90k ok \ action mirred egress mirror dev eth1 4) # repeat above but send packets to dummy0 as well so you can see them # with tcpdump: tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \ match ip src 10.0.0.9/32 flowid 1:16 \ action police rate 100kbit burst 90k ok \ action mirred egress mirror dev eth1 \ action mirred egress mirror dev dummy0 Again, dont know what you are trying to do, so i gave you a shotgun answer and i could almost swear you are probably trying to hardcode one of these scenarios by writting a driver ;-> cheers, jamal On Fri, 2005-02-11 at 07:39, junk wrote: > Hello, > > i'm coding a virtual interface. That virtual interface has to receive packets > coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can > see my packets arriving on red0 (my virtual interface). > > But there is a problem.. > > If i send an icmp request to 10.0.1.1 from another computer: > > The icmp request arrives on the physical interface, ROUTE target makes it > arrive on red0 > > icmp request arriving on red0: 10.0.0.1 > > The problem is that the destination MAC is the one of eth0, so, it seems the > kernel doesn't really deliver the packet to my driver. I can see it in tcpdump > but my driver receive function is never called. > > I tried every -j ROUTE option, --gw or --iif, with --continue, or not.. > > Any idea? > > From hadi@cyberus.ca Sat Feb 12 05:45:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 05:45:42 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CDjYaD014603 for ; Sat, 12 Feb 2005 05:45:36 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CzxaU-0003J3-Ob for netdev@oss.sgi.com; Sat, 12 Feb 2005 08:45:30 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CzxaQ-0003RB-SZ; Sat, 12 Feb 2005 08:45:27 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: jamal Reply-To: hadi@cyberus.ca To: Dan Siemon Cc: netdev@oss.sgi.com In-Reply-To: <1108134446.5523.22.camel@ganymede> References: <20050117165626.GE26856@postel.suug.ch> <1106002197.1046.19.camel@jzny.localdomain> <20050118134406.GR26856@postel.suug.ch> <1106058592.1035.95.camel@jzny.localdomain> <20050118145830.GS26856@postel.suug.ch> <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108215923.1126.132.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Feb 2005 08:45:23 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1563 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: 1897 Lines: 40 On first impression, this looks very nice - I think you got the object hierachy figured etc; i will look closely later. What would be really interesting is to see (gulp) a SOAP/xml interface on top of this. Is this something you can do with those "bindings"? It seems to me from a library perspective, youa nd Thomas may have to sync. And restricting to just QoS maybe be a limitation (netlink is the friend you are looking for; so from networking perspective, give them GUI clikers ways to set routes, static IPSEC SAs etc). Oh and it would be interesting to have events (see that link come up down etc) cheers, jamal On Fri, 2005-02-11 at 10:07, Dan Siemon wrote: > On Wed, 2005-26-01 at 08:48 -0500, jamal wrote: > > Your call really - you are the one who is going to maintain it;-> > > As for ease of use and avoiding users from knowing details of how > > tlvs are put together etc - i think it doesnt matter how thats done > > underneath the hood; it is still doable on top of current libnetlink. In > > other words whats required, IMO, is something that hides netlink totaly > > so that the programmer/user doesnt even get to see TLVs. > > (Sorry to join this thread so late.) > > I'd like to make a little plug for my Linux QoS Library (LQL) [1] > project. LQL provides an abstraction of the kernel QoS features. Full > API documentation is available from the website. > > I already have working bindings for one high level language (C# on Mono) > [2]. Creating bindings for Python, Perl etc should be quite easy. > Someone recently emailed me about starting work on Perl bindings. > > There is still lots of work to do. Support for more QDiscs and > classifiers is needed and the socket handling code needs a rewrite to > better handle errors. Work continues and these things will be fixed. > > [1] - http://www.coverfire.com/lql/ > [2] - http://www.coverfire.com/lql-sharp/ From kuznet@yakov.inr.ac.ru Sat Feb 12 06:17:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 06:17:41 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CEHTrp015661 for ; Sat, 12 Feb 2005 06:17:30 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=MptRSHTvitUXWaxAXqHBhz2AgtHSZFWzsuy9QQxSuu/8dc9souMXyvzCwPIuOQXoG6CAo64InksrJzYabPFQX6bY03fgnRNBw+P7rujOdhPUvrMQnWpv5JIBkkoHdUpQhEJIHk3iJGFIbvgTMhkQVCQY7iV2rlSClgNn5gQE3JU=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id RAA27479; Sat, 12 Feb 2005 17:16:41 +0300 Date: Sat, 12 Feb 2005 17:16:41 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Stephen Hemminger , hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212141641.GA27456@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211170740.2608419b.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1564 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: 598 Lines: 20 Hello! > This set of data frames you quoted are all full, and > are tightly interspaced. It looks exactly like a TSO > frame, which we certainly set PSH on, but the TSO > engine is dropping it aparently. > > I guess this is e1000. Any e1000 internals experts reading > here who can comment on how e1000's TSO engine treats the > PSH flag? Or it was two one-segment frames. Before blaming on e1000 it would be easier to confirm that linux never worked with MacOS X, except for those kernels which had congestion avoidance mostly supppressed. I.e. let's disable TSO in 2.6.9 and look. Alexey From tgraf@suug.ch Sat Feb 12 06:29:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 06:29:33 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CETQoP016355 for ; Sat, 12 Feb 2005 06:29:26 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 01BC5F; Sat, 12 Feb 2005 15:29:01 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BB9D81C0EA; Sat, 12 Feb 2005 15:29:43 +0100 (CET) Date: Sat, 12 Feb 2005 15:29:43 +0100 From: Thomas Graf To: jamal Cc: Dan Siemon , netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050212142943.GF31837@postel.suug.ch> References: <20050118145830.GS26856@postel.suug.ch> <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108215923.1126.132.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2687 Lines: 57 > > I'd like to make a little plug for my Linux QoS Library (LQL) [1] > > project. LQL provides an abstraction of the kernel QoS features. Full > > API documentation is available from the website. I've been looking at this before and I do like your approach. The license prevents me from really using it buts that's not your problem. What I really like about it are the bindings to other languages, that's definitely a good thing. * jamal <1108215923.1126.132.camel@jzny.localdomain> 2005-02-12 08:45 > What would be really interesting is to see (gulp) a SOAP/xml interface > on top of this. Is this something you can do with those "bindings"? Indeed, an xml interface would be really nice to have. I've been implementing some xml bits for links and neighbour in libnl so far but i'm not yet sure about the exact format until I'm sure there is no existing format that would fit us. > It seems to me from a library perspective, youa nd Thomas may have to > sync. Sure, I'm willing to sync as long as the result stays LGPL. The architectures are quite different so I think the only code we can share or convert are the actual qdisc/class/filter modules to parse the netlink messages and do various translations of types and flags etc. > And restricting to just QoS maybe be a limitation (netlink is the > friend you are looking for; so from networking perspective, give them > GUI clikers ways to set routes, static IPSEC SAs etc). Oh and it would > be interesting to have events (see that link come up down etc) Although it's possible to receive multicast group messages I haven't added a specific API into it and you have to do the demuxing of the various messages types yourself for now (via valid message callback). Maybe a quick status report about what's done: - core netlink API: 80%, lacks better support for non-blocking sockets and for multicast grouping messages - link: 100% - neighbour: 100% - route: 70%, msg parser and attribte setting done, still lacks a good dumping procedure and message building - address: partial patch received which works more or less, someone has started working on it again - rule: 0% - tc 50% still lacks implementations for various qdiscs and classifiers I haven't touched any other netlink users such as xfrm but those should be easier to do actually, rtnetlink is the biggest ;-> I've been spending some time on documenting the existing API and about 40% is done by now. You can have a look at the current progress of the documentation, the neighbour and link documentation is nearly finished and gives you the best impression. http://people.suug.ch/~tgr/libnl/doc/modules.html From kuznet@yakov.inr.ac.ru Sat Feb 12 06:31:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 06:31:35 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CEVU0a016881 for ; Sat, 12 Feb 2005 06:31:31 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=lUpJSpMmu0fleKOIeaiV4a+zEnhM9wIONAj9odyKDsgTAPBFo051mLg96PFI2dGoqog514KE6EmkY+UagIr1EKNDsrAgbVGgRFQU7RIo1RWGl8A6iSj7l1UD+XooSqsGbnBdPurrunzZK0r/u/9Wyzz+7Kh1hu31GV5cZXmo3Io=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id RAA27617; Sat, 12 Feb 2005 17:31:05 +0300 Date: Sat, 12 Feb 2005 17:31:05 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Rick Jones , hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212143105.GB27456@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211170958.17fcde21.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1566 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: 622 Lines: 19 Hello! > > In some cases at least if the sender does not completely fill cwnd the > > ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the > > sender does not always fill cwnd. > > At a maximum, "1/tcp_tso_win_divisor" of the cwnd will ever be left > empty. > > By default, this is 1/8 of the cwnd. In any case, receiver cannot know sender cwnd, so that "fill" or "not fill" is is not a question. What is broken in that implementation is that it does not feel slow start. ACK avoidance while slow start is certain disaster. Currrent theory is that MacOS X thinks that we do not do slow start. Alexey From pablo@eurodev.net Sat Feb 12 08:48:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 08:48:26 -0800 (PST) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CGmDYS023489 for ; Sat, 12 Feb 2005 08:48:14 -0800 Received: from eurodev.net ([85.136.117.201]) by smtp08.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050212164807.YCPD4106.smtp08.retemail.es@eurodev.net>; Sat, 12 Feb 2005 17:48:07 +0100 Message-ID: <420E334B.8060805@eurodev.net> Date: Sat, 12 Feb 2005 17:48:11 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> In-Reply-To: <20050212010504.X24171@build.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1311 Lines: 39 Chris Wright wrote: >Add audit_check_sender() function for audit netlink messages. This can also >be used to set the loginuid, although I left that off for the moment. > >===== kernel/audit.c 1.9 vs edited ===== >--- 1.9/kernel/audit.c 2005-01-30 22:33:47 -08:00 >+++ edited/kernel/audit.c 2005-02-11 22:25:33 -08:00 >@@ -309,27 +309,36 @@ nlmsg_failure: /* Used by NLMSG_PUT */ > * Check for appropriate CAP_AUDIT_ capabilities on incoming audit > * control messages. > */ >-static int audit_netlink_ok(kernel_cap_t eff_cap, u16 msg_type) >+static int audit_check_sender(struct sk_buff *skb) > { >- int err = 0; >+ struct nlmsghdr *nlh; >+ u16 msg_type; >+ int err = -EINVAL; > >+ if (skb->len < NLMSG_LENGTH(0)) >+ goto out; >+ >+ nlh = (struct nlmsghdr *)skb->data; >+ msg_type = nlh->nlmsg_type; > > You're introducing some kind of check for malformed packets here as well, don't you think that such thing should be done by the receiver ? I also see another option which is passing as parameter such function which check for capabilities/audit stuff to my netlink_process_skb function, calling it before process_msg. But in that case, the packet sent by a sender that doesn't has the right to was already enqueued. I understand that this is exactly what you are trying to avoid. -- Pablo From olh@suse.de Sat Feb 12 09:15:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 09:15:33 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CHFREj024550 for ; Sat, 12 Feb 2005 09:15:28 -0800 Received: from hermes.suse.de (hermes-ext.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 B07631463018 for ; Sat, 12 Feb 2005 18:15:21 +0100 (CET) Date: Sat, 12 Feb 2005 18:15:21 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: the remaining purpose of cmsg_nxthdr() Message-ID: <20050212171521.GA3497@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 1457 Lines: 47 Are there still valid users of ? All I found was uClibc-0.9.26/include/netinet/ip_tcp.h, which should probably include their sys/socket.h instead. diff -purN linux-2.6.11-rc3-bk8/include/linux/socket.h linux-2.6.11/include/linux/socket.h --- linux-2.6.11-rc3-bk8/include/linux/socket.h 2005-02-03 02:56:33.000000000 +0100 +++ linux-2.6.11/include/linux/socket.h 2005-02-12 18:05:10.000000000 +0100 @@ -95,20 +95,8 @@ struct cmsghdr { ((mhdr)->msg_controllen - \ ((char *)(cmsg) - (char *)(mhdr)->msg_control))) -/* - * This mess will go away with glibc - */ - #ifdef __KERNEL__ #define __KINLINE static inline -#elif defined(__GNUC__) -#define __KINLINE static __inline__ -#elif defined(__cplusplus) -#define __KINLINE static inline -#else -#define __KINLINE static -#endif - /* * Get the next cmsg header @@ -120,7 +108,7 @@ struct cmsghdr { * Now it always returns valid, not truncated ancillary object * HEADER. But caller still MUST check, that cmsg->cmsg_len is * inside range, given by msg->msg_controllen before using - * ansillary object DATA. --ANK (980731) + * ancillary object DATA. --ANK (980731) */ __KINLINE struct cmsghdr * __cmsg_nxthdr(void *__ctl, __kernel_size_t __size, @@ -139,6 +127,7 @@ __KINLINE struct cmsghdr * cmsg_nxthdr ( { return __cmsg_nxthdr(__msg->msg_control, __msg->msg_controllen, __cmsg); } +#endif /* "Socket"-level control message types: */ From davem@davemloft.net Sat Feb 12 11:25:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 11:25:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CJPrbR027970 for ; Sat, 12 Feb 2005 11:25:54 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D02rD-0005iw-00; Sat, 12 Feb 2005 11:23:07 -0800 Date: Sat, 12 Feb 2005 11:23:07 -0800 From: "David S. Miller" To: Andi Kleen Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050212112307.00fefaa2.davem@davemloft.net> In-Reply-To: References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 545 Lines: 17 On Sat, 12 Feb 2005 13:11:43 +0100 Andi Kleen wrote: > "David S. Miller" writes: > > > > I guess this is e1000. Any e1000 internals experts reading > > here who can comment on how e1000's TSO engine treats the > > PSH flag? > > If that is the problem it should be easy to test for. Just > disable TSO with ethtool -K ethX tso off > > Hubert, does that make the problem go away? We're testing the new code that sets PSH on every TSO frame. If we disable TSO, the new code won't be exercised nor tested. :-) From davem@davemloft.net Sat Feb 12 11:30:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 11:30:21 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CJUFpG028466 for ; Sat, 12 Feb 2005 11:30:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D02w7-0005jn-00; Sat, 12 Feb 2005 11:28:11 -0800 Date: Sat, 12 Feb 2005 11:28:11 -0800 From: "David S. Miller" To: Alexey Kuznetsov Cc: rick.jones2@hp.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050212112811.13a0b97d.davem@davemloft.net> In-Reply-To: <20050212143105.GB27456@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 486 Lines: 12 On Sat, 12 Feb 2005 17:31:05 +0300 Alexey Kuznetsov wrote: > In any case, receiver cannot know sender cwnd, so that "fill" or "not fill" > is is not a question. > > What is broken in that implementation is that it does not feel slow start. > ACK avoidance while slow start is certain disaster. Currrent theory is that > MacOS X thinks that we do not do slow start. It is correct. Although, I am still believing that setting PSH is the avenue of investigation. From davem@davemloft.net Sat Feb 12 11:43:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 11:43:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CJhgPp029235 for ; Sat, 12 Feb 2005 11:43:42 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D0393-0005nU-00; Sat, 12 Feb 2005 11:41:33 -0800 Date: Sat, 12 Feb 2005 11:41:32 -0800 From: "David S. Miller" To: Alexey Kuznetsov Cc: shemminger@osdl.org, hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050212114132.5f7b7ffe.davem@davemloft.net> In-Reply-To: <20050212141641.GA27456@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> <20050212141641.GA27456@yakov.inr.ac.ru> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 828 Lines: 22 On Sat, 12 Feb 2005 17:16:41 +0300 Alexey Kuznetsov wrote: > > This set of data frames you quoted are all full, and > > are tightly interspaced. It looks exactly like a TSO > > frame, which we certainly set PSH on, but the TSO > > engine is dropping it aparently. ... > Or it was two one-segment frames. Even ignoring my TSO changes, we should be seeing at a minimum 1/2 window PSH settings which we're not as far as I can tell. (this is due to the forced_push() test in net/ipv4/tcp.c) This also points out a bug in my TSO PSH patch, I should be updating tp->pushed_seq shouldn't I? Question is, what to set it to? I think correct value is TCP_SKB_CB(skb)->end_seq. > I.e. let's disable TSO in 2.6.9 and look. I believe this experiment had been performed already. Stephen, isn't that the case? From leonid.grossman@neterion.com Sat Feb 12 11:47:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 11:47:58 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CJlqW0029766 for ; Sat, 12 Feb 2005 11:47:53 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1CJjZdG027202; Sat, 12 Feb 2005 14:45:35 -0500 (EST) Received: from lgt40 ([10.16.16.165]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1CJjWDD016296; Sat, 12 Feb 2005 14:45:32 -0500 (EST) Message-Id: <200502121945.j1CJjWDD016296@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" , "'Alexey Kuznetsov'" Cc: , , , , , Subject: RE: 2.6.10 TCP troubles -- suggested patch Date: Sat, 12 Feb 2005 11:44:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050212112811.13a0b97d.davem@davemloft.net> Thread-Index: AcUROUun7s9Fsk1KTAO5B8ecDKm8hgAAX8gA X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 32 Typically, a TSO engine sets PSH in the last packet that it builds for the TSO+PSH request. Leonid > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of David S. Miller > Sent: Saturday, February 12, 2005 11:28 AM > To: Alexey Kuznetsov > Cc: rick.jones2@hp.com; hubert.tonneau@fullpliant.org; > shemminger@osdl.org; romieu@fr.zoreil.com; > kuznet@ms2.inr.ac.ru; netdev@oss.sgi.com > Subject: Re: 2.6.10 TCP troubles -- suggested patch > > On Sat, 12 Feb 2005 17:31:05 +0300 > Alexey Kuznetsov wrote: > > > In any case, receiver cannot know sender cwnd, so that > "fill" or "not fill" > > is is not a question. > > > > What is broken in that implementation is that it does not > feel slow start. > > ACK avoidance while slow start is certain disaster. > Currrent theory is > > that MacOS X thinks that we do not do slow start. > > It is correct. Although, I am still believing that setting > PSH is the avenue of investigation. > > From kuznet@yakov.inr.ac.ru Sat Feb 12 11:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 11:53:52 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CJrlcM030294 for ; Sat, 12 Feb 2005 11:53:48 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=nf0SqowzKX0fDjzBXurgrksczTwWtyxDBvACQxOAKemNamrhSVsWWjogicvmFwzROSREIWJI32TspBHTpFwhyskuuYMWy1E8iPJKTuB//8UwM5NqQyarTKjVl6q5aemSpAz+1FutjZVYJ8+MpgjpgGwimXUSQDpAx6wCsKPu3fQ=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id WAA28944; Sat, 12 Feb 2005 22:52:46 +0300 Date: Sat, 12 Feb 2005 22:52:46 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Alexey Kuznetsov , rick.jones2@hp.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212195246.GA28895@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <20050212112811.13a0b97d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050212112811.13a0b97d.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1573 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: 521 Lines: 14 Hello! > It is correct. Although, I am still believing that setting PSH > is the avenue of investigation. Exactly. That's why the next test should be with disabled TSO in 2.6.9. If too rare PSHs were a problem, it will show as the same disaster there. [ And, to be honest, in this case, I daresay MacOS X may be left with its bugs alone. Or we could help it with something like setting PSH when we are in slow start and each half of CWND after completion of slow start. Or just set PSH on each frame. ] Alexey From kuznet@yakov.inr.ac.ru Sat Feb 12 12:03:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 12:03:56 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CK3n4h031039 for ; Sat, 12 Feb 2005 12:03:50 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=N3wD2vjB7oAZqYvDL3NN+ydVIQkoRBdBaoPkubDaHt/EJ52mCFu4ToDaBOxlzdQz6wgIq7m0s/y/GZLltJOMPK1aaJfxkhotgPgmyKp3WcJMYtct1D7kQis94op/eXqIy60g5uOJs2zb9kXqqddGCnSYLpXyy4fm7UQ4K+R84ZA=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id XAA29009; Sat, 12 Feb 2005 23:03:18 +0300 Date: Sat, 12 Feb 2005 23:03:18 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Alexey Kuznetsov , shemminger@osdl.org, hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212200318.GB28895@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> <20050212141641.GA27456@yakov.inr.ac.ru> <20050212114132.5f7b7ffe.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050212114132.5f7b7ffe.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1574 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: 676 Lines: 23 Hello! > set it to? I think correct value is TCP_SKB_CB(skb)->end_seq. Yup. But it does not matter. When it is not advanced, it does not make PSHs more rare. Actually, that anti-MacOS never worked well. If segment with forced PSH was not transmitted in time, even forced PSHs could be deleted. Your patch with setting PSH right before (or in) tcp_transmit_skb() must work. Unless these segments are not tso. > > I.e. let's disable TSO in 2.6.9 and look. > > I believe this experiment had been performed already. I saw only tests with TSO. And 2.6.9 showed exactly the same weird behaviour. Only 2.6.9 did not slow start and we had only a few of 200msec gaps. Alexey From rick.jones2@hp.com Sat Feb 12 12:20:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 12:20:10 -0800 (PST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CKK4pD002650 for ; Sat, 12 Feb 2005 12:20:04 -0800 Received: from [192.168.1.100] (adsl-67-116-53-82.dsl.sntc01.pacbell.net [67.116.53.82]) by mailhub.hp.com (Postfix) with ESMTP id 960582710E; Sat, 12 Feb 2005 15:19:51 -0500 (EST) In-Reply-To: <20050212143105.GB27456@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <86de38db09518ced8865af09cd79c064@hp.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org From: rick jones Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Sat, 12 Feb 2005 12:19:35 -0800 To: Alexey Kuznetsov X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 39 On Feb 12, 2005, at 6:31 AM, Alexey Kuznetsov wrote: > Hello! > >>> In some cases at least if the sender does not completely fill cwnd >>> the >>> ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the >>> sender does not always fill cwnd. >> >> At a maximum, "1/tcp_tso_win_divisor" of the cwnd will ever be left >> empty. >> >> By default, this is 1/8 of the cwnd. > > In any case, receiver cannot know sender cwnd, so that "fill" or "not > fill" > is is not a question. How is that? Isn't cwnd based on the ACKs the sender receives from the receiver? > What is broken in that implementation is that it does not feel slow > start. > ACK avoidance while slow start is certain disaster. Currrent theory is > that > MacOS X thinks that we do not do slow start. Actually, it may think slow start is being done - there was enough small packet back and forth on the connection before the "heavy transfer" to get cwnd opened - I just didn't quote that in the "cooked" output. All the stacks with ACK avoidance with which I am familiar do not make the assumption that the sender is not doing slow-start. They make sure to send enough ACKs at the beginning (or after packet loss) to allow the sender's cwnd to grow. rick jones wisdom teeth are impacted, people are affected by the effects of events From davem@davemloft.net Sat Feb 12 12:31:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 12:31:06 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CKV1BI003322 for ; Sat, 12 Feb 2005 12:31:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D03sc-0006AU-00; Sat, 12 Feb 2005 12:28:38 -0800 Date: Sat, 12 Feb 2005 12:28:38 -0800 From: "David S. Miller" To: rick jones Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050212122838.76cb838d.davem@davemloft.net> In-Reply-To: <86de38db09518ced8865af09cd79c064@hp.com> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> X-Mailer: Sylpheed version 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 304 Lines: 10 On Sat, 12 Feb 2005 12:19:35 -0800 rick jones wrote: > How is that? Isn't cwnd based on the ACKs the sender receives from the > receiver? ACKs go from sender to receiver, first of all. It is based upon congestion as seen "by receiver", something which is impossible for sender. From kuznet@yakov.inr.ac.ru Sat Feb 12 12:56:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 12:56:27 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CKuLDL004349 for ; Sat, 12 Feb 2005 12:56:22 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=Pydn3Z48gjoXVe9PHa5ZvQYjwEEa/Vi/n8URPSrxy9l4llJTSaW+OstNQJotBc5Hqh4UvpbcQmCYxDQamIP5OyDB/J4AXJEVsnjTpRD96Iv6Cg0Msmo+jdXdpgf9+n/fQfiOkXFVRfqbd2LGSr/oRo+ZkIF+5Pzyt9nmvHdxBQg=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id XAA29185; Sat, 12 Feb 2005 23:56:17 +0300 Date: Sat, 12 Feb 2005 23:56:17 +0300 From: Alexey Kuznetsov To: rick jones Cc: Alexey Kuznetsov , netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212205617.GA29146@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86de38db09518ced8865af09cd79c064@hp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1577 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: 915 Lines: 25 Hello! > Actually, it may think slow start is being done - there was enough > small packet back and forth on the connection before the "heavy > transfer" to get cwnd opened If receiver sent an ACK it still does not mean that sender used it to increase its cwnd. Particularly, small packet exchange definitely does not inflate cwnd. > output. All the stacks with ACK avoidance with which I am familiar do > not make the assumption that the sender is not doing slow-start. They > make sure to send enough ACKs at the beginning (or after packet loss) > to allow the sender's cwnd to grow. Well, we do similar thing with delayed ACKs. And it took a few of runs of testing to understand that we cannot detect even packet loss reliably enough. :-) Actually, those receivers could use the first delayed ACK event as a sign of failure of their heuristics and block stretching acks for this connection. Alexey From pablo@eurodev.net Sat Feb 12 13:19:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 13:19:05 -0800 (PST) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CLJ0M4005436 for ; Sat, 12 Feb 2005 13:19:01 -0800 Received: from eurodev.net ([85.136.113.74]) by smtp08.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050212211854.OTI4106.smtp08.retemail.es@eurodev.net>; Sat, 12 Feb 2005 22:18:54 +0100 Message-ID: <420E72C3.1050307@eurodev.net> Date: Sat, 12 Feb 2005 22:18:59 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH 2/4] [NETLINK] introduce netlink_check_skb function References: <420BF8CB.6080005@eurodev.net> <20050211032448.GD31837@postel.suug.ch> <420D243C.4090507@eurodev.net> <20050211224354.GE31837@postel.suug.ch> In-Reply-To: <20050211224354.GE31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1323 Lines: 33 Hi Thomas, Thomas Graf wrote: >>They are all the same thing. They all return 16 bytes which is the size >>of a netlink header. If you and someone else think that those are more >>readable, I'm ok with it, whatever. I just stole that piece of code as >>is from current checkings done in xfrm and rtnetlink. >> >> > >That's absolutely true, my point is that while reading that line >of code it reads like while the remaining length in the socket buffer >is still greather or equal than the total message size until the next >message with a payload of 0, then do something. It looks confusing at >a first glance because you're not event interested in the payload just >now. A choice of NLMSG_ALIGN(sizeof(*nlh)) or NLMSG_LENGTH(0) clearly >points out that you're just checking for enough room regarding the >netlink header in order to access it safely and do the real sanity >check against the complete message length. Engross that thought a bit >further, NLMSG_SPACE could change at some point assuming that it is >only used in contexts where the total message size is in question. > >If you think that's too much of nitpicking, then forget about it. It's >technicaly absolutely correct at the moment. > > Looks fine you convince me. If this is finally pushed forward, let's replace that line. Thanks. -- Pablo From niv@us.ibm.com Sat Feb 12 13:28:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 13:28:08 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CLS2v2005997 for ; Sat, 12 Feb 2005 13:28:03 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1CLRvlN014398 for ; Sat, 12 Feb 2005 16:27:57 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1CLRuFS278886 for ; Sat, 12 Feb 2005 16:27:56 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1CLRu4o017027 for ; Sat, 12 Feb 2005 16:27:56 -0500 Received: from [9.65.52.28] (sig-9-65-52-28.mts.ibm.com [9.65.52.28]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1CLRsE8017015; Sat, 12 Feb 2005 16:27:55 -0500 Message-ID: <420E74D6.3020100@us.ibm.com> Date: Sat, 12 Feb 2005 13:27:50 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Kuznetsov CC: rick jones , netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> <20050212205617.GA29146@yakov.inr.ac.ru> In-Reply-To: <20050212205617.GA29146@yakov.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1579 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: 418 Lines: 13 Alexey Kuznetsov wrote: > If receiver sent an ACK it still does not mean that sender used it > to increase its cwnd. Particularly, small packet exchange definitely > does not inflate cwnd. Simplest way to go about this is simply compare it to the trace of the "good/fast" connection - Hubert, could you provide the "good" trace as well? That would show where the differences in time are taken up.. thanks, Nivedita From ak@muc.de Sat Feb 12 13:30:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 13:30:37 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CLUVls006477 for ; Sat, 12 Feb 2005 13:30:32 -0800 Received: (qmail 53432 invoked by uid 3709); 12 Feb 2005 21:30:30 -0000 Date: 12 Feb 2005 22:30:30 +0100 Date: Sat, 12 Feb 2005 22:30:30 +0100 From: Andi Kleen To: "David S. Miller" Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212213030.GB51971@muc.de> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> <20050212112307.00fefaa2.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050212112307.00fefaa2.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1580 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: 216 Lines: 7 > We're testing the new code that sets PSH on every TSO frame. > If we disable TSO, the new code won't be exercised nor tested. > :-) Sorry, I read the thread out of order (shouldn't do that) Ignore my mail. -Andi From pablo@eurodev.net Sat Feb 12 13:41:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 13:41:52 -0800 (PST) Received: from smtp07.retemail.es ([62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CLfeZL007130 for ; Sat, 12 Feb 2005 13:41:41 -0800 Received: from eurodev.net ([85.136.113.74]) by smtp07.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050212214109.UFWU10926.smtp07.retemail.es@eurodev.net>; Sat, 12 Feb 2005 22:41:09 +0100 Message-ID: <420E77FA.6080007@eurodev.net> Date: Sat, 12 Feb 2005 22:41:14 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> In-Reply-To: <420E334B.8060805@eurodev.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 982 Lines: 26 Pablo Neira wrote: > I also see another option which is passing as parameter such function > which check for capabilities/audit stuff to my netlink_process_skb > function, calling it before process_msg. But in that case, the packet > sent by a sender that doesn't has the right to was already enqueued. I > understand that this is exactly what you are trying to avoid. With your patch, a message from user space process that doesn't have the capabilites follows this path: sys_sendmsg() -> netlink_sendmsg() -> netlink_unicast() -> netlink_sendskb() = discarded here. Currently, it continues, for example in case of rtnetlink: ... -> netlink_sendskb() -> sk_data_ready(sk, len) -> rtnetlink_rcv() -> rtnetlink_rcv_skb() -> rtnetlink_rcv_msg() = discarded here. Nowadays the message is enqueued but it's discarded later. So if I'm not missing anything, I don't see the point of adding a new function to check for capabilities/audit stuff just a bit before. -- Pablo From rick.jones2@hp.com Sat Feb 12 13:44:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 13:44:14 -0800 (PST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CLiATf007662 for ; Sat, 12 Feb 2005 13:44:11 -0800 Received: from [192.168.1.100] (adsl-67-116-53-82.dsl.sntc01.pacbell.net [67.116.53.82]) by mailhub.hp.com (Postfix) with ESMTP id 1F5112710F; Sat, 12 Feb 2005 16:44:05 -0500 (EST) In-Reply-To: <20050212205617.GA29146@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> <20050212205617.GA29146@yakov.inr.ac.ru> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0db5e06aa50422877f9ec4a2e35d6795@hp.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org From: rick jones Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Sat, 12 Feb 2005 13:43:52 -0800 To: Alexey Kuznetsov X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1105 Lines: 30 > If receiver sent an ACK it still does not mean that sender used it > to increase its cwnd. Particularly, small packet exchange definitely > does not inflate cwnd. Is that in general, or in Linux? >> output. All the stacks with ACK avoidance with which I am familiar do >> not make the assumption that the sender is not doing slow-start. They >> make sure to send enough ACKs at the beginning (or after packet loss) >> to allow the sender's cwnd to grow. > > Well, we do similar thing with delayed ACKs. And it took a few of runs > of testing to understand that we cannot detect even packet loss > reliably > enough. :-) I never claimed it was easy :) > Actually, those receivers could use the first delayed ACK event as > a sign of failure of their heuristics and block stretching acks for > this connection. The ones with which I am familiar do - after N delayed ACK events where N is something other than one though. And they still send immediate ACKs to the senders upon out of order data and all that. rick jones Wisdom teeth are impacted, people are affected by the effects of events From kuznet@yakov.inr.ac.ru Sat Feb 12 14:00:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 14:00:19 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CM0ESh008410 for ; Sat, 12 Feb 2005 14:00:15 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=FbCch73T1685+tptGcLEOkdzWvQ3ZMOZbH4XKm+2Il8vfTsC+WK4Hmxt98DOQA0ADBFulxlaVPntQGFhYbgZhuG0eVdhneCWOqDmVbxxNgVe6LNPYpuVVXqSpM8KVH7ZAoMVGGj8neXo0g9P1Mnz3Wh15CLzy3RsLHSAvfYXduQ=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id BAA29424; Sun, 13 Feb 2005 01:00:10 +0300 Date: Sun, 13 Feb 2005 01:00:10 +0300 From: Alexey Kuznetsov To: rick jones Cc: Alexey Kuznetsov , netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212220010.GA29417@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> <20050212205617.GA29146@yakov.inr.ac.ru> <0db5e06aa50422877f9ec4a2e35d6795@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0db5e06aa50422877f9ec4a2e35d6795@hp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1583 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: 304 Lines: 14 Hello! > Is that in general, or in Linux? Any which follows some of congestion window validation recommendations. Even canonical bsd restarts slow start after rtt. > N is something other than one though. Well, 1 is quite enough to be sure that something is very wrong. You see a proof here. Alexey From dan@coverfire.com Sat Feb 12 14:07:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 14:07:57 -0800 (PST) Received: from otis.cyg.net (otis.cyg.net [69.41.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CM7nNH008994 for ; Sat, 12 Feb 2005 14:07:49 -0800 Received: from ganymede.coverfire.com (ganymede.coverfire.com [69.41.199.10]) (authenticated bits=0) by otis.cyg.net (8.12.11/8.12.11) with ESMTP id j1CM7CNn007662; Sat, 12 Feb 2005 17:07:12 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: Dan Siemon To: hadi@cyberus.ca Cc: netdev@oss.sgi.com In-Reply-To: <1108215923.1126.132.camel@jzny.localdomain> References: <20050117165626.GE26856@postel.suug.ch> <1106002197.1046.19.camel@jzny.localdomain> <20050118134406.GR26856@postel.suug.ch> <1106058592.1035.95.camel@jzny.localdomain> <20050118145830.GS26856@postel.suug.ch> <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> Content-Type: text/plain Date: Sat, 12 Feb 2005 17:07:13 -0500 Message-Id: <1108246033.7554.18.camel@ganymede> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dan@coverfire.com Precedence: bulk X-list: netdev Content-Length: 1363 Lines: 29 On Sat, 2005-12-02 at 08:45 -0500, jamal wrote: > On first impression, this looks very nice - I think you got the object > hierachy figured etc; i will look closely later. > What would be really interesting is to see (gulp) a SOAP/xml interface > on top of this. Is this something you can do with those "bindings"? Yes, a SOAP/XML-RPC interface should be quite possible. This is one of the main reasons I went to the trouble of creating the Mono bindings. I need to create some sort of XML interface to LQL in the next few weeks. > It seems to me from a library perspective, youa nd Thomas may have to > sync. And restricting to just QoS maybe be a limitation (netlink is the > friend you are looking for; so from networking perspective, give them > GUI clikers ways to set routes, static IPSEC SAs etc). Oh and it would > be interesting to have events (see that link come up down etc) I named the project Linux QoS Library before I realized that interface parameters etc could be manipulated via Netlink. I have no intention of limiting LQL to just QoS features. Eventually I'll probably stop referring to it as Linux QoS Library and just use LQL. As for combining my work with Thomas, I'm certainly willing to discuss it. -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 From ak@muc.de Sat Feb 12 14:29:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 14:29:40 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CMTToW009728 for ; Sat, 12 Feb 2005 14:29:30 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 5D480D033E; Sat, 12 Feb 2005 23:29:28 +0100 (CET) To: linux@horizon.com Cc: arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu Subject: Re: [PATCH] OpenBSD Networking-related randomization port References: <20050131201141.GA4879@elte.hu> <20050131232735.11236.qmail@science.horizon.com> From: Andi Kleen Date: Sat, 12 Feb 2005 23:29:28 +0100 In-Reply-To: <20050131232735.11236.qmail@science.horizon.com> (linux@horizon.com's message of "31 Jan 2005 23:27:35 -0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1585 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: 327 Lines: 10 linux@horizon.com writes: > > (The homebrew 15-bit block cipher in this code does show how much the > world needs a small block cipher for some of these applications.) Doesn't TEA fill this niche? It's certainly used for this in the Linux kernel, e.g. in reiserfs (although I have my doubts it is really useful there) -Andi From tgraf@suug.ch Sat Feb 12 14:31:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 14:31:50 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CMVjMm010222 for ; Sat, 12 Feb 2005 14:31:46 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7E758F; Sat, 12 Feb 2005 23:31:22 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 177621C0EA; Sat, 12 Feb 2005 23:32:05 +0100 (CET) Date: Sat, 12 Feb 2005 23:32:04 +0100 From: Thomas Graf To: Dan Siemon Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050212223204.GG31837@postel.suug.ch> References: <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108246033.7554.18.camel@ganymede> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2316 Lines: 46 * Dan Siemon <1108246033.7554.18.camel@ganymede> 2005-02-12 17:07 > On Sat, 2005-12-02 at 08:45 -0500, jamal wrote: > > On first impression, this looks very nice - I think you got the object > > hierachy figured etc; i will look closely later. > > What would be really interesting is to see (gulp) a SOAP/xml interface > > on top of this. Is this something you can do with those "bindings"? > > Yes, a SOAP/XML-RPC interface should be quite possible. This is one of > the main reasons I went to the trouble of creating the Mono bindings. I > need to create some sort of XML interface to LQL in the next few weeks. Before you go ahead, please consider its possible usages. If possible it should conform to an existing format allowing for distributed configuration of network nodes. If no such thing exist and you design your own format please consider the following requirements, because it would be sad if you waste effort that needs to be redone later on. - all components of the networking configuration must be configurable. This includes links, neighbours, routes, routing rules, traffic control but also configuration parameters currently only accessible via ethtool. - The whole interface must take care of the byte order issues. This is the most tricky part. - It must be possible to extend it without breaking backward compatibility. > As for combining my work with Thomas, I'm certainly willing to discuss > it. So let's discuss it, from what I can see your library only consists of basic netlink connection abilities and message parsers/builders on a per netlink user basis. You do not provide any ways to customize it, if the user of your library wants to send its own messages he's pretty much on its own because the whole process of constructing the message, sending it and waiting for the ack is hidden behind one single function. The per object API is quite similiar, you also let the user set the attributes to a object and then commit that object to the kernel. Honestly speaking, your API doesn't fit my needs and the changes to make it suiteable would be rather big so I'm not sure whether a merge of my code into yours would make much sense and the only that could be merged from your side to mine would be the additional support for two or three qdiscs such as htb. From linux@horizon.com Sat Feb 12 15:25:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 15:25:39 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CNPUV8011572 for ; Sat, 12 Feb 2005 15:25:32 -0800 Received: (qmail 10839 invoked by uid 1000); 12 Feb 2005 23:25:18 -0000 Date: 12 Feb 2005 23:25:18 -0000 Message-ID: <20050212232518.10838.qmail@science.horizon.com> From: linux@horizon.com To: ak@muc.de, linux@horizon.com Subject: Re: [PATCH] OpenBSD Networking-related randomization port Cc: arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu In-Reply-To: X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: netdev Content-Length: 3725 Lines: 87 > linux@horizon.com writes: >> (The homebrew 15-bit block cipher in this code does show how much the >> world needs a small block cipher for some of these applications.) > > Doesn't TEA fill this niche? It's certainly used for this in the Linux > kernel, e.g. in reiserfs (although I have my doubts it is really useful > there) Sorry; ambiguous parsing. I meant "(small block) cipher", not "small (block cipher)". TEA is intended for the latter niche. What I meant was a cipher that could encrypt blocks smaller than 64 bits. It's easy to make a smaller hash by just thowing bits away, but a block cipher is a permutation, and has to be invertible. For example, if I take a k-bit counter and encrypt it with a k-bit block cipher, the output is guaranteed not to repeat in less than 2^k steps, but the value after a given value is hard to predict. There is a well-known technique for reducing the block size of a cipher by a small factor, such as from a power of 2 to a prime number slightly lower. That is: unsigned encrypt_mod_n(unsigned x, unsigned n) { assert(x < n); do { x = encrypt(x); } while (x >= n); return x; } It takes a bit of thinking to realize why this creates an bijection from [0..n-1] -> [0..n-1], but it's kind of a neat "aha!" when it does. Remember, encrypt() is a bijection from [0..N-1] -> [0..N-1] for some N >= n. Typically N = 2^k for some k. However, this technique requires N/n calls to encrypt(). I.e. n calls to encrypt_mod_n() will cause N calls to encrypt(). It's generally considered practical up to N/n = 2, so we can encrypt modulo any modulus n if we have encrypt() functions for any N = 2^k a power of 2. I.e. a k-bit block cipher. For example, suppose we want to encrypt 7-digit North American telephone numbers. These are of the form NXX-XXXX, where N is a digit other than 0 or 1, and X is any digit. there are 8e6 possibilities. Using this scheme and a 23-bit block cipher, we can encrypt them to different valid 7-digit telephone numbers. Likewise, 10-digit number with area codes, +1 NXX NXX-XXXX (but not starting with N11) are also possible. There are 792 area codes and 8e6 numbers for a total of 7776000000 < 2^33 combinations. This sort of thing is very useful for adding encryption to protocols and file formats not designed for it. However, the standard literature is notably lacking in block ciphers in funny block sizes. There was one AES submission (The Hasty Pudding Cipher, http://www.cs.arizona.edu/~rcs/hpc/) that supported variable block sizes, but it was eliminated fairly early. To start with, consider very small blocks: 1, 2 or 3 bits. There are only two possible things encrypt() can do with a 1-bit value: either invert it or leave it alone. There are 4! = 24 possible 2-bit encryption operations. Ideally, the key should specify them all with equal probability, but 24 does not evenly divide the (power of 2 sized) keyspace. It is interesting to look at how iniformly the possibilities are covered. It's fun to consider a Feistel network, dividing the plaintext into 1-bit L and R values, and alternating L ^= f(R), R ^= f(L) for (not nexessarily invertible) round functions f. Since there are only 4 possible 1-bit functions (1, 0, x and !x), you can consider each round to have an independent 2-bit round subkey and see how the cipher's uniformity develops as you increase the number of rounds and the key length to go with it. There are 8! = 40320 3-bit encryption operations. Again, all should be covered uniformly. An odd number of bits makes a Feistel design more challenging. But if you don't allow odd numbers of bits, you have to push the shrinking technique it to N/n = 4, which starts to get unpleasant. From roland@topspin.com Sat Feb 12 16:18:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 16:19:00 -0800 (PST) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1D0IuuC012752 for ; Sat, 12 Feb 2005 16:18:56 -0800 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sat, 12 Feb 2005 16:18:14 -0800 Received: from localhost.localdomain ([10.10.253.72]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 12 Feb 2005 16:18:14 -0800 Received: by localhost.localdomain (Postfix, from userid 1113) id 2C5E44FE01; Sat, 12 Feb 2005 16:18:14 -0800 (PST) To: linux@horizon.com Cc: ak@muc.de, arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu Subject: Re: [PATCH] OpenBSD Networking-related randomization port X-Message-Flag: Warning: May contain useful information References: <20050212232518.10838.qmail@science.horizon.com> From: Roland Dreier Date: Sat, 12 Feb 2005 16:18:14 -0800 In-Reply-To: <20050212232518.10838.qmail@science.horizon.com> (linux@horizon.com's message of "12 Feb 2005 23:25:18 -0000") Message-ID: <527jld2tyx.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 13 Feb 2005 00:18:14.0294 (UTC) FILETIME=[8225C360:01C51161] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 929 Lines: 20 linux> It's easy to make a smaller hash by just thowing bits away, linux> but a block cipher is a permutation, and has to be linux> invertible. linux> For example, if I take a k-bit counter and encrypt it with linux> a k-bit block cipher, the output is guaranteed not to linux> repeat in less than 2^k steps, but the value after a given linux> value is hard to predict. Huh? What if my cipher consists of XOR-ing with a k-bit pattern? That's a permutation on the set of k-bit blocks but it happens to decompose as a product of (non-overlapping) swaps. In general for more realistic block ciphers like DES it seems extremely unlikely that the cipher has only a single orbit when viewed as a permutation. I would expect a real block cipher to behave more like a random permutation, which means that the expected number of orbits for a k-bit cipher should be about ln(2^k) or roughly .7 * k. - R. From rick.jones2@hp.com Sat Feb 12 17:29:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 17:29:34 -0800 (PST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1D1TUud017909 for ; Sat, 12 Feb 2005 17:29:31 -0800 Received: from [192.168.1.100] (adsl-67-116-53-82.dsl.sntc01.pacbell.net [67.116.53.82]) by mailhub.hp.com (Postfix) with ESMTP id D7F8827119; Sat, 12 Feb 2005 20:29:24 -0500 (EST) In-Reply-To: <20050212220010.GA29417@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> <20050212205617.GA29146@yakov.inr.ac.ru> <0db5e06aa50422877f9ec4a2e35d6795@hp.com> <20050212220010.GA29417@yakov.inr.ac.ru> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67e9e71a41cc2a840cc89f836e2b6f4b@hp.com> Content-Transfer-Encoding: 7bit Cc: romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org From: rick jones Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Sat, 12 Feb 2005 17:29:16 -0800 To: netdev@oss.sgi.com X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1253 Lines: 33 On Feb 12, 2005, at 2:00 PM, Alexey Kuznetsov wrote: > Any which follows some of congestion window validation recommendations. If you could point me at the chapter and verse that would be great. > Even canonical bsd restarts slow start after rtt. Did we have >= one RTT of idle in the packet trace? >> N is something other than one though. > > Well, 1 is quite enough to be sure that something is very wrong. > You see a proof here. The debate of course is what :) In and of _itself_, a delayed ACK does not guarantee something is very wrong. For example, in a request/response situation when the response takes longer than the delayed ACK interval to generate. And if it was not request/response, and the sender simply didn't have any more to send at that point. Going back to the quantity of cwnd which may be left unused when TSO is enabled. If when TSO is enabled, the sender does not take full advantage of the cwnd doesn't that then mean that to deal with the same bandwidth delay product, one needs a larger TCP window when TSO is enabled than when it is not? In the default case of tcp_tso_win_divisor being 8 that would be another 12.5% right? rick jones there is no rest for the wicked, yet the virtuous have no pillows From linux@horizon.com Sat Feb 12 17:41:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 17:41:15 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1D1fA5D018496 for ; Sat, 12 Feb 2005 17:41:11 -0800 Received: (qmail 19283 invoked by uid 1000); 13 Feb 2005 01:41:04 -0000 Date: 13 Feb 2005 01:41:04 -0000 Message-ID: <20050213014104.19282.qmail@science.horizon.com> From: linux@horizon.com To: linux@horizon.com, roland@topspin.com Subject: Re: [PATCH] OpenBSD Networking-related randomization port Cc: ak@muc.de, arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu In-Reply-To: <527jld2tyx.fsf@topspin.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: netdev Content-Length: 3012 Lines: 94 linux> It's easy to make a smaller hash by just thowing bits away, linux> but a block cipher is a permutation, and has to be linux> invertible. linux> For example, if I take a k-bit counter and encrypt it with linux> a k-bit block cipher, the output is guaranteed not to linux> repeat in less than 2^k steps, but the value after a given linux> value is hard to predict. > Huh? What if my cipher consists of XOR-ing with a k-bit pattern? > That's a permutation on the set of k-bit blocks but it happens to > decompose as a product of (non-overlapping) swaps. > > In general for more realistic block ciphers like DES it seems > extremely unlikely that the cipher has only a single orbit when viewed > as a permutation. I would expect a real block cipher to behave more > like a random permutation, which means that the expected number of > orbits for a k-bit cipher should be about ln(2^k) or roughly .7 * k. I think you misunderstand; your comments don't seem to make sense unless I assume you're imagining output feedback mode: x[0] = encrypt(IV) x[1] = encrypt(x[0]) x[2] = encrypt(x[1]) etc. Obviously, this pattern will repeat after some unpredictable interval. (However, owing to the invertibility of encryption, looping can be easily detected by noticing that x[i] = IV.) But I was talking about counter mode: x[0] = encrypt(0) x[1] = encrypt(1) x[2] = encrypt(2) etc. It should be obvious that this will not repeat until the counter overflows k bits and you try to compute encrypt(2^k) = encrypt(0). One easy way to generate unpredictable 16-bit port numbers that don't repeat too fast is: highbit = 0; for (;;) { generate_random_encryption_key(key); for (i = 0; i < 20000; i++) use(highbit | encrypt15(i, key)); highbit ^= 0x8000; } Note that this does NOT use all 32K values before switching to another key; if that were the case, an attacker who kept a big bitmap of reviously seen values could preduct the last few values based on knowing what hadn't been seen already. Of course, you can always wrap a layer of Knuth's Algorithm B (randomization by shuffling) around anything: #include "basic_rng.h" #define SHUFFLE_SIZE 32 /* Power of 2 is more efficient */ struct better_rng_state { struct basic_rng_state basic; unsigned y; unsigned z[SHUFFLE_SIZE]; }; void better_rng_seed(struct better_rng_state *state, unsigned seed) { unsigned i; basic_rng_seed(&state->basic, seed); for (i = 0; i < SHUFFLE_SIZE; i++) state->z[i] = basic_rng(&state->basic); state->y = basic_rng(&state->basic) % SHUFFLE_SIZE; } unsigned better_rng(struct better_rng_state *state) { unsigned x = state->z[state->y]; state->y = (state->z = basic_rng(&state->basic)) % SHUFFLE_SIZE; return x; } (You can reduce code size by reducing modulo SHUFFLE_SIZE when you use state->y rather than when storing into it, but I have done it the other way to make clear exactly how much "effective" state is stored. You can also just initialize state->y to a fixed value.) From hubert.tonneau@fullpliant.org Sun Feb 13 03:20:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 03:20:53 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1DBKiP5005419 for ; Sun, 13 Feb 2005 03:20:44 -0800 From: Hubert Tonneau To: Alexey Kuznetsov , "David S. Miller" Cc: Alexey Kuznetsov , rick.jones2@hp.com, shemminger@osdl.org, romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Sun, 13 Feb 2005 10:52:35 GMT Message-ID: <0528GVO12@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 1396 Lines: 45 Alexey Kuznetsov wrote: > > Exactly. That's why the next test should be with disabled TSO in 2.6.9. > If too rare PSHs were a problem, it will show as the same disaster there. After, ethtool -K eth1 tso off the result is unchanged on 2.6.9 (14 seconds for 105 MB). After, ethtool -K eth1 tso off the result is also unchanged on 2.6.10-ac11 with no extra TCP patch (325 seconds). Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) Link detected: yes PS: Please sorry for the long delay I have to run tests, and the reason is that it's a production server, so I cannot make tests in the middle of the day, it's remote, so in order to switch the kernel, I have to upload the new one, and then upload again the old one to switch back, and the best connection I have these days is 30 Kbps modem connection. It will improve on monday since I'll have a 128 Kbps ADSL connection. From bdschuym@pandora.be Sun Feb 13 09:09:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 09:09:48 -0800 (PST) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DH9fq0024236 for ; Sun, 13 Feb 2005 09:09:42 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id DA59532818E; Sun, 13 Feb 2005 18:09:39 +0100 (MET) Received: from 192.168.0.138 (dD5763CA9.access.telenet.be [213.118.60.169]) by astra.telenet-ops.be (Postfix) with ESMTP id E0A76328096; Sun, 13 Feb 2005 18:09:38 +0100 (MET) Subject: [PATCH/RFC] Reduce call chain length in netfilter (take 2) From: Bart De Schuymer To: "David S. Miller" Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, Rusty Russell , Patrick McHardy , snort2004@mail.ru, ak@suse.de, bridge@osdl.org, gandalf@wlug.westbo.se, dwmw2@infradead.org, shemminger@osdl.org Content-Type: text/plain Date: Sun, 13 Feb 2005 18:16:21 +0100 Message-Id: <1108314982.4662.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bdschuym@pandora.be Precedence: bulk X-list: netdev Content-Length: 7162 Lines: 216 Hi, This is a second try to fix the long chain call lengths in netfilter. The difference with the previous patch is that I got rid of the extra argument. I somehow didn't see it could be done without using the 'int *ret2' argument. A comment on the number of arguments to nf_hook_slow: I don't think the number of arguments should be decreased. For the bridge-nf code, f.e., the indev argument does not equal (*pskb)->dev (this is an answer to a question of Rusty in the old thread). A comment on the argument change of nf_hook_slow (sk_buff * to sk_buff **) and the bad influence on tail call optimization possibilities. From the discussion in the old thread it became clear that no tail call is generated for the current code. So, I don't see why this is a reason not to accept the patch. Furthermore, if gcc ever would become able of doing the current code with a tail call, it should be very easy to change the code back to the original. In the meantime, I think this patch is the best known solution. cheers, Bart --- linux-2.6.11-rc3/include/linux/netfilter.h.old 2005-02-12 13:48:13.000000000 +0100 +++ linux-2.6.11-rc3/include/linux/netfilter.h 2005-02-12 17:02:48.000000000 +0100 @@ -18,7 +18,8 @@ #define NF_STOLEN 2 #define NF_QUEUE 3 #define NF_REPEAT 4 -#define NF_MAX_VERDICT NF_REPEAT +#define NF_STOP 5 +#define NF_MAX_VERDICT NF_STOP /* Generic cache responses from hook functions. <= 0x2000 is used for protocol-flags. */ @@ -138,21 +139,32 @@ void nf_log_packet(int pf, /* This is gross, but inline doesn't cut it for avoiding the function call in fast path: gcc doesn't inline (needs value tracking?). --RR */ #ifdef CONFIG_NETFILTER_DEBUG -#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \ - nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn), INT_MIN) -#define NF_HOOK_THRESH nf_hook_slow +#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \ +({int __ret; \ +if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \ + __ret = (okfn)(skb); \ +__ret;}) +#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \ +({int __ret; \ +if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \ + __ret = (okfn)(skb); \ +__ret;}) #else -#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \ -(list_empty(&nf_hooks[(pf)][(hook)]) \ - ? (okfn)(skb) \ - : nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn), INT_MIN)) -#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \ -(list_empty(&nf_hooks[(pf)][(hook)]) \ - ? (okfn)(skb) \ - : nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn), (thresh))) +#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \ +({int __ret; \ +if (list_empty(&nf_hooks[pf][hook]) || \ + (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \ + __ret = (okfn)(skb); \ +__ret;}) +#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \ +({int __ret; \ +if (list_empty(&nf_hooks[pf][hook]) || \ + (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \ + __ret = (okfn)(skb); \ +__ret;}) #endif -int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb, +int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb, struct net_device *indev, struct net_device *outdev, int (*okfn)(struct sk_buff *), int thresh); --- linux-2.6.11-rc3/net/core/netfilter.c.old 2005-02-12 13:48:06.000000000 +0100 +++ linux-2.6.11-rc3/net/core/netfilter.c 2005-02-12 16:16:03.000000000 +0100 @@ -349,6 +349,8 @@ static unsigned int nf_iterate(struct li int (*okfn)(struct sk_buff *), int hook_thresh) { + unsigned int verdict; + /* * The caller must not block between calls to this * function because of risk of continuing from deleted element. @@ -361,28 +363,18 @@ static unsigned int nf_iterate(struct li /* Optimization: we don't need to hold module reference here, since function can't sleep. --RR */ - switch (elem->hook(hook, skb, indev, outdev, okfn)) { - case NF_QUEUE: - return NF_QUEUE; - - case NF_STOLEN: - return NF_STOLEN; - - case NF_DROP: - return NF_DROP; - - case NF_REPEAT: - *i = (*i)->prev; - break; - + verdict = elem->hook(hook, skb, indev, outdev, okfn); + if (verdict != NF_ACCEPT) { #ifdef CONFIG_NETFILTER_DEBUG - case NF_ACCEPT: - break; - - default: - NFDEBUG("Evil return from %p(%u).\n", - elem->hook, hook); + if (unlikely(verdict > NF_MAX_VERDICT)) { + NFDEBUG("Evil return from %p(%u).\n", + elem->hook, hook); + continue; + } #endif + if (verdict != NF_REPEAT) + return verdict; + *i = (*i)->prev; } } return NF_ACCEPT; @@ -494,7 +486,9 @@ static int nf_queue(struct sk_buff *skb, return 1; } -int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb, +/* Returns 1 if okfn() needs to be executed by the caller, + * -EPERM for NF_DROP, 0 otherwise. */ +int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb, struct net_device *indev, struct net_device *outdev, int (*okfn)(struct sk_buff *), @@ -508,34 +502,29 @@ int nf_hook_slow(int pf, unsigned int ho rcu_read_lock(); #ifdef CONFIG_NETFILTER_DEBUG - if (skb->nf_debug & (1 << hook)) { + if (unlikely((*pskb)->nf_debug & (1 << hook))) { printk("nf_hook: hook %i already set.\n", hook); - nf_dump_skb(pf, skb); + nf_dump_skb(pf, *pskb); } - skb->nf_debug |= (1 << hook); + (*pskb)->nf_debug |= (1 << hook); #endif elem = &nf_hooks[pf][hook]; - next_hook: - verdict = nf_iterate(&nf_hooks[pf][hook], &skb, hook, indev, +next_hook: + verdict = nf_iterate(&nf_hooks[pf][hook], pskb, hook, indev, outdev, &elem, okfn, hook_thresh); - if (verdict == NF_QUEUE) { + if (verdict == NF_ACCEPT || verdict == NF_STOP) { + ret = 1; + goto unlock; + } else if (verdict == NF_DROP) { + kfree_skb(*pskb); + ret = -EPERM; + } else if (verdict == NF_QUEUE) { NFDEBUG("nf_hook: Verdict = QUEUE.\n"); - if (!nf_queue(skb, elem, pf, hook, indev, outdev, okfn)) + if (!nf_queue(*pskb, elem, pf, hook, indev, outdev, okfn)) goto next_hook; } - - switch (verdict) { - case NF_ACCEPT: - ret = okfn(skb); - break; - - case NF_DROP: - kfree_skb(skb); - ret = -EPERM; - break; - } - +unlock: rcu_read_unlock(); return ret; } --- linux-2.6.11-rc3/net/bridge/br_netfilter.c.old 2005-02-12 13:48:22.000000000 +0100 +++ linux-2.6.11-rc3/net/bridge/br_netfilter.c 2005-02-12 17:04:45.000000000 +0100 @@ -829,8 +829,7 @@ static unsigned int ip_sabotage_in(unsig { if ((*pskb)->nf_bridge && !((*pskb)->nf_bridge->mask & BRNF_NF_BRIDGE_PREROUTING)) { - okfn(*pskb); - return NF_STOLEN; + return NF_STOP; } return NF_ACCEPT; @@ -891,8 +890,7 @@ static unsigned int ip_sabotage_out(unsi if (out->priv_flags & IFF_802_1Q_VLAN) nf_bridge->netoutdev = (struct net_device *)out; #endif - okfn(skb); - return NF_STOLEN; + return NF_STOP; } return NF_ACCEPT; From jgarzik@pobox.com Sun Feb 13 09:49:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 09:50:04 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DHnh9l025408 for ; Sun, 13 Feb 2005 09:49:54 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D0NsJ-0003BQ-SQ; Sun, 13 Feb 2005 17:49:40 +0000 Message-ID: <420F9326.6040501@pobox.com> Date: Sun, 13 Feb 2005 12:49:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: akpm@osdl.org, jdmason@us.ibm.com, netdev@oss.sgi.com Subject: Re: [patch 2.6.11-rc3 1/5] r8169: endianness fixes References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> In-Reply-To: <20050211233918.GB8792@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1593 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: 13 Lines: 2 applied 1-5 From jgarzik@pobox.com Sun Feb 13 12:19:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 12:19:25 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DKJE6L031998 for ; Sun, 13 Feb 2005 12:19:14 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D0QD3-0003jW-0v; Sun, 13 Feb 2005 20:19:13 +0000 Message-ID: <420FB632.1080706@pobox.com> Date: Sun, 13 Feb 2005 15:18:58 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev Subject: [BK PATCHES] 2.6.x net driver fixes Content-Type: multipart/mixed; boundary="------------060304050309040009090806" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1594 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: 12327 Lines: 425 This is a multi-part message in MIME format. --------------060304050309040009090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------060304050309040009090806 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/ibm_emac/ibm_emac_core.c | 8 +- drivers/net/ibm_emac/ibm_emac_core.h | 2 drivers/net/tulip/de2104x.c | 4 - drivers/net/wan/dscc4.c | 117 ++++++++++++++++++----------------- 4 files changed, 67 insertions(+), 64 deletions(-) through these ChangeSets: (05/02/13 1.2033) [PATCH] emac: fix mdio delay Fixes MDIO delay. Please apply. Signed-off-by: Ralph Siemsen Signed-off-by: Matt Porter Signed-off-by: Jeff Garzik (05/02/13 1.2032) [PATCH] emac: fix jumbo frame support Fixes a bug in RX buffer allocation so that jumbo size skbs are allocated when the MTU size is changed. Also removes the deprecated restore_flags() call. Please apply. Signed-off-by: Matt Porter Signed-off-by: Jeff Garzik (05/02/11 1.2031) [PATCH] de214x.c uses uninitialized pci_dev->irq Don't use pci_dev->irq until after pci_enable_device(). Andy Esten reported that his NIC stopped working in 2.6.10 because of this problem. Signed-off-by: Bjorn Helgaas Signed-off-by: Jeff Garzik (05/01/27 1.1966.102.5) [PATCH] dscc4: removal of unneeded variable Removal of unneeded variable and more spaces for my eyes. Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik (05/01/27 1.1966.102.4) [PATCH] dscc4: removal of unneeded casts Removal of unneeded casts. Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik (05/01/27 1.1966.102.3) [PATCH] dscc4: error status checking and pci janitoring Error status checking and PCI janitoring - propagation of the error code; - pci_request_region use in dscc4_init_one; - missing pci_disable_device() added to the error path; Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik (05/01/27 1.1966.102.2) [PATCH] dscc4: code factorisation Small code factorization. Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik (05/01/27 1.1966.102.1) [PATCH] dscc4: use of uncompletely initialized struct dscc4_set_quartz() is issued with an argument in an unitialized state and the kernel does not like it. Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik --------------060304050309040009090806 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c --- a/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-13 15:18:01 -05:00 +++ b/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-13 15:18:01 -05:00 @@ -475,8 +475,9 @@ out_be32(&emacp->em0stacr, stacr); - while (((stacr = in_be32(&emacp->em0stacr) & EMAC_STACR_OC) == 0) - && (count++ < 5000)) + count = 0; + while ((((stacr = in_be32(&emacp->em0stacr)) & EMAC_STACR_OC) == 0) + && (count++ < MDIO_DELAY)) udelay(1); MDIO_DEBUG((" (count was %d)\n", count)); @@ -912,7 +913,6 @@ PKT_DEBUG(("emac_start_xmit() stopping queue\n")); netif_stop_queue(dev); spin_unlock_irqrestore(&fep->lock, flags); - restore_flags(flags); return -EBUSY; } @@ -1281,7 +1281,7 @@ /* Format the receive descriptor ring. */ ep->rx_slot = 0; /* Default is MTU=1500 + Ethernet overhead */ - ep->rx_buffer_size = ENET_DEF_BUF_SIZE; + ep->rx_buffer_size = dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE; emac_rx_fill(dev, 0); if (ep->rx_slot != 0) { printk(KERN_ERR diff -Nru a/drivers/net/ibm_emac/ibm_emac_core.h b/drivers/net/ibm_emac/ibm_emac_core.h --- a/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-13 15:18:01 -05:00 +++ b/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-13 15:18:01 -05:00 @@ -77,8 +77,6 @@ #define ENET_HEADER_SIZE 14 #define ENET_FCS_SIZE 4 -#define ENET_DEF_MTU_SIZE 1500 -#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE) #define EMAC_MIN_FRAME 64 #define EMAC_MAX_FRAME 9018 #define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE) diff -Nru a/drivers/net/tulip/de2104x.c b/drivers/net/tulip/de2104x.c --- a/drivers/net/tulip/de2104x.c 2005-02-13 15:18:01 -05:00 +++ b/drivers/net/tulip/de2104x.c 2005-02-13 15:18:01 -05:00 @@ -1960,8 +1960,6 @@ dev->tx_timeout = de_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; - dev->irq = pdev->irq; - de = dev->priv; de->de21040 = ent->driver_data == 0 ? 1 : 0; de->pdev = pdev; @@ -1996,6 +1994,8 @@ pdev->irq, pci_name(pdev)); goto err_out_res; } + + dev->irq = pdev->irq; /* obtain and check validity of PCI I/O address */ pciaddr = pci_resource_start(pdev, 1); diff -Nru a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c --- a/drivers/net/wan/dscc4.c 2005-02-13 15:18:01 -05:00 +++ b/drivers/net/wan/dscc4.c 2005-02-13 15:18:01 -05:00 @@ -691,7 +691,7 @@ root = ppriv->root; for (i = 0; i < dev_per_card; i++) - unregister_hdlc_device(dscc4_to_dev(&root[i])); + unregister_hdlc_device(dscc4_to_dev(root + i)); pci_set_drvdata(pdev, NULL); @@ -706,33 +706,36 @@ { struct dscc4_pci_priv *priv; struct dscc4_dev_priv *dpriv; - static int cards_found = 0; void __iomem *ioaddr; - int i; + int i, rc; printk(KERN_DEBUG "%s", version); - if (pci_enable_device(pdev)) - goto err_out; - if (!request_mem_region(pci_resource_start(pdev, 0), - pci_resource_len(pdev, 0), "registers")) { + rc = pci_enable_device(pdev); + if (rc < 0) + goto out; + + rc = pci_request_region(pdev, 0, "registers"); + if (rc < 0) { printk(KERN_ERR "%s: can't reserve MMIO region (regs)\n", DRV_NAME); - goto err_out; + goto err_disable_0; } - if (!request_mem_region(pci_resource_start(pdev, 1), - pci_resource_len(pdev, 1), "LBI interface")) { + rc = pci_request_region(pdev, 1, "LBI interface"); + if (rc < 0) { printk(KERN_ERR "%s: can't reserve MMIO region (lbi)\n", DRV_NAME); - goto err_out_free_mmio_region0; + goto err_free_mmio_region_1; } + ioaddr = ioremap(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0)); if (!ioaddr) { printk(KERN_ERR "%s: cannot remap MMIO region %lx @ %lx\n", DRV_NAME, pci_resource_len(pdev, 0), pci_resource_start(pdev, 0)); - goto err_out_free_mmio_region; + rc = -EIO; + goto err_free_mmio_regions_2; } printk(KERN_DEBUG "Siemens DSCC4, MMIO at %#lx (regs), %#lx (lbi), IRQ %d\n", pci_resource_start(pdev, 0), @@ -742,14 +745,16 @@ pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0xf8); pci_set_master(pdev); - if (dscc4_found1(pdev, ioaddr)) - goto err_out_iounmap; + rc = dscc4_found1(pdev, ioaddr); + if (rc < 0) + goto err_iounmap_3; - priv = (struct dscc4_pci_priv *)pci_get_drvdata(pdev); + priv = pci_get_drvdata(pdev); - if (request_irq(pdev->irq, &dscc4_irq, SA_SHIRQ, DRV_NAME, priv->root)){ + rc = request_irq(pdev->irq, dscc4_irq, SA_SHIRQ, DRV_NAME, priv->root); + if (rc < 0) { printk(KERN_WARNING "%s: IRQ %d busy\n", DRV_NAME, pdev->irq); - goto err_out_free1; + goto err_release_4; } /* power up/little endian/dma core controlled via lrda/ltda */ @@ -769,9 +774,11 @@ priv->iqcfg = (u32 *) pci_alloc_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), &priv->iqcfg_dma); if (!priv->iqcfg) - goto err_out_free_irq; + goto err_free_irq_5; writel(priv->iqcfg_dma, ioaddr + IQCFG); + rc = -ENOMEM; + /* * SCC 0-3 private rx/tx irq structures * IQRX/TXi needs to be set soon. Learned it the hard way... @@ -781,7 +788,7 @@ dpriv->iqtx = (u32 *) pci_alloc_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), &dpriv->iqtx_dma); if (!dpriv->iqtx) - goto err_out_free_iqtx; + goto err_free_iqtx_6; writel(dpriv->iqtx_dma, ioaddr + IQTX0 + i*4); } for (i = 0; i < dev_per_card; i++) { @@ -789,7 +796,7 @@ dpriv->iqrx = (u32 *) pci_alloc_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), &dpriv->iqrx_dma); if (!dpriv->iqrx) - goto err_out_free_iqrx; + goto err_free_iqrx_7; writel(dpriv->iqrx_dma, ioaddr + IQRX0 + i*4); } @@ -804,17 +811,18 @@ writel(0xff200001, ioaddr + GCMDR); - cards_found++; - return 0; + rc = 0; +out: + return rc; -err_out_free_iqrx: +err_free_iqrx_7: while (--i >= 0) { dpriv = priv->root + i; pci_free_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), dpriv->iqrx, dpriv->iqrx_dma); } i = dev_per_card; -err_out_free_iqtx: +err_free_iqtx_6: while (--i >= 0) { dpriv = priv->root + i; pci_free_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), @@ -822,20 +830,19 @@ } pci_free_consistent(pdev, IRQ_RING_SIZE*sizeof(u32), priv->iqcfg, priv->iqcfg_dma); -err_out_free_irq: +err_free_irq_5: free_irq(pdev->irq, priv->root); -err_out_free1: +err_release_4: dscc4_free1(pdev); -err_out_iounmap: +err_iounmap_3: iounmap (ioaddr); -err_out_free_mmio_region: - release_mem_region(pci_resource_start(pdev, 1), - pci_resource_len(pdev, 1)); -err_out_free_mmio_region0: - release_mem_region(pci_resource_start(pdev, 0), - pci_resource_len(pdev, 0)); -err_out: - return -ENODEV; +err_free_mmio_regions_2: + pci_release_region(pdev, 1); +err_free_mmio_region_1: + pci_release_region(pdev, 0); +err_disable_0: + pci_disable_device(pdev); + goto out; }; /* @@ -882,8 +889,7 @@ struct dscc4_dev_priv *root; int i, ret = -ENOMEM; - root = (struct dscc4_dev_priv *) - kmalloc(dev_per_card*sizeof(*root), GFP_KERNEL); + root = kmalloc(dev_per_card*sizeof(*root), GFP_KERNEL); if (!root) { printk(KERN_ERR "%s: can't allocate data\n", DRV_NAME); goto err_out; @@ -892,22 +898,17 @@ for (i = 0; i < dev_per_card; i++) { root[i].dev = alloc_hdlcdev(root + i); - if (!root[i].dev) { - while (i--) - free_netdev(root[i].dev); + if (!root[i].dev) goto err_free_dev; - } } - ppriv = (struct dscc4_pci_priv *) kmalloc(sizeof(*ppriv), GFP_KERNEL); + ppriv = kmalloc(sizeof(*ppriv), GFP_KERNEL); if (!ppriv) { printk(KERN_ERR "%s: can't allocate private data\n", DRV_NAME); - goto err_free_dev2; + goto err_free_dev; } memset(ppriv, 0, sizeof(struct dscc4_pci_priv)); - ret = dscc4_set_quartz(root, quartz); - if (ret < 0) - goto err_free_priv; + ppriv->root = root; spin_lock_init(&ppriv->lock); @@ -951,20 +952,24 @@ goto err_unregister; } } + + ret = dscc4_set_quartz(root, quartz); + if (ret < 0) + goto err_unregister; + pci_set_drvdata(pdev, ppriv); return ret; err_unregister: - while (--i >= 0) { + while (i-- > 0) { dscc4_release_ring(root + i); - unregister_hdlc_device(dscc4_to_dev(&root[i])); + unregister_hdlc_device(dscc4_to_dev(root + i)); } -err_free_priv: kfree(ppriv); -err_free_dev2: - for (i = 0; i < dev_per_card; i++) - free_netdev(root[i].dev); + i = dev_per_card; err_free_dev: + while (i-- > 0) + free_netdev(root[i].dev); kfree(root); err_out: return ret; @@ -1998,10 +2003,10 @@ iounmap(ioaddr); - release_mem_region(pci_resource_start(pdev, 1), - pci_resource_len(pdev, 1)); - release_mem_region(pci_resource_start(pdev, 0), - pci_resource_len(pdev, 0)); + pci_release_region(pdev, 1); + pci_release_region(pdev, 0); + + pci_disable_device(pdev); } static int dscc4_hdlc_attach(struct net_device *dev, unsigned short encoding, --------------060304050309040009090806-- From jgarzik@pobox.com Sun Feb 13 12:38:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 12:39:07 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DKcwsX000340 for ; Sun, 13 Feb 2005 12:38:58 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D0QW8-00061V-PI; Sun, 13 Feb 2005 20:38:57 +0000 Message-ID: <420FBAD3.3020909@pobox.com> Date: Sun, 13 Feb 2005 15:38:43 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel Subject: netdev-2.6 queue updated Content-Type: multipart/mixed; boundary="------------020904010101080409030203" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1595 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: 17119 Lines: 395 This is a multi-part message in MIME format. --------------020904010101080409030203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See attached for list of changes, BK info, and patch URL. Recent changes: * posted patch against 2.6.11-rc4 (see attached) * incorporated ieee80211 lib code into the wireless-2.6 sub-tree, which is included in this queue. This code will form the basis of the "Linux wireless stack". Wireless hackers... start hacking! * r8169 fixes, sundance fix, bonding update, smc91x update --------------020904010101080409030203 Content-Type: text/plain; name="netdev.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="netdev.txt" BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.11-rc4-netdev1.patch.bz2 This will update the following files: drivers/net/bagetlance.c | 1368 ----- include/linux/dp83840.h | 41 Documentation/networking/bonding.txt | 2101 +++++---- Documentation/networking/e100.txt | 3 Documentation/networking/ixgb.txt | 9 MAINTAINERS | 7 arch/arm/mach-pxa/lubbock.c | 2 arch/arm/mach-sa1100/neponset.c | 2 drivers/net/3c503.c | 67 drivers/net/3c515.c | 32 drivers/net/8139cp.c | 100 drivers/net/8139too.c | 291 - drivers/net/Kconfig | 56 drivers/net/Makefile | 2 drivers/net/Space.c | 11 drivers/net/arcnet/arc-rawmode.c | 4 drivers/net/arcnet/arc-rimi.c | 14 drivers/net/arcnet/arcnet.c | 30 drivers/net/arcnet/com20020.c | 6 drivers/net/arcnet/com90io.c | 4 drivers/net/arcnet/com90xx.c | 8 drivers/net/arcnet/rfc1051.c | 8 drivers/net/arcnet/rfc1201.c | 12 drivers/net/au1000_eth.c | 1361 ++++- drivers/net/au1000_eth.h | 55 drivers/net/b44.h | 14 drivers/net/bonding/bond_alb.c | 8 drivers/net/bonding/bond_main.c | 35 drivers/net/cs89x0.c | 4 drivers/net/eepro100.c | 10 drivers/net/es3210.c | 32 drivers/net/ewrk3.c | 87 drivers/net/fealnx.c | 275 - drivers/net/hamradio/baycom_epp.c | 53 drivers/net/hamradio/baycom_par.c | 8 drivers/net/hamradio/baycom_ser_fdx.c | 7 drivers/net/hamradio/baycom_ser_hdx.c | 7 drivers/net/hamradio/bpqether.c | 17 drivers/net/hamradio/dmascc.c | 2073 ++++---- drivers/net/hamradio/hdlcdrv.c | 48 drivers/net/hamradio/mkiss.c | 12 drivers/net/hamradio/yam.c | 38 drivers/net/ibm_emac/ibm_emac.h | 4 drivers/net/ibmlana.c | 99 drivers/net/ibmlana.h | 1 drivers/net/ioc3-eth.c | 83 drivers/net/irda/act200l-sir.c | 3 drivers/net/irda/irtty-sir.c | 4 drivers/net/irda/ma600-sir.c | 12 drivers/net/irda/sir_dev.c | 4 drivers/net/irda/tekram-sir.c | 3 drivers/net/jazzsonic.c | 217 drivers/net/meth.c | 275 - drivers/net/meth.h | 2 drivers/net/mv643xx_eth.c | 2400 +++++----- drivers/net/mv643xx_eth.h | 603 -- drivers/net/ni65.c | 3 drivers/net/ns83820.c | 3 drivers/net/pcmcia/ibmtr_cs.c | 7 drivers/net/pcmcia/xirc2ps_cs.c | 23 drivers/net/pcnet32.c | 47 drivers/net/ppp_generic.c | 2 drivers/net/r8169.c | 92 drivers/net/s2io.c | 45 drivers/net/sb1250-mac.c | 109 drivers/net/sgiseeq.c | 70 drivers/net/sis900.c | 195 drivers/net/sk_mca.c | 126 drivers/net/sk_mca.h | 19 drivers/net/skge.c | 3334 ++++++++++++++ drivers/net/skge.h | 3005 ++++++++++++ drivers/net/smc-mca.c | 37 drivers/net/smc-ultra.c | 34 drivers/net/smc-ultra32.c | 30 drivers/net/smc91x.c | 203 drivers/net/smc91x.h | 79 drivers/net/sonic.c | 4 drivers/net/sundance.c | 7 drivers/net/tg3.h | 14 drivers/net/tokenring/ibmtr.c | 158 drivers/net/typhoon-firmware.h | 5568 ++++++++++-------------- drivers/net/typhoon.c | 244 - drivers/net/wan/cosa.c | 7 drivers/net/wan/dscc4.c | 117 drivers/net/wd.c | 36 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/airo.c | 25 drivers/net/wireless/airport.c | 5 drivers/net/wireless/arlan.h | 4 drivers/net/wireless/atmel_cs.c | 3 drivers/net/wireless/hermes.c | 43 drivers/net/wireless/hermes.h | 62 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1080 ++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 ++ drivers/net/wireless/hostap/hostap_ap.c | 3259 ++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 556 ++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 ++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 +++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 785 +++ drivers/net/wireless/hostap/hostap_download.c | 761 +++ drivers/net/wireless/hostap/hostap_hw.c | 3607 +++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 469 ++ drivers/net/wireless/hostap/hostap_ioctl.c | 3624 +++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 452 + drivers/net/wireless/hostap/hostap_plx.c | 611 ++ drivers/net/wireless/hostap/hostap_proc.c | 466 ++ drivers/net/wireless/hostap/hostap_wlan.h | 1071 ++++ drivers/net/wireless/orinoco_cs.c | 10 drivers/net/wireless/orinoco_pci.c | 7 drivers/net/wireless/orinoco_plx.c | 82 drivers/net/wireless/orinoco_tmd.c | 51 drivers/net/wireless/prism54/isl_ioctl.c | 2 drivers/net/wireless/ray_cs.c | 5 include/linux/ibmtr.h | 15 include/linux/mii.h | 4 include/linux/mv643xx.h | 434 + include/linux/netdevice.h | 2 include/linux/pci_ids.h | 8 include/net/ieee80211.h | 883 +++ include/net/ieee80211_crypt.h | 86 net/Kconfig | 2 net/Makefile | 1 net/core/dev.c | 28 net/ieee80211/Kconfig | 71 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 253 + net/ieee80211/ieee80211_crypt_ccmp.c | 473 ++ net/ieee80211/ieee80211_crypt_tkip.c | 711 +++ net/ieee80211/ieee80211_crypt_wep.c | 275 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++ net/ieee80211/ieee80211_tx.c | 448 + net/ieee80211/ieee80211_wx.c | 471 ++ 144 files changed, 42414 insertions(+), 9971 deletions(-) through these ChangeSets: : o sundance: attempt to address high irqs due to TX overflow : o Big rename o Rename MV_READ => mv_read and MV_WRITE => mv_write o Additional whitespace cleanups, mostly changing spaces to tabs in comments o Run mv643xx_eth.[ch] through scripts/Lindent o Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. o This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case o Add support for PHYs/boards that don't support autonegotiation o With this patch, the driver now calls netif_carrier_off/netif_carrier_on o This patch cleans up the handling of receive skb sizing : o ieee80211 subsystem : o [netdrvr 8139cp] add PCI ID Adrian Bunk: o remove dp83840.h Alexander Viro: o 3c503 (iomem + isa-ectomy) o ibmlana part 2 (iomem annotations and isa-ectomy) o ibmlana part 1 (netdev_priv()) o sk_mca - iomem and isa-ectomy o sk_mca - netdev_priv() o ibmtr 2/2: ibmtr annotations - the rest o ibmtr 1/2: iomem annotations - trivial part o es3210 iomem annotions and isa-ectomy o ewrk3 iomem annotations + isa-ectomy o wd iomem annotations + isa-ectomy o smc-ultra32 iomem annotations + isa-ectomy o smc-ultra iomem annotations + isa-ectomy o smc-mca iomem annotations and isa-ectomy o fealnx iomem annotations, switch to io{read,write} o wireless iomem annotations and fixes, switch to io{read,write} Dale Farnsworth: o This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. o This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. o This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: o This patch adds device driver model support to the mv643xx_eth driver o This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. o This patch fixes the code that enables hardware checksum generation o This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. o This patch removes code that is redundant or useless Daniele Venzano: o sis900: chiprev i/o cleanups o sis900: debugging output update o sis900 printk audit o sis900: version bump; remove broken URL o sis900: add infrastructure needed for standard netif messages David Dillow: o Bump version and release date o Version 03.001.008 of the Typhoon firmware, courtesy of 3Com o Fixup the version reporting to match 3Com o Use module_param() and add descriptions o Teach typhoon to use port IO on machines that need it. It will attempt to use MMIO, but if that fails (or the user asks), it will fallback to port IO. o Enable bus mastering before saving our state, or we'll only be able to load the modules one time. David T. Hollis: o Move MII-related constants from b44/tg3 drivers to linux/mii.h Domen Puncer: o net/ewrk3: replace schedule_timeout() with msleep_interruptible() o net/tekram-sir: replace schedule_timeout() with msleep() o net/ns83820: replace schedule_timeout() with msleep() o net/ni65: replace schedule_timeout() with msleep() o net/sir_dev: replace schedule_timeout() with msleep() o net/xirc2ps_cs: replace Wait() with msleep() o net/ma600-sir: replace schedule_timeout() with msleep() o net/irtty-sir: replace schedule_timeout() with msleep() o net/act2001-sir: replace schedule_timeout() with msleep() o arcnet: remove casts Don Fry: o pcnet32: 79c976 with fiber optic fix Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o r8169: synchronization and balancing when the device is closed o r8169: screaming irq when the device is closed o r8169: typo in debugging code o r8169: merge of Realtek's code o r8169: endianness fixes o dscc4: removal of unneeded variable o dscc4: removal of unneeded casts o dscc4: error status checking and pci janitoring o dscc4: code factorisation o dscc4: use of uncompletely initialized struct o 8139cp: SG support fixes Ganesh Venkatesan: o ixgb: Documentation/networking/ixgb.txt Ian Campbell: o use datacs in smc91x driver o smc91x: power down PHY on suspend Jay Vosburgh: o bonding: Update/rewrite bonding.txt o bonding: Update kconfig description o bonding: change misleading warning o bonding: use wrappers to change mtu and MAC o net/core: move set MAC into separate function Jeff Garzik: o [wireless hostap] update for new pci_save_state() o [netdrvr 8139cp] TSO support Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver JustMan: o atmel_cs: Add support LG LW2100N WLAN PCMCIA card Matt Porter: o Add PPC440SP support to IBM EMAC driver Nicolas Pitre: o smc91x: allow RX of VLAN packets Nishanth Aravamudan: o net/cosa: replace schedule_timeout() with msleep() o net/airo: replace schedule_timeout() with msleep()/ssleep() o net/cs89x0: replace schedule_timeout() with msleep() Paul Mackerras: o remove bogus exports in ppp Pavel Machek: o eepro100 kill obsolete ifdefs Pekka Enberg: o 8139too: use iomap for pio/mmio Ralf Bächle: o Reformat DMASCC driver o Use netdev_priv in baycom_epp driver o Use netdev_priv in baycom_ser_fdx driver o Use netdev_priv in hdlcdrv driver o Use netdev_priv in baycom_ser_hdx driver o Use netdev_priv in baycom_par driver o Use netdev_priv in bpqether driver o Use netdev_priv in mkiss driver o Use netdev_priv in YAM driver o SGI Seeq updates o SB1250 driver updates o S2IO syntax fixes o Meth driver updates o Marvell MV-64340 driver upda o Jazzsonic driver updates o IOC3 driver updates o Remove Baget network driver o Au1000 driver updates Randy Dunlap: o ray_cs: reduce stack usage (sockaddr) o prism54: use NULL for pointer o (v2) arlan: remove gcc warning with CONFIG_PROC_FS=n Rene Herman: o 8139too Interframe Gap Time Scott Feldman: o e100: remove reference to NAPI config option Steffen Klassert: o Add MODULE_VERSION to the 3c515 driver o Use netdev_priv in the 3c515 driver o 8139cp - add netpoll support Stephen Hemminger: o skge driver (0.5) o 8139too: use netdev_priv o 8139cp - module_param Thomas Gleixner: o rtl8139too.c: Fix missing pci_disable_dev o rtl8139too.c: Fix missing pci_disable_dev Tony Lindgren: o Add OMAP support to smc91x Ethernet driver --------------020904010101080409030203-- From romieu@fr.zoreil.com Sun Feb 13 15:27:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:27:29 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNRLPW003951 for ; Sun, 13 Feb 2005 15:27:22 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNQ4qU002909; Mon, 14 Feb 2005 00:26:04 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNPxP5002908; Mon, 14 Feb 2005 00:25:59 +0100 Date: Mon, 14 Feb 2005 00:25:59 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, Stephen Hemminger , Randy Dunlap , James Ketrenos Subject: [patch 2.6.11-rc4-netdev1 2/4] ieee80211: removal of unneeded checks Message-ID: <20050213232559.GA2898@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> <20050213232421.GB2060@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050213232421.GB2060@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1597 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: 3766 Lines: 152 Remove several checks before free/undo. It turns out that crypto_free_tfm() did not need to be issued in ieee80211_ccmp_init() nor in prism2_wep_init(). Signed-off-by: Francois Romieu diff -puN net/ieee80211/ieee80211_crypt_ccmp.c~80211-010 net/ieee80211/ieee80211_crypt_ccmp.c --- a/net/ieee80211/ieee80211_crypt_ccmp.c~80211-010 2005-02-13 23:39:29.137921826 +0100 +++ b/net/ieee80211/ieee80211_crypt_ccmp.c 2005-02-13 23:39:59.957874980 +0100 @@ -81,7 +81,7 @@ static void * ieee80211_ccmp_init(int ke priv = kmalloc(sizeof(*priv), GFP_ATOMIC); if (priv == NULL) - goto fail; + goto out; memset(priv, 0, sizeof(*priv)); priv->key_idx = key_idx; @@ -89,19 +89,11 @@ static void * ieee80211_ccmp_init(int ke if (priv->tfm == NULL) { printk(KERN_DEBUG "ieee80211_crypt_ccmp: could not allocate " "crypto API aes\n"); - goto fail; - } - - return priv; - -fail: - if (priv) { - if (priv->tfm) - crypto_free_tfm(priv->tfm); kfree(priv); + priv = NULL; } - - return NULL; +out: + return priv; } diff -puN net/ieee80211/ieee80211_crypt_tkip.c~80211-010 net/ieee80211/ieee80211_crypt_tkip.c --- a/net/ieee80211/ieee80211_crypt_tkip.c~80211-010 2005-02-13 23:39:29.140921334 +0100 +++ b/net/ieee80211/ieee80211_crypt_tkip.c 2005-02-14 00:10:37.681957335 +0100 @@ -67,37 +67,35 @@ static void * ieee80211_tkip_init(int ke struct ieee80211_tkip_data *priv; priv = kmalloc(sizeof(*priv), GFP_ATOMIC); - if (priv == NULL) - goto fail; - memset(priv, 0, sizeof(*priv)); - priv->key_idx = key_idx; - - priv->tfm_arc4 = crypto_alloc_tfm("arc4", 0); - if (priv->tfm_arc4 == NULL) { - printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " - "crypto API arc4\n"); - goto fail; - } - - priv->tfm_michael = crypto_alloc_tfm("michael_mic", 0); - if (priv->tfm_michael == NULL) { - printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " - "crypto API michael_mic\n"); - goto fail; - } - - return priv; - -fail: if (priv) { - if (priv->tfm_michael) - crypto_free_tfm(priv->tfm_michael); - if (priv->tfm_arc4) - crypto_free_tfm(priv->tfm_arc4); - kfree(priv); + struct { + struct crypto_tfm **tfm; + char *name; + } tab[] = { + { &priv->tfm_arc4, "arc4" }, + { &priv->tfm_michael, "michael_mic" }, + { NULL, NULL } + }, *p; + + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + for (p = tab; p->name; p++) { + *p->tfm = crypto_alloc_tfm(p->name, 0); + if (!*p->tfm) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: " + "could not allocate crypto API %s\n", + p->name); + while (p-- != tab) + crypto_free_tfm(*p->tfm); + kfree(priv); + priv = NULL; + break; + } + } } - return NULL; + return priv; } diff -puN net/ieee80211/ieee80211_crypt_wep.c~80211-010 net/ieee80211/ieee80211_crypt_wep.c --- a/net/ieee80211/ieee80211_crypt_wep.c~80211-010 2005-02-13 23:39:29.143920843 +0100 +++ b/net/ieee80211/ieee80211_crypt_wep.c 2005-02-13 23:39:29.148920025 +0100 @@ -45,30 +45,24 @@ static void * prism2_wep_init(int keyidx struct prism2_wep_data *priv; priv = kmalloc(sizeof(*priv), GFP_ATOMIC); - if (priv == NULL) - goto fail; + if (!priv) + goto out; memset(priv, 0, sizeof(*priv)); priv->key_idx = keyidx; priv->tfm = crypto_alloc_tfm("arc4", 0); - if (priv->tfm == NULL) { + if (!priv->tfm) { printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate " "crypto API arc4\n"); - goto fail; + kfree(priv); + priv = NULL; + goto out; } /* start WEP IV from a random value */ get_random_bytes(&priv->iv, 4); - +out: return priv; - -fail: - if (priv) { - if (priv->tfm) - crypto_free_tfm(priv->tfm); - kfree(priv); - } - return NULL; } _ From romieu@fr.zoreil.com Sun Feb 13 15:27:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:27:28 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNRLcE003952 for ; Sun, 13 Feb 2005 15:27:22 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNOScP002896; Mon, 14 Feb 2005 00:24:28 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNOM57002895; Mon, 14 Feb 2005 00:24:22 +0100 Date: Mon, 14 Feb 2005 00:24:21 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, Stephen Hemminger , Randy Dunlap , James Ketrenos Subject: [patch 2.6.11-rc4-netdev1 1/4] ieee80211: failure of ieee80211_crypto_init() Message-ID: <20050213232421.GB2060@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420FBAD3.3020909@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1596 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: 2592 Lines: 84 Tell the world that ieee80211_crypto_init() failed and propagate its status code. Signed-off-by: Francois Romieu diff -puN net/ieee80211/ieee80211_crypt.c~80211-000 net/ieee80211/ieee80211_crypt.c --- a/net/ieee80211/ieee80211_crypt.c~80211-000 2005-02-13 23:38:22.751792758 +0100 +++ b/net/ieee80211/ieee80211_crypt.c 2005-02-13 23:38:22.762790957 +0100 @@ -207,17 +207,23 @@ static struct ieee80211_crypto_ops ieee8 static int __init ieee80211_crypto_init(void) { + int ret = -ENOMEM; + hcrypt = kmalloc(sizeof(*hcrypt), GFP_KERNEL); - if (hcrypt == NULL) - return -ENOMEM; + if (!hcrypt) + goto out; memset(hcrypt, 0, sizeof(*hcrypt)); INIT_LIST_HEAD(&hcrypt->algs); spin_lock_init(&hcrypt->lock); - (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); - - return 0; + ret = ieee80211_register_crypto_ops(&ieee80211_crypt_null); + if (ret < 0) { + kfree(hcrypt); + hcrypt = NULL; + } +out: + return ret; } diff -puN net/ieee80211/ieee80211_crypt_ccmp.c~80211-000 net/ieee80211/ieee80211_crypt_ccmp.c --- a/net/ieee80211/ieee80211_crypt_ccmp.c~80211-000 2005-02-13 23:38:22.754792267 +0100 +++ b/net/ieee80211/ieee80211_crypt_ccmp.c 2005-02-13 23:38:22.763790793 +0100 @@ -456,10 +456,7 @@ static struct ieee80211_crypto_ops ieee8 static int __init ieee80211_crypto_ccmp_init(void) { - if (ieee80211_register_crypto_ops(&ieee80211_crypt_ccmp) < 0) - return -1; - - return 0; + return ieee80211_register_crypto_ops(&ieee80211_crypt_ccmp); } diff -puN net/ieee80211/ieee80211_crypt_tkip.c~80211-000 net/ieee80211/ieee80211_crypt_tkip.c --- a/net/ieee80211/ieee80211_crypt_tkip.c~80211-000 2005-02-13 23:38:22.757791776 +0100 +++ b/net/ieee80211/ieee80211_crypt_tkip.c 2005-02-13 23:38:22.764790629 +0100 @@ -694,10 +694,7 @@ static struct ieee80211_crypto_ops ieee8 static int __init ieee80211_crypto_tkip_init(void) { - if (ieee80211_register_crypto_ops(&ieee80211_crypt_tkip) < 0) - return -1; - - return 0; + return ieee80211_register_crypto_ops(&ieee80211_crypt_tkip); } diff -puN net/ieee80211/ieee80211_crypt_wep.c~80211-000 net/ieee80211/ieee80211_crypt_wep.c --- a/net/ieee80211/ieee80211_crypt_wep.c~80211-000 2005-02-13 23:38:22.759791448 +0100 +++ b/net/ieee80211/ieee80211_crypt_wep.c 2005-02-13 23:38:22.764790629 +0100 @@ -258,10 +258,7 @@ static struct ieee80211_crypto_ops ieee8 static int __init ieee80211_crypto_wep_init(void) { - if (ieee80211_register_crypto_ops(&ieee80211_crypt_wep) < 0) - return -1; - - return 0; + return ieee80211_register_crypto_ops(&ieee80211_crypt_wep); } _ From romieu@fr.zoreil.com Sun Feb 13 15:31:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:31:23 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNVHiR004951 for ; Sun, 13 Feb 2005 15:31:18 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNSh5x003016; Mon, 14 Feb 2005 00:28:43 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNSbEa003015; Mon, 14 Feb 2005 00:28:37 +0100 Date: Mon, 14 Feb 2005 00:28:37 +0100 From: Francois Romieu To: Jeff Garzik , netdev@oss.sgi.com Cc: Stephen Hemminger , Randy Dunlap , James Ketrenos Subject: [patch 2.6.11-rc4-netdev1 4/4] ieee80211: offset_in_page() removal Message-ID: <20050213232837.GC2898@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> <20050213232421.GB2060@electric-eye.fr.zoreil.com> <20050213232559.GA2898@electric-eye.fr.zoreil.com> <20050213232729.GB2898@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050213232729.GB2898@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1598 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: 513 Lines: 19 offset_in_page() removal. Signed-off-by: Francois Romieu diff -puN include/net/ieee80211.h~80211-030 include/net/ieee80211.h --- a/include/net/ieee80211.h~80211-030 2005-02-14 00:10:56.416908756 +0100 +++ b/include/net/ieee80211.h 2005-02-14 00:10:56.419908268 +0100 @@ -884,9 +884,4 @@ static inline const char *escape_essid(c *d = '\0'; return escaped; } - -#ifndef offset_in_page -#define offset_in_page(p) ((unsigned long)(p) & ~PAGE_MASK) -#endif - #endif /* IEEE80211_H */ _ From romieu@fr.zoreil.com Sun Feb 13 15:31:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:31:23 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNVIOR004952 for ; Sun, 13 Feb 2005 15:31:18 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNRYG0003002; Mon, 14 Feb 2005 00:27:34 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNRTP0003001; Mon, 14 Feb 2005 00:27:29 +0100 Date: Mon, 14 Feb 2005 00:27:29 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, Stephen Hemminger , Randy Dunlap , James Ketrenos Subject: [patch 2.6.11-rc4-netdev1 3/4] ieee80211: C99 initialization for eap_types Message-ID: <20050213232729.GB2898@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> <20050213232421.GB2060@electric-eye.fr.zoreil.com> <20050213232559.GA2898@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050213232559.GA2898@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1599 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: 1075 Lines: 40 C99 initialization for eap_types. Signed-off-by: Francois Romieu diff -puN include/net/ieee80211.h~80211-020 include/net/ieee80211.h --- a/include/net/ieee80211.h~80211-020 2005-02-14 00:10:49.003115207 +0100 +++ b/include/net/ieee80211.h 2005-02-14 00:10:49.007114556 +0100 @@ -64,16 +64,25 @@ struct ieee80211_hdr_3addr { u16 seq_ctl; } __attribute__ ((packed)); +enum eap_type { + EAP_PACKET = 0, + EAPOL_START, + EAPOL_LOGOFF, + EAPOL_KEY, + EAPOL_ENCAP_ASF_ALERT +}; + static const char *eap_types[] = { - "EAP-Packet", "EAPOL-Start", "EAPOL-Logoff", "EAPOL-Key", - "EAPOL-Encap-ASF-Alert", "Unknown" + [EAP_PACKET] = "EAP-Packet", + [EAPOL_START] = "EAPOL-Start", + [EAPOL_LOGOFF] = "EAPOL-Logoff", + [EAPOL_KEY] = "EAPOL-Key", + [EAPOL_ENCAP_ASF_ALERT] = "EAPOL-Encap-ASF-Alert" }; static inline const char *eap_get_type(int type) { - if (type > ARRAY_SIZE(eap_types)) - type = ARRAY_SIZE(eap_types) - 1; - return eap_types[type]; + return (type >= ARRAY_SIZE(eap_types)) ? "Unknown" : eap_types[type]; } struct eapol { _ From romieu@fr.zoreil.com Sun Feb 13 15:35:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:35:15 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNZAUB005963 for ; Sun, 13 Feb 2005 15:35:10 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNV4Ni003034; Mon, 14 Feb 2005 00:31:04 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNUxBQ003033; Mon, 14 Feb 2005 00:30:59 +0100 Date: Mon, 14 Feb 2005 00:30:59 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 2.6.11-rc4-netdev1 1/2] strip: clash with include/linux/netdevice.h Message-ID: <20050213233059.GC2060@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420FBAD3.3020909@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1600 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: 1141 Lines: 31 Clash with include/linux/netdevice.h Signed-off-by: Francois Romieu diff -puN drivers/net/wireless/strip.c~strip-000 drivers/net/wireless/strip.c --- a/drivers/net/wireless/strip.c~strip-000 2005-02-14 00:11:04.238635826 +0100 +++ b/drivers/net/wireless/strip.c 2005-02-14 00:11:04.242635176 +0100 @@ -2398,10 +2398,11 @@ static int set_mac_address(struct strip return 0; } -static int dev_set_mac_address(struct net_device *dev, void *addr) +static int strip_set_mac_address(struct net_device *dev, void *addr) { struct strip *strip_info = (struct strip *) (dev->priv); struct sockaddr *sa = addr; + printk(KERN_INFO "%s: strip_set_dev_mac_address called\n", dev->name); set_mac_address(strip_info, (MetricomAddress *) sa->sa_data); return 0; @@ -2552,7 +2553,7 @@ static void strip_dev_setup(struct net_d dev->hard_start_xmit = strip_xmit; dev->hard_header = strip_header; dev->rebuild_header = strip_rebuild_header; - dev->set_mac_address = dev_set_mac_address; + dev->set_mac_address = strip_set_mac_address; dev->get_stats = strip_get_stats; dev->change_mtu = strip_change_mtu; } _ From romieu@fr.zoreil.com Sun Feb 13 15:35:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 15:35:15 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1DNZA0W005962 for ; Sun, 13 Feb 2005 15:35:10 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1DNWnMt003207; Mon, 14 Feb 2005 00:32:49 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1DNWicf003206; Mon, 14 Feb 2005 00:32:44 +0100 Date: Mon, 14 Feb 2005 00:32:43 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 2.6.11-rc4-netdev1 2/2] strip: use of netdev_priv Message-ID: <20050213233243.GD2898@electric-eye.fr.zoreil.com> References: <420FBAD3.3020909@pobox.com> <20050213233059.GC2060@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050213233059.GC2060@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1601 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: 3063 Lines: 82 Use of netdev_priv. Signed-off-by: Francois Romieu diff -puN drivers/net/wireless/strip.c~strip-010 drivers/net/wireless/strip.c --- a/drivers/net/wireless/strip.c~strip-010 2005-02-14 00:11:08.527937733 +0100 +++ b/drivers/net/wireless/strip.c 2005-02-14 00:11:08.532936920 +0100 @@ -876,7 +876,7 @@ static int allocate_buffers(struct strip */ static int strip_change_mtu(struct net_device *dev, int new_mtu) { - struct strip *strip_info = dev->priv; + struct strip *strip_info = netdev_priv(dev); int old_mtu = strip_info->mtu; unsigned char *orbuff = strip_info->rx_buff; unsigned char *osbuff = strip_info->sx_buff; @@ -1563,7 +1563,7 @@ static void strip_send(struct strip *str /* Encapsulate a datagram and kick it into a TTY queue. */ static int strip_xmit(struct sk_buff *skb, struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (!netif_running(dev)) { printk(KERN_ERR "%s: xmit call when iface is down\n", @@ -1639,7 +1639,7 @@ static int strip_header(struct sk_buff * unsigned short type, void *daddr, void *saddr, unsigned len) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); STRIP_Header *header = (STRIP_Header *) skb_push(skb, sizeof(STRIP_Header)); /*printk(KERN_INFO "%s: strip_header 0x%04X %s\n", dev->name, type, @@ -1648,7 +1648,7 @@ static int strip_header(struct sk_buff * header->src_addr = strip_info->true_dev_addr; header->protocol = htons(type); - /*HexDump("strip_header", (struct strip *)(dev->priv), skb->data, skb->data + skb->len); */ + /*HexDump("strip_header", netdev_priv(dev), skb->data, skb->data + skb->len); */ if (!daddr) return (-dev->hard_header_len); @@ -2400,7 +2400,7 @@ static int set_mac_address(struct strip static int strip_set_mac_address(struct net_device *dev, void *addr) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); struct sockaddr *sa = addr; printk(KERN_INFO "%s: strip_set_dev_mac_address called\n", dev->name); @@ -2410,8 +2410,8 @@ static int strip_set_mac_address(struct static struct net_device_stats *strip_get_stats(struct net_device *dev) { + struct strip *strip_info = netdev_priv(dev); static struct net_device_stats stats; - struct strip *strip_info = (struct strip *) (dev->priv); memset(&stats, 0, sizeof(struct net_device_stats)); @@ -2455,7 +2455,7 @@ static struct net_device_stats *strip_ge static int strip_open_low(struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (strip_info->tty == NULL) return (-ENODEV); @@ -2488,7 +2488,7 @@ static int strip_open_low(struct net_dev static int strip_close_low(struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (strip_info->tty == NULL) return -EBUSY; _ From dan@coverfire.com Sun Feb 13 16:24:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 16:24:19 -0800 (PST) Received: from otis.cyg.net (otis.cyg.net [69.41.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E0ODbe011018 for ; Sun, 13 Feb 2005 16:24:13 -0800 Received: from ganymede.coverfire.com (ganymede.coverfire.com [69.41.199.10]) (authenticated bits=0) by otis.cyg.net (8.12.11/8.12.11) with ESMTP id j1E0NaHj028481; Sun, 13 Feb 2005 19:23:36 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: Dan Siemon To: Thomas Graf Cc: hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20050212223204.GG31837@postel.suug.ch> References: <1106144009.1047.989.camel@jzny.localdomain> <20050119165421.GB26856@postel.suug.ch> <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> Content-Type: text/plain Date: Sun, 13 Feb 2005 19:23:37 -0500 Message-Id: <1108340618.14978.66.camel@ganymede> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dan@coverfire.com Precedence: bulk X-list: netdev Content-Length: 3203 Lines: 71 On Sat, 2005-12-02 at 23:32 +0100, Thomas Graf wrote: > * Dan Siemon <1108246033.7554.18.camel@ganymede> 2005-02-12 17:07 > > Yes, a SOAP/XML-RPC interface should be quite possible. This is one of > > the main reasons I went to the trouble of creating the Mono bindings. I > > need to create some sort of XML interface to LQL in the next few weeks. > > Before you go ahead, please consider its possible usages. If possible > it should conform to an existing format allowing for distributed > configuration of network nodes. If no such thing exist and you design > your own format please consider the following requirements, because it > would be sad if you waste effort that needs to be redone later on. The initial implementation will be very specific to LQLs methods. I need this for a prototype application. > - The whole interface must take care of the byte order issues. This is > the most tricky part. I don't see how byte order issues are a problem when using SOAP. Example? > > As for combining my work with Thomas, I'm certainly willing to discuss > > it. > > So let's discuss it, from what I can see your library only consists of > basic netlink connection abilities and message parsers/builders on a > per netlink user basis. You do not provide any ways to customize it, > if the user of your library wants to send its own messages he's pretty > much on its own because the whole process of constructing the message, > sending it and waiting for the ack is hidden behind one single function. My main design goal for LQL is a nice C library for the existing QoS elements (and later link and friends). As such public functions that allow the user of the library to construct their own nlmsg packets is not my main interest. The functions in the LQL namespace attempt to hide all aspects of Netlink and the underlying communication to the kernel. However, I do have functions for manipulating raw messages. These functions are all in the NL namespace (nl.c and nl.h). They are quite purposely hidden from the public API documentation. Perhaps these functions should be documented publicly; although for 99% of the people using the library the last thing they want to do is build a netlink message. Examples: gboolean nl_tcpacket_add_rtattr(TcPacket *pkt, unsigned short type, unsigned short len, void *data); This function adds a new rtattr to the message. There is a similar function that adds a nested rtattr. nl_tcpacket_do_command() will send the message and wait for an ACK. Usage examples can be found in lql_qdisc_htb_helper.c. > Honestly speaking, your API doesn't fit my needs and the changes to > make it suiteable would be rather big so I'm not sure whether a merge > of my code into yours would make much sense and the only that could be > merged from your side to mine would be the additional support for two > or three qdiscs such as htb. I'm curious exactly what your needs are. It does appear you are aiming for a somewhat more low level library than I am. Whether or not that precludes some kind of merger I don't know. -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 From mgalgoci@parcelfarce.linux.theplanet.co.uk Sun Feb 13 17:04:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 17:04:47 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E14bEj012371 for ; Sun, 13 Feb 2005 17:04:38 -0800 Received: from [127.0.0.1] (helo=localhost) by parcelfarce.linux.theplanet.co.uk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D0UfE-0001lH-Ok; Mon, 14 Feb 2005 01:04:36 +0000 Date: Mon, 14 Feb 2005 01:04:36 +0000 (GMT) From: Matthew J Galgoci To: jgarzik@pobox.corp, netdev@oss.sgi.com Subject: [patch] wireless-2.6 stuff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mgalgoci@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: netdev Content-Length: 19612 Lines: 528 Jeff, Here are some basic no-brainer stuff for wireless-2.6. I don't have any atmel hardware to test though. Matt drivers/net/wireless/ieee802_11.h | 78 -------------------------------------- drivers/net/wireless/Kconfig | 46 ++++++++-------------- drivers/net/wireless/atmel.c | 62 +++++++++++++++--------------- drivers/net/wireless/orinoco.c | 11 ++--- drivers/net/wireless/todo.txt | 2 drivers/net/wireless/wl3501.h | 4 - 6 files changed, 59 insertions(+), 144 deletions(-) through these ChangeSets: (05/02/13 1.2033) - convert various drivers to use - mark obsolete pre-802.11 radios diff -Nru a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig --- a/drivers/net/wireless/Kconfig 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/Kconfig 2005-02-13 19:18:22 -05:00 @@ -6,7 +6,7 @@ depends on NETDEVICES config NET_RADIO - bool "Wireless LAN drivers (non-hamradio) & Wireless Extensions" + bool "Wireless LAN drivers (non-hamradio) and Wireless Extensions" ---help--- Support for wireless LANs and everything having to do with radio, but not with amateur radio or FM broadcasting. @@ -24,18 +24,12 @@ the tools from . - Some user-level drivers for scarab devices which don't require - special kernel support are available from - . - -# Note : the cards are obsolete (can't buy them anymore), but the drivers -# are not, as people are still using them... -comment "Obsolete Wireless cards support (pre-802.11)" - depends on NET_RADIO && (INET || ISA || PCMCIA) +comment "Obsolete Wireless cards support (pre-802.11) (OBSOLETE)" + depends on NET_RADIO && (INET || ISA || PCMCIA) && OBSOLETE config STRIP - tristate "STRIP (Metricom starmode radio IP)" - depends on NET_RADIO && INET + tristate "STRIP (Metricom starmode radio IP) (OBSOLETE)" + depends on NET_RADIO && INET && OBSOLETE ---help--- Say Y if you have a Metricom radio and intend to use Starmode Radio IP. STRIP is a radio protocol developed for the MosquitoNet project @@ -57,23 +51,19 @@ called strip. config ARLAN - tristate "Aironet Arlan 655 & IC2200 DS support" - depends on NET_RADIO && ISA && !64BIT + tristate "Aironet Arlan 655 & IC2200 DS support (OBSOLETE)" + depends on NET_RADIO && ISA && !64BIT && OBSOLETE ---help--- Aironet makes Arlan, a class of wireless LAN adapters. These use the www.Telxon.com chip, which is also used on several similar cards. - This driver is tested on the 655 and IC2200 series cards. Look at - for the latest information. + This driver is tested on the 655 and IC2200 series cards. The driver is built as two modules, arlan and arlan-proc. The latter is the /proc interface and is not needed most of time. - On some computers the card ends up in non-valid state after some - time. Use a ping-reset script to clear it. - config WAVELAN - tristate "AT&T/Lucent old WaveLAN & DEC RoamAbout DS ISA support" - depends on NET_RADIO && ISA + tristate "AT&T/Lucent old WaveLAN & DEC RoamAbout DS ISA support (OBSOLETE)" + depends on NET_RADIO && ISA && OBSOLETE ---help--- The Lucent WaveLAN (formerly NCR and AT&T; or DEC RoamAbout DS) is a Radio LAN (wireless Ethernet-like Local Area Network) using the @@ -99,8 +89,8 @@ called wavelan. config PCMCIA_WAVELAN - tristate "AT&T/Lucent old WaveLAN Pcmcia wireless support" - depends on NET_RADIO && PCMCIA + tristate "AT&T/Lucent old WaveLAN Pcmcia wireless support (OBSOLETE)" + depends on NET_RADIO && PCMCIA && OBSOLETE help Say Y here if you intend to attach an AT&T/Lucent Wavelan PCMCIA (PC-card) wireless Ethernet networking card to your computer. This @@ -110,8 +100,8 @@ called wavelan_cs. If unsure, say N. config PCMCIA_NETWAVE - tristate "Xircom Netwave AirSurfer Pcmcia wireless support" - depends on NET_RADIO && PCMCIA + tristate "Xircom Netwave AirSurfer Pcmcia wireless support (OBSOLETE)" + depends on NET_RADIO && PCMCIA && OBSOLETE help Say Y here if you intend to attach this type of PCMCIA (PC-card) wireless Ethernet networking card to your computer. @@ -119,12 +109,12 @@ To compile this driver as a module, choose M here: the module will be called netwave_cs. If unsure, say N. -comment "Wireless 802.11 Frequency Hopping cards support" - depends on NET_RADIO && PCMCIA +comment "Wireless 802.11 Frequency Hopping cards support (OBSOLETE)" + depends on NET_RADIO && PCMCIA && OBSOLETE config PCMCIA_RAYCS - tristate "Aviator/Raytheon 2.4MHz wireless support" - depends on NET_RADIO && PCMCIA + tristate "Aviator/Raytheon 2.4MHz wireless support (OBSOLETE)" + depends on NET_RADIO && PCMCIA && OBSOLETE ---help--- Say Y here if you intend to attach an Aviator/Raytheon PCMCIA (PC-card) wireless Ethernet networking card to your computer. diff -Nru a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c --- a/drivers/net/wireless/atmel.c 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/atmel.c 2005-02-13 19:18:22 -05:00 @@ -68,7 +68,7 @@ #include #include #include -#include "ieee802_11.h" +#include #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -600,12 +600,12 @@ static void atmel_wmem32(struct atmel_private *priv, u16 pos, u32 data); static void atmel_command_irq(struct atmel_private *priv); static int atmel_validate_channel(struct atmel_private *priv, int channel); -static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u16 frame_len, u8 rssi); static void atmel_management_timer(u_long a); static void atmel_send_command(struct atmel_private *priv, int command, void *cmd, int cmd_size); static int atmel_send_command_wait(struct atmel_private *priv, int command, void *cmd, int cmd_size); -static void atmel_transmit_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_transmit_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u8 *body, int body_len); static u8 atmel_get_mib8(struct atmel_private *priv, u8 type, u8 index); @@ -809,7 +809,7 @@ static int start_tx (struct sk_buff *skb, struct net_device *dev) { struct atmel_private *priv = netdev_priv(dev); - struct ieee802_11_hdr header; + struct ieee80211_hdr header; unsigned long flags; u16 buff, frame_ctl, len = (ETH_ZLEN < skb->len) ? skb->len : ETH_ZLEN; u8 SNAP_RFC1024[6] = {0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00}; @@ -845,17 +845,17 @@ return 1; } - frame_ctl = IEEE802_11_FTYPE_DATA; + frame_ctl = IEEE80211_FTYPE_DATA; header.duration_id = 0; header.seq_ctl = 0; if (priv->wep_is_on) - frame_ctl |= IEEE802_11_FCTL_WEP; + frame_ctl |= IEEE80211_FCTL_WEP; if (priv->operating_mode == IW_MODE_ADHOC) { memcpy(&header.addr1, skb->data, 6); memcpy(&header.addr2, dev->dev_addr, 6); memcpy(&header.addr3, priv->BSSID, 6); } else { - frame_ctl |= IEEE802_11_FCTL_TODS; + frame_ctl |= IEEE80211_FCTL_TODS; memcpy(&header.addr1, priv->CurrentBSSID, 6); memcpy(&header.addr2, dev->dev_addr, 6); memcpy(&header.addr3, skb->data, 6); @@ -884,7 +884,7 @@ } static void atmel_transmit_management_frame(struct atmel_private *priv, - struct ieee802_11_hdr *header, + struct ieee80211_hdr *header, u8 *body, int body_len) { u16 buff; @@ -899,7 +899,7 @@ tx_update_descriptor(priv, header->addr1[0] & 0x01, len, buff, TX_PACKET_TYPE_MGMT); } -static void fast_rx_path(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void fast_rx_path(struct atmel_private *priv, struct ieee80211_hdr *header, u16 msdu_size, u16 rx_packet_loc, u32 crc) { /* fast path: unfragmented packet copy directly into skbuf */ @@ -937,7 +937,7 @@ } memcpy(skbp, header->addr1, 6); /* destination address */ - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) memcpy(&skbp[6], header->addr3, 6); else memcpy(&skbp[6], header->addr2, 6); /* source address */ @@ -972,14 +972,14 @@ return (crc ^ 0xffffffff) == netcrc; } -static void frag_rx_path(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void frag_rx_path(struct atmel_private *priv, struct ieee80211_hdr *header, u16 msdu_size, u16 rx_packet_loc, u32 crc, u16 seq_no, u8 frag_no, int more_frags) { u8 mac4[6]; u8 source[6]; struct sk_buff *skb; - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) memcpy(source, header->addr3, 6); else memcpy(source, header->addr2, 6); @@ -1064,7 +1064,7 @@ static void rx_done_irq(struct atmel_private *priv) { int i; - struct ieee802_11_hdr header; + struct ieee80211_hdr header; for (i = 0; atmel_rmem8(priv, atmel_rx(priv, RX_DESC_FLAGS_OFFSET, priv->rx_desc_head)) == RX_DESC_FLAG_VALID && @@ -1099,7 +1099,7 @@ /* probe for CRC use here if needed once five packets have arrived with the same crc status, we assume we know what's happening and stop probing */ if (priv->probe_crc) { - if (!priv->wep_is_on || !(frame_ctl & IEEE802_11_FCTL_WEP)) { + if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP)) { priv->do_rx_crc = probe_crc(priv, rx_packet_loc, msdu_size); } else { priv->do_rx_crc = probe_crc(priv, rx_packet_loc + 24, msdu_size - 24); @@ -1114,16 +1114,16 @@ } /* don't CRC header when WEP in use */ - if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE802_11_FCTL_WEP))) { + if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP))) { crc = crc32_le(0xffffffff, (unsigned char *)&header, 24); } msdu_size -= 24; /* header */ - if ((frame_ctl & IEEE802_11_FCTL_FTYPE) == IEEE802_11_FTYPE_DATA) { + if ((frame_ctl & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA) { - int more_fragments = frame_ctl & IEEE802_11_FCTL_MOREFRAGS; - u8 packet_fragment_no = seq_control & IEEE802_11_SCTL_FRAG; - u16 packet_sequence_no = (seq_control & IEEE802_11_SCTL_SEQ) >> 4; + int more_fragments = frame_ctl & IEEE80211_FCTL_MOREFRAGS; + u8 packet_fragment_no = seq_control & IEEE80211_SCTL_FRAG; + u16 packet_sequence_no = (seq_control & IEEE80211_SCTL_SEQ) >> 4; if (!more_fragments && packet_fragment_no == 0 ) { fast_rx_path(priv, &header, msdu_size, rx_packet_loc, crc); @@ -1133,7 +1133,7 @@ } } - if ((frame_ctl & IEEE802_11_FCTL_FTYPE) == IEEE802_11_FTYPE_MGMT) { + if ((frame_ctl & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT) { /* copy rest of packet into buffer */ atmel_copy_to_host(priv->dev, (unsigned char *)&priv->rx_buf, rx_packet_loc + 24, msdu_size); @@ -2637,10 +2637,10 @@ static void send_authentication_request(struct atmel_private *priv, u8 *challenge, int challenge_len) { - struct ieee802_11_hdr header; + struct ieee80211_hdr header; struct auth_body auth; - header.frame_ctl = cpu_to_le16(IEEE802_11_FTYPE_MGMT | IEEE802_11_STYPE_AUTH); + header.frame_ctl = cpu_to_le16(IEEE80211_FTYPE_MGMT | IEEE80211_STYPE_AUTH); header.duration_id = cpu_to_le16(0x8000); header.seq_ctl = 0; memcpy(header.addr1, priv->CurrentBSSID, 6); @@ -2651,7 +2651,7 @@ auth.alg = cpu_to_le16(C80211_MGMT_AAN_SHAREDKEY); /* no WEP for authentication frames with TrSeqNo 1 */ if (priv->CurrentAuthentTransactionSeqNum != 1) - header.frame_ctl |= cpu_to_le16(IEEE802_11_FCTL_WEP); + header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_WEP); } else { auth.alg = cpu_to_le16(C80211_MGMT_AAN_OPENSYSTEM); } @@ -2675,7 +2675,7 @@ { u8 *ssid_el_p; int bodysize; - struct ieee802_11_hdr header; + struct ieee80211_hdr header; struct ass_req_format { u16 capability; u16 listen_interval; @@ -2688,8 +2688,8 @@ u8 rates[4]; } body; - header.frame_ctl = cpu_to_le16(IEEE802_11_FTYPE_MGMT | - (is_reassoc ? IEEE802_11_STYPE_REASSOC_REQ : IEEE802_11_STYPE_ASSOC_REQ)); + header.frame_ctl = cpu_to_le16(IEEE80211_FTYPE_MGMT | + (is_reassoc ? IEEE80211_STYPE_REASSOC_REQ : IEEE80211_STYPE_ASSOC_REQ)); header.duration_id = cpu_to_le16(0x8000); header.seq_ctl = 0; @@ -2725,9 +2725,9 @@ atmel_transmit_management_frame(priv, &header, (void *)&body, bodysize); } -static int is_frame_from_current_bss(struct atmel_private *priv, struct ieee802_11_hdr *header) +static int is_frame_from_current_bss(struct atmel_private *priv, struct ieee80211_hdr *header) { - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) return memcmp(header->addr3, priv->CurrentBSSID, 6) == 0; else return memcmp(header->addr2, priv->CurrentBSSID, 6) == 0; @@ -2775,7 +2775,7 @@ } -static void store_bss_info(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void store_bss_info(struct atmel_private *priv, struct ieee80211_hdr *header, u16 capability, u16 beacon_period, u8 channel, u8 rssi, u8 ssid_len, u8 *ssid, int is_beacon) { @@ -3050,12 +3050,12 @@ } /* deals with incoming managment frames. */ -static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u16 frame_len, u8 rssi) { u16 subtype; - switch (subtype = le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_STYPE) { + switch (subtype = le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_STYPE) { case C80211_SUBTYPE_MGMT_BEACON : case C80211_SUBTYPE_MGMT_ProbeResponse: diff -Nru a/drivers/net/wireless/ieee802_11.h b/drivers/net/wireless/ieee802_11.h --- a/drivers/net/wireless/ieee802_11.h 2005-02-13 19:18:22 -05:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,78 +0,0 @@ -#ifndef _IEEE802_11_H -#define _IEEE802_11_H - -#define IEEE802_11_DATA_LEN 2304 -/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section - 6.2.1.1.2. - - The figure in section 7.1.2 suggests a body size of up to 2312 - bytes is allowed, which is a bit confusing, I suspect this - represents the 2304 bytes of real data, plus a possible 8 bytes of - WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ - - -#define IEEE802_11_HLEN 30 -#define IEEE802_11_FRAME_LEN (IEEE802_11_DATA_LEN + IEEE802_11_HLEN) - -struct ieee802_11_hdr { - u16 frame_ctl; - u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; - u16 seq_ctl; - u8 addr4[ETH_ALEN]; -} __attribute__ ((packed)); - -/* Frame control field constants */ -#define IEEE802_11_FCTL_VERS 0x0002 -#define IEEE802_11_FCTL_FTYPE 0x000c -#define IEEE802_11_FCTL_STYPE 0x00f0 -#define IEEE802_11_FCTL_TODS 0x0100 -#define IEEE802_11_FCTL_FROMDS 0x0200 -#define IEEE802_11_FCTL_MOREFRAGS 0x0400 -#define IEEE802_11_FCTL_RETRY 0x0800 -#define IEEE802_11_FCTL_PM 0x1000 -#define IEEE802_11_FCTL_MOREDATA 0x2000 -#define IEEE802_11_FCTL_WEP 0x4000 -#define IEEE802_11_FCTL_ORDER 0x8000 - -#define IEEE802_11_FTYPE_MGMT 0x0000 -#define IEEE802_11_FTYPE_CTL 0x0004 -#define IEEE802_11_FTYPE_DATA 0x0008 - -/* management */ -#define IEEE802_11_STYPE_ASSOC_REQ 0x0000 -#define IEEE802_11_STYPE_ASSOC_RESP 0x0010 -#define IEEE802_11_STYPE_REASSOC_REQ 0x0020 -#define IEEE802_11_STYPE_REASSOC_RESP 0x0030 -#define IEEE802_11_STYPE_PROBE_REQ 0x0040 -#define IEEE802_11_STYPE_PROBE_RESP 0x0050 -#define IEEE802_11_STYPE_BEACON 0x0080 -#define IEEE802_11_STYPE_ATIM 0x0090 -#define IEEE802_11_STYPE_DISASSOC 0x00A0 -#define IEEE802_11_STYPE_AUTH 0x00B0 -#define IEEE802_11_STYPE_DEAUTH 0x00C0 - -/* control */ -#define IEEE802_11_STYPE_PSPOLL 0x00A0 -#define IEEE802_11_STYPE_RTS 0x00B0 -#define IEEE802_11_STYPE_CTS 0x00C0 -#define IEEE802_11_STYPE_ACK 0x00D0 -#define IEEE802_11_STYPE_CFEND 0x00E0 -#define IEEE802_11_STYPE_CFENDACK 0x00F0 - -/* data */ -#define IEEE802_11_STYPE_DATA 0x0000 -#define IEEE802_11_STYPE_DATA_CFACK 0x0010 -#define IEEE802_11_STYPE_DATA_CFPOLL 0x0020 -#define IEEE802_11_STYPE_DATA_CFACKPOLL 0x0030 -#define IEEE802_11_STYPE_NULLFUNC 0x0040 -#define IEEE802_11_STYPE_CFACK 0x0050 -#define IEEE802_11_STYPE_CFPOLL 0x0060 -#define IEEE802_11_STYPE_CFACKPOLL 0x0070 - -#define IEEE802_11_SCTL_FRAG 0x000F -#define IEEE802_11_SCTL_SEQ 0xFFF0 - -#endif /* _IEEE802_11_H */ diff -Nru a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c --- a/drivers/net/wireless/orinoco.c 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/orinoco.c 2005-02-13 19:18:22 -05:00 @@ -441,6 +441,8 @@ #include #include +#include + #include #include #include @@ -448,7 +450,6 @@ #include "hermes.h" #include "hermes_rid.h" #include "orinoco.h" -#include "ieee802_11.h" /********************************************************************/ /* Module information */ @@ -484,7 +485,7 @@ /********************************************************************/ #define ORINOCO_MIN_MTU 256 -#define ORINOCO_MAX_MTU (IEEE802_11_DATA_LEN - ENCAPS_OVERHEAD) +#define ORINOCO_MAX_MTU (IEEE80211_DATA_LEN - ENCAPS_OVERHEAD) #define SYMBOL_MAX_VER_LEN (14) #define USER_BAP 0 @@ -735,7 +736,7 @@ if ( (new_mtu < ORINOCO_MIN_MTU) || (new_mtu > ORINOCO_MAX_MTU) ) return -EINVAL; - if ( (new_mtu + ENCAPS_OVERHEAD + IEEE802_11_HLEN) > + if ( (new_mtu + ENCAPS_OVERHEAD + IEEE80211_HLEN) > (priv->nicbuf_size - ETH_HLEN) ) return -EINVAL; @@ -1074,7 +1075,7 @@ stats->rx_dropped++; goto drop; } - if (length > IEEE802_11_DATA_LEN) { + if (length > IEEE80211_DATA_LEN) { printk(KERN_WARNING "%s: Oversized frame received (%d bytes)\n", dev->name, length); stats->rx_length_errors++; @@ -2178,7 +2179,7 @@ /* No need to lock, the hw_unavailable flag is already set in * alloc_orinocodev() */ - priv->nicbuf_size = IEEE802_11_FRAME_LEN + ETH_HLEN; + priv->nicbuf_size = IEEE80211_FRAME_LEN + ETH_HLEN; /* Initialize the firmware */ err = hermes_init(hw); diff -Nru a/drivers/net/wireless/todo.txt b/drivers/net/wireless/todo.txt --- a/drivers/net/wireless/todo.txt 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/todo.txt 2005-02-13 19:18:22 -05:00 @@ -7,9 +7,11 @@ 2) Bring new Wireless LAN driver not yet in the kernel there See my web page for details In particular : HostAP + In progress. 3) Misc o Mark wavelan, wavelan_cs, netwave_cs drivers as obsolete o Maybe arlan.c, ray_cs.c and strip.c also deserve to be obsolete + Completed. Jean II diff -Nru a/drivers/net/wireless/wl3501.h b/drivers/net/wireless/wl3501.h --- a/drivers/net/wireless/wl3501.h 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/wl3501.h 2005-02-13 19:18:22 -05:00 @@ -2,7 +2,7 @@ #define __WL3501_H__ #include -#include "ieee802_11.h" +#include /* define for WLA 2.0 */ #define WL3501_BLKSZ 256 @@ -548,7 +548,7 @@ struct wl3501_80211_tx_hdr { struct wl3501_80211_tx_plcp_hdr pclp_hdr; - struct ieee802_11_hdr mac_hdr; + struct ieee80211_hdr mac_hdr; } __attribute__ ((packed)); /* From SRS0+9030dc47798e09726bfb+540+infradead.org+hch@pentafluge.srs.infradead.org Sun Feb 13 23:04:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Feb 2005 23:04:08 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E7437O022559 for ; Sun, 13 Feb 2005 23:04:05 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D0aH5-0008S8-6Y; Mon, 14 Feb 2005 07:04:03 +0000 Date: Mon, 14 Feb 2005 07:04:03 +0000 From: Christoph Hellwig To: Matthew J Galgoci Cc: jgarzik@pobox.corp, netdev@oss.sgi.com Subject: Re: [patch] wireless-2.6 stuff Message-ID: <20050214070403.GA32480@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 326 Lines: 8 > -comment "Obsolete Wireless cards support (pre-802.11)" > - depends on NET_RADIO && (INET || ISA || PCMCIA) > +comment "Obsolete Wireless cards support (pre-802.11) (OBSOLETE)" > + depends on NET_RADIO && (INET || ISA || PCMCIA) && OBSOLETE bad idea. we have tons of totally outdated hardware that's not marked obsolete. From vincent.roqueta@ext.bull.net Mon Feb 14 00:21:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 00:22:00 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E8LgMT031490 for ; Mon, 14 Feb 2005 00:21:46 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id EC99F19D91F; Mon, 14 Feb 2005 09:21:39 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12222-06; Mon, 14 Feb 2005 09:21:37 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 4692419D916; Mon, 14 Feb 2005 09:21:37 +0100 (CET) Received: from frecb000719.frec.bull.fr ([129.183.101.52]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005021409302327:402 ; Mon, 14 Feb 2005 09:30:23 +0100 From: Vincent Roqueta Organization: BULL SA To: Andi Kleen Subject: Re: IP More Fragements bit problem. Date: Mon, 14 Feb 2005 09:27:38 +0100 User-Agent: KMail/1.6.1 References: <200502111708.16024.vincent.roqueta@ext.bull.net> In-Reply-To: Cc: netdev@oss.sgi.com MIME-Version: 1.0 Message-Id: <200502140927.38950.vincent.roqueta@ext.bull.net> X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 09:30:23, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 09:30:24, Serialize complete at 14/02/2005 09:30:24 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1E8LgMT031490 X-archive-position: 1605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent.roqueta@ext.bull.net Precedence: bulk X-list: netdev Content-Length: 1374 Lines: 39 Le vendredi 11 Février 2005 19:24, vous avez écrit : > Vincent Roqueta writes: > > D + MF > > *DELAY* > > A + MF > > B + MF > > C + MF > > D + MF > > *DELAY* > > ... > > > > After a while AIX destroy first fragments because of the IP fragements > > life time. Trond Myklebust said me you can do anything for that? > > Are you sure? I tested 2.6.10rc3 and it works correctly for > me with ping. The algorithm in ip_fragment() looks good too > from visual inspection. Yes, I am sure testing with NFSv3 over UDP. I can send you traces seen by AIX. > And ping uses the same code to fragment as NFS sunrpc > over UDP. Ok. > 19:15:24.100934 averell > trent: (frag 64564:1480@1480+) > 19:15:24.100938 averell > trent: (frag 64564:1480@2960+) > 19:15:24.100943 averell > trent: (frag 64564:1480@4440+) > 19:15:24.100947 averell > trent: (frag 64564:1480@5920+) > 19:15:24.100951 averell > trent: (frag 64564:1480@7400+) > 19:15:24.100957 averell > trent: (frag 64564:1128@8880) <--- No MF. I don't have that :( > Also why are you testing NFSv4 over UDP anyways? I thought > everybody was finally running it over TCP now. I am not testing NFSv4 over UDP, I am doing NFSv3 tests over UDP to compare performances between NFSv4 and NFSv3, and some interoperablity testing on NFS (v3 and v4). That the last tests that does not work fine. Vincent From vincent.roqueta@ext.bull.net Mon Feb 14 00:23:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 00:23:37 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E8NRU5031703 for ; Mon, 14 Feb 2005 00:23:27 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 09AB719D91F; Mon, 14 Feb 2005 09:23:27 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12222-10; Mon, 14 Feb 2005 09:23:24 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 932B319D916; Mon, 14 Feb 2005 09:23:24 +0100 (CET) Received: from frecb000719.frec.bull.fr ([129.183.101.52]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005021409320916:406 ; Mon, 14 Feb 2005 09:32:09 +0100 From: Vincent Roqueta Organization: BULL SA To: Nivedita Singhvi Subject: Re: IP More Fragements bit problem. Date: Mon, 14 Feb 2005 09:29:24 +0100 User-Agent: KMail/1.6.1 References: <200502111708.16024.vincent.roqueta@ext.bull.net> <420CFD1F.2060701@us.ibm.com> In-Reply-To: <420CFD1F.2060701@us.ibm.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Message-Id: <200502140929.24379.vincent.roqueta@ext.bull.net> X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 09:32:09, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 09:32:12, Serialize complete at 14/02/2005 09:32:12 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1E8NRU5031703 X-archive-position: 1606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent.roqueta@ext.bull.net Precedence: bulk X-list: netdev Content-Length: 638 Lines: 25 Le vendredi 11 Février 2005 19:44, vous avez écrit : > Vincent Roqueta wrote: > > On kernel 2.6.10rc2 and laters (last tested is 2.6.11-rc3) we have: > > > > A + MF > > B + MF > > C + MF > > D + MF > > > > That cause AIX waiting for the last packet with out sending ack > > So Linux suppose AIX didn't receive all, and re send all packets. > > So AIX is receiving that: > > A + MF > > B + MF > > C + MF > > D + MF > > *DELAY * > > Silly question, but are you absolutely sure that the original wasn't > actually ABCDE? No, we are not sure. It is possible we lack the last fragement witch is not marked with the MF bit. Vincent ROQUETA From mgalgoci@parcelfarce.linux.theplanet.co.uk Mon Feb 14 00:42:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 00:42:51 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E8gk7b000774 for ; Mon, 14 Feb 2005 00:42:47 -0800 Received: from [127.0.0.1] (helo=localhost) by parcelfarce.linux.theplanet.co.uk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D0bob-0001GH-J4; Mon, 14 Feb 2005 08:42:45 +0000 Date: Mon, 14 Feb 2005 08:42:45 +0000 (GMT) From: Matthew J Galgoci To: netdev@oss.sgi.com cc: jgarzik@pobox.com, hch@infradead.org Subject: Re: [patch] wireless-2.6 stuff In-Reply-To: <20050214070403.GA32480@infradead.org> Message-ID: References: <20050214070403.GA32480@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mgalgoci@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: netdev Content-Length: 598 Lines: 15 On Mon, 14 Feb 2005, Christoph Hellwig wrote: > > -comment "Obsolete Wireless cards support (pre-802.11)" > > - depends on NET_RADIO && (INET || ISA || PCMCIA) > > +comment "Obsolete Wireless cards support (pre-802.11) (OBSOLETE)" > > + depends on NET_RADIO && (INET || ISA || PCMCIA) && OBSOLETE > > bad idea. we have tons of totally outdated hardware that's not marked > obsolete. On the grounds that these non-standard radios weren't horribly prolific and were pre-802.11, I think that they should be marked as obsolete and depend on obsolete. Does _anyone_ here have any of these radios? From okir@suse.de Mon Feb 14 03:29:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 03:29:18 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EBTBtl014842 for ; Mon, 14 Feb 2005 03:29:12 -0800 Received: from hermes.suse.de (hermes-ext.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 BAB60147659E for ; Mon, 14 Feb 2005 12:29:05 +0100 (CET) Date: Mon, 14 Feb 2005 12:29:05 +0100 From: Olaf Kirch To: netdev@oss.sgi.com Subject: [PATCH] VLAN over bonding Message-ID: <20050214112905.GF23861@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1608 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: 1513 Lines: 49 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, It seems when you create a VLAN configuration on top of a bonding device, any normal (non-VLAN) traffic stops completely. The reason is that bond_dev_queue_xmit() drops all outgoing frames that have no VLAN tag. The attached patch tries to fix this - is this the right way to do this, or does that break other areas of VLAN-over-bonding? Thanks Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=vlan-bonding-normal-frames Index: linux-2.6.10/drivers/net/bonding/bond_main.c =================================================================== --- linux-2.6.10.orig/drivers/net/bonding/bond_main.c +++ linux-2.6.10/drivers/net/bonding/bond_main.c @@ -807,15 +807,10 @@ struct vlan_entry *bond_next_vlan(struct int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev) { unsigned short vlan_id; - int res; if (!list_empty(&bond->vlan_list) && - !(slave_dev->features & NETIF_F_HW_VLAN_TX)) { - res = vlan_get_tag(skb, &vlan_id); - if (res) { - return -EINVAL; - } - + !(slave_dev->features & NETIF_F_HW_VLAN_TX) && + vlan_get_tag(skb, &vlan_id) == 0) { skb->dev = slave_dev; skb = vlan_put_tag(skb, vlan_id); if (!skb) { --XsQoSWH+UP9D9v3l-- From vincent.roqueta@ext.bull.net Mon Feb 14 04:31:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 04:31:39 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ECVScC020837 for ; Mon, 14 Feb 2005 04:31:29 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 489EA19D914; Mon, 14 Feb 2005 13:31:26 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25119-08; Mon, 14 Feb 2005 13:31:24 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id C643419D90D; Mon, 14 Feb 2005 13:31:23 +0100 (CET) Received: from frecb000719.frec.bull.fr ([129.183.101.52]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005021413400991:1157 ; Mon, 14 Feb 2005 13:40:09 +0100 From: Vincent Roqueta Organization: BULL SA To: Nivedita Singhvi Subject: Re: IP More Fragements bit problem. Date: Mon, 14 Feb 2005 13:37:25 +0100 User-Agent: KMail/1.6.1 References: <200502111708.16024.vincent.roqueta@ext.bull.net> <420CFD1F.2060701@us.ibm.com> <200502140929.24379.vincent.roqueta@ext.bull.net> In-Reply-To: <200502140929.24379.vincent.roqueta@ext.bull.net> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Message-Id: <200502141337.25499.vincent.roqueta@ext.bull.net> X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 13:40:09, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 14/02/2005 13:40:12, Serialize complete at 14/02/2005 13:40:12 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent.roqueta@ext.bull.net Precedence: bulk X-list: netdev Content-Length: 393 Lines: 16 Hello, > > > > Silly question, but are you absolutely sure that the original wasn't > > actually ABCDE? > > No, we are not sure. It is possible we lack the last fragement witch is not > marked with the MF bit. You are right. All fragments are not sent !!! And so the last fragment received is not the last fragment sent by the client. The MF is set and that is correct. Sorry :/ Vincent From sds@epoch.ncsc.mil Mon Feb 14 05:07:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 05:08:09 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ED7tsN022299 for ; Mon, 14 Feb 2005 05:07:56 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1ED4gI8025134; Mon, 14 Feb 2005 13:04:42 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1ED7ERH024557; Mon, 14 Feb 2005 08:07:14 -0500 (EST) Subject: Re: [RFC][PATCH 1/3] netlink check sender From: Stephen Smalley To: Chris Wright Cc: netdev@oss.sgi.com, davem@davemloft.net, James Morris , "Serge E. Hallyn" In-Reply-To: <20050212010243.W24171@build.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 14 Feb 2005 07:59:59 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 927 Lines: 29 On Sat, 2005-02-12 at 04:02, Chris Wright wrote: > ===== net/netlink/af_netlink.c 1.69 vs edited ===== > --- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00 > +++ edited/net/netlink/af_netlink.c 2005-02-11 18:05:59 -08:00 > int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) > { > struct netlink_opt *nlk; > - int len = skb->len; > - > + int err, len = skb->len; > + > nlk = nlk_sk(sk); > + > + printk("%s: %s(%d) send_check %p\n", __FUNCTION__, current->comm, current->pid, nlk->check_sender); > + if (nlk->check_sender) > + if ((err = nlk->check_sender(skb))) { > + netlink_detachskb(sk, skb); > + return err; > + } > + printk() is a leftover from debugging, I assume. Why place the check_sender() call here vs. just replacing the existing security_netlink_send() call in netlink_sendmsg() with this new call? -- Stephen Smalley National Security Agency From sds@tycho.nsa.gov Mon Feb 14 05:13:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 05:13:08 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EDD1Zm022881 for ; Mon, 14 Feb 2005 05:13:02 -0800 Received: from tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1EDA0I8025569; Mon, 14 Feb 2005 13:10:00 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1EDDBL9029669; Mon, 14 Feb 2005 08:13:11 -0500 (EST) Subject: Re: [RFC][PATCH 1/3] netlink check sender From: Stephen Smalley To: Chris Wright Cc: netdev@oss.sgi.com, davem@davemloft.net, James Morris , "Serge E. Hallyn" In-Reply-To: <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108386320.15437.22.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 14 Feb 2005 08:05:20 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@tycho.nsa.gov Precedence: bulk X-list: netdev Content-Length: 570 Lines: 14 On Mon, 2005-02-14 at 07:59, Stephen Smalley wrote: > printk() is a leftover from debugging, I assume. > Why place the check_sender() call here vs. just replacing the existing > security_netlink_send() call in netlink_sendmsg() with this new call? Sorry, replacing security_netlink_send() would be bad (for SELinux checking), but I'm not clear on why you don't put the check_sender() call right after it in netlink_sendmsg() so that you ensure that you have complete coverage (vs. unicast-specific). -- Stephen Smalley National Security Agency From sds@epoch.ncsc.mil Mon Feb 14 05:16:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 05:16:39 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EDG3Q4023439 for ; Mon, 14 Feb 2005 05:16:04 -0800 Received: from epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j1EDD0I8025789; Mon, 14 Feb 2005 13:13:00 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by epoch.ncsc.mil (8.12.8/8.12.8) with ESMTP id j1EDFYRH024633; Mon, 14 Feb 2005 08:15:34 -0500 (EST) Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit From: Stephen Smalley To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, James Morris , "Serge E. Hallyn" In-Reply-To: <420E77FA.6080007@eurodev.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> Content-Type: text/plain Organization: National Security Agency Message-Id: <1108386498.15437.26.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 14 Feb 2005 08:08:19 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@epoch.ncsc.mil Precedence: bulk X-list: netdev Content-Length: 1107 Lines: 28 On Sat, 2005-02-12 at 16:41, Pablo Neira wrote: > With your patch, a message from user space process that doesn't have the > capabilites follows this path: > > sys_sendmsg() -> netlink_sendmsg() -> netlink_unicast() -> > netlink_sendskb() = discarded here. > > Currently, it continues, for example in case of rtnetlink: > > ... -> netlink_sendskb() -> sk_data_ready(sk, len) -> rtnetlink_rcv() -> > rtnetlink_rcv_skb() -> rtnetlink_rcv_msg() = discarded here. > > Nowadays the message is enqueued but it's discarded later. So if I'm not > missing anything, I don't see the point of adding a new function to > check for capabilities/audit stuff just a bit before. Two reasons: 1) The sender-side checks allow checking (and auditing) based on the current task's credentials, vs. having to save the information in the netlink_skb_parms for use on the receiver side. 2) Performing the check up front at send time allows the kernel to reject it early and reduce extraneous processing / resource consumption by unauthorized processes. -- Stephen Smalley National Security Agency From kuznet@yakov.inr.ac.ru Mon Feb 14 06:13:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 06:13:58 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1EEDpZx025629 for ; Mon, 14 Feb 2005 06:13:54 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=d1VXrbz/6oI4b6zKr9UTNeh8XrM654HUMkzewzvoS20qe2fe7pagvNb7ISYOz+yPjmDt83bn4jOay6NGcrVtBJ2qfrvmHaOlBs5onU/ek/reWtalGghvX1QD7DpduMi/Msq2XSGLKEmxQVCZrbeG03JSe5Yq/wt2J9B03zp+3r4=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id RAA15919; Mon, 14 Feb 2005 17:12:24 +0300 Date: Mon, 14 Feb 2005 17:12:24 +0300 From: Alexey Kuznetsov To: Hubert Tonneau Cc: Alexey Kuznetsov , "David S. Miller" , rick.jones2@hp.com, shemminger@osdl.org, romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050214141224.GB15683@yakov.inr.ac.ru> References: <0528GVO12@server5.heliogroup.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0528GVO12@server5.heliogroup.fr> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1613 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: 459 Lines: 18 Hello! > ethtool -K eth1 tso off > the result is unchanged on 2.6.9 (14 seconds for 105 MB). > > After, > ethtool -K eth1 tso off > the result is also unchanged on 2.6.10-ac11 with no extra TCP patch (325 seconds). Well, it means the theory was wrong... tso is innocent. To make a new theory we need a tcpdump of 2.6.10 with disabled tso. > it's a production server, I hope we can stay in its normal configuration now. TSO may be kept disabled. Alexey From tgraf@suug.ch Mon Feb 14 06:26:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 06:27:03 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EEQwIR026471 for ; Mon, 14 Feb 2005 06:26:58 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E7C9CF; Mon, 14 Feb 2005 15:26:28 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id AE0F71C0EA; Mon, 14 Feb 2005 15:27:10 +0100 (CET) Date: Mon, 14 Feb 2005 15:27:10 +0100 From: Thomas Graf To: Dan Siemon Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050214142710.GI31837@postel.suug.ch> References: <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> <1108340618.14978.66.camel@ganymede> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108340618.14978.66.camel@ganymede> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1336 Lines: 30 > > - The whole interface must take care of the byte order issues. This is > > the most tricky part. > > I don't see how byte order issues are a problem when using SOAP. > Example? It depends on wehther your outline every qdisc/filter in the protocol. If you do so it's not a problem but you have to extend your protocol every time a new qdisc is introduced or an existing one changes. A generic partly binary based protocol will have byte order issues. My current idea, given I can't find an existing protocol, is to let every netlink user describe its own format with a generic grammar so the protocol can stay stable. One of the candidates is the netconf specification which basically does what we need but is still in early development. > I'm curious exactly what your needs are. Basically I need to be able to change the beavhiour of the message parser to for example overwrite the sequence number checking in order to do message multiplexing. It's not like I would be represenative though. > It does appear you are aiming for a somewhat more low level library than > I am. Whether or not that precludes some kind of merger I don't know. Yes, it seems so. It's a pitty that we waste effort by doing the same nearly work but I really need the low level API and the possibility to customize the parsing and sending code. From wensong@linux-vs.org Mon Feb 14 09:02:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 09:02:56 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EH2n3b005767 for ; Mon, 14 Feb 2005 09:02:50 -0800 Received: from penguin.linux-vs.org ([220.192.153.203]) by lb1.ctrip.com (8.12.10/8.12.10) with ESMTP id j1EH1cMh005528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2005 01:01:58 +0800 Received: from penguin.linux-vs.org (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id j1EH0iuA004180; Tue, 15 Feb 2005 01:00:44 +0800 Received: from localhost (wensong@localhost) by penguin.linux-vs.org (8.12.8/8.12.8/Submit) with ESMTP id j1EH0clp004175; Tue, 15 Feb 2005 01:00:42 +0800 X-Authentication-Warning: penguin.linux-vs.org: wensong owned process doing -bs Date: Tue, 15 Feb 2005 01:00:38 +0800 (CST) From: Wensong Zhang To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] [IPVS] Fixed that the WRR scheduler works correctly when server is updated or overloaded Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1463811584-572891765-1097000265=:2451" Content-ID: X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev Content-Length: 2662 Lines: 57 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Hi Dave, Here is the patch to make the WRR scheduler work correctly when server is updated with new weight or marked overloaded. Please check and apply it to kernel 2.6. Thanks, Wensong ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.6-ipvs-wrr.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.6-ipvs-wrr.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5 bGUgcGF0Y2guDQojDQojIENoYW5nZVNldA0KIyAgIDIwMDUvMDIvMTUgMDA6 NDQ6MTcrMDg6MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcgDQojICAgW0lQVlNd IEZpeGVkIHRoYXQgdGhlIFdSUiBzY2hlZHVsZXIgd29ya3MgY29ycmVjdGx5 IHdoZW4gc2VydmVyIGlzIHVwZGF0ZWQgb3Igb3ZlcmxvYWRlZC4NCiMgICAN CiMgICBUaGFua3MgbXVzdCBnbyB0byBLZWVzIEhvZWt6ZW1hIDxrZWVzQHR3 ZWFrZXJzLm5ldD4gZm9yIGRpc292ZXJpbmcgdGhlDQojICAgcHJvYmxlbSBh bmQgcHJvdmlkaW5nIGEgcGF0Y2guIFRoYW5rcyBnbyB0byBKdWxpYW4gYW5k IEhvcm1zIGZvciBkaXNjdXNzaW9uDQojICAgYW5kIG1ha2luZyB0aGlzIHBh dGNoLg0KIyANCiMgbmV0L2lwdjQvaXB2cy9pcF92c193cnIuYw0KIyAgIDIw MDUvMDIvMTUgMDA6NDM6NTArMDg6MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcg KzMgLTENCiMgICBmaXhlZCB0byByZXNldCBtYXJrLT5jdyBpZiBtYXJrLT5j dyBpcyBncmVhdGVyIHRoYW4gbWF4aW11bSB3ZWlnaHQgd2hpbGUgdXBkYXRp bmcgc2VydmljZTsNCiMgICBmaXhlZCB0byByZXR1cm4gTlVMTCBvbmx5IHdo ZW4gYWxsIHRoZSBzZXJ2ZXJzIGFyZSBub3QgYXZhaWxhYmxlIGF0IGFueSB3 ZWlnaHQuDQojICAgDQojIA0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQvaXB2cy9p cF92c193cnIuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfd3JyLmMNCi0tLSBh L25ldC9pcHY0L2lwdnMvaXBfdnNfd3JyLmMJMjAwNS0wMi0xNSAwMDo0Njow NSArMDg6MDANCisrKyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfd3JyLmMJMjAw NS0wMi0xNSAwMDo0NjowNSArMDg6MDANCkBAIC0xMjYsNiArMTI2LDggQEAN CiAJbWFyay0+Y2wgPSAmc3ZjLT5kZXN0aW5hdGlvbnM7DQogCW1hcmstPm13 ID0gaXBfdnNfd3JyX21heF93ZWlnaHQoc3ZjKTsNCiAJbWFyay0+ZGkgPSBp cF92c193cnJfZ2NkX3dlaWdodChzdmMpOw0KKwlpZiAobWFyay0+Y3cgPiBt YXJrLT5tdykNCisJCW1hcmstPmN3ID0gMDsNCiAJcmV0dXJuIDA7DQogfQ0K IA0KQEAgLTE4Niw3ICsxODgsNyBAQA0KIAkJCX0NCiAJCX0NCiANCi0JCWlm IChtYXJrLT5jbCA9PSBwKSB7DQorCQlpZiAobWFyay0+Y2wgPT0gcCAmJiBt YXJrLT5jdyA9PSBtYXJrLT5kaSkgew0KIAkJCS8qIGJhY2sgdG8gdGhlIHN0 YXJ0LCBhbmQgbm8gZGVzdCBpcyBmb3VuZC4NCiAJCQkgICBJdCBpcyBvbmx5 IHBvc3NpYmxlIHdoZW4gYWxsIGRlc3RzIGFyZSBPVkVSTE9BREVEICovDQog CQkJZGVzdCA9IE5VTEw7DQo= ---1463811584-572891765-1097000265=:2451-- From jdmason@us.ibm.com Mon Feb 14 09:20:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 09:20:38 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EHKQm1006569 for ; Mon, 14 Feb 2005 09:20:32 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1EHKI5j323626 for ; Mon, 14 Feb 2005 12:20:18 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1EHKIoO239378 for ; Mon, 14 Feb 2005 10:20:18 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1EHKHUG005401 for ; Mon, 14 Feb 2005 10:20:18 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1EHKH2p005388; Mon, 14 Feb 2005 10:20:17 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [patch 2.6.11-rc3 5/5] r8169: synchronization and balancing when the device is closed Date: Mon, 14 Feb 2005 11:16:54 -0600 User-Agent: KMail/1.7.2 Cc: Jeff Garzik , akpm@osdl.org, netdev@oss.sgi.com References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> <20050211234403.GC13644@electric-eye.fr.zoreil.com> <20050211234522.GD13644@electric-eye.fr.zoreil.com> In-Reply-To: <20050211234522.GD13644@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: <200502141116.54441.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 541 Lines: 20 [...] > @@ -2399,6 +2398,8 @@ static int rtl8169_close(struct net_devi > > free_irq(dev->irq, dev); > > + netif_poll_enable(dev); > + > pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, > tp->RxPhyAddr); > pci_free_consistent(pdev, R8169_TX_RING_BYTES, tp->TxDescArray, > > _ Dumb question....Why is this needed? dev_close has already checked for the bit before it calls the rtl8169_close routine (and it was already ripped out by netif_poll_disable in rtl8169_down). -- Jon Mason jdmason@us.ibm.com From olh@suse.de Mon Feb 14 09:47:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 09:47:52 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EHljXF007515 for ; Mon, 14 Feb 2005 09:47:46 -0800 Received: from hermes.suse.de (hermes-ext.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 7EDAF1479BBE for ; Mon, 14 Feb 2005 18:47:39 +0100 (CET) Date: Mon, 14 Feb 2005 18:47:39 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: [PATCH] fix typo in include/linux/socket.h Message-ID: <20050214174739.GA23145@suse.de> References: <20050212171521.GA3497@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050212171521.GA3497@suse.de> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 755 Lines: 17 I guess we have to reduce the patch to fix just the typo. Signed-off-by: Olaf Hering diff -purN linux-2.6.11-rc3-bk8/include/linux/socket.h linux-2.6.11/include/linux/socket.h --- linux-2.6.11-rc3-bk8/include/linux/socket.h 2005-02-03 02:56:33.000000000 +0100 +++ linux-2.6.11/include/linux/socket.h 2005-02-12 18:05:10.000000000 +0100 @@ -120,7 +108,7 @@ struct cmsghdr { * Now it always returns valid, not truncated ancillary object * HEADER. But caller still MUST check, that cmsg->cmsg_len is * inside range, given by msg->msg_controllen before using - * ansillary object DATA. --ANK (980731) + * ancillary object DATA. --ANK (980731) */ __KINLINE struct cmsghdr * __cmsg_nxthdr(void *__ctl, __kernel_size_t __size, From amitg@calsoftinc.com Mon Feb 14 09:51:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 09:51:20 -0800 (PST) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EHpDhP008083 for ; Mon, 14 Feb 2005 09:51:14 -0800 Received: from 172.16.0.125 (unknown [172.16.0.125]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id B1846DB589; Mon, 14 Feb 2005 23:13:35 +0530 (IST) From: Amit Gud Organization: Calsoft Pvt. Ltd. To: jgarzik@pobox.com, netdev@oss.sgi.com Subject: [PATCH 9/18] drivers/net/ remove pci_find_{device, subsys} Date: Mon, 14 Feb 2005 11:25:23 +0530 User-Agent: KMail/1.5 Cc: kernel-janitors@lists.osdl.org, gud@eth.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502141125.25185.amitg@calsoftinc.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amitg@calsoftinc.com Precedence: bulk X-list: netdev Content-Length: 5832 Lines: 131 Remove deprecated pci_find_device and pci_find_subsys AG -- May the source be with you Signed-off-by: Amit Gud diff -uprN orig/drivers/net/e1000/e1000_main.c linux-2.6.11-rc3/drivers/net/e1000/e1000_main.c --- orig/drivers/net/e1000/e1000_main.c 2005-02-11 15:19:48.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/e1000/e1000_main.c 2005-02-14 02:02:48.000000000 +0530 @@ -2792,7 +2792,7 @@ e1000_notify_reboot(struct notifier_bloc case SYS_DOWN: case SYS_HALT: case SYS_POWER_OFF: - while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { + while((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { if(pci_dev_driver(pdev) == &e1000_driver) e1000_suspend(pdev, 3); } diff -uprN orig/drivers/net/fc/iph5526.c linux-2.6.11-rc3/drivers/net/fc/iph5526.c --- orig/drivers/net/fc/iph5526.c 2004-10-19 03:23:43.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/fc/iph5526.c 2005-02-14 02:02:55.000000000 +0530 @@ -3711,7 +3711,7 @@ int iph5526_detect(Scsi_Host_Template *t fc[i] = NULL; for (i = 0; clone_list[i].vendor_id != 0; i++) - while ((pdev = pci_find_device(clone_list[i].vendor_id, clone_list[i].device_id, pdev))) { + while ((pdev = pci_get_device(clone_list[i].vendor_id, clone_list[i].device_id, pdev))) { unsigned short pci_command; if (pci_enable_device(pdev)) continue; diff -uprN orig/drivers/net/gt96100eth.c linux-2.6.11-rc3/drivers/net/gt96100eth.c --- orig/drivers/net/gt96100eth.c 2005-02-11 15:19:48.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/gt96100eth.c 2005-02-14 02:07:09.000000000 +0530 @@ -615,9 +615,9 @@ static int gt96100_init_module(void) /* * Stupid probe because this really isn't a PCI device */ - if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, + if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT96100, NULL)) && - !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, + !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) { printk(KERN_ERR __FILE__ ": GT96100 not found!\n"); return -ENODEV; diff -uprN orig/drivers/net/ixgb/ixgb_main.c linux-2.6.11-rc3/drivers/net/ixgb/ixgb_main.c --- orig/drivers/net/ixgb/ixgb_main.c 2005-02-11 15:19:48.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/ixgb/ixgb_main.c 2005-02-14 02:07:17.000000000 +0530 @@ -2087,7 +2087,7 @@ ixgb_notify_reboot(struct notifier_block case SYS_DOWN: case SYS_HALT: case SYS_POWER_OFF: - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { + while ((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { if (pci_dev_driver(pdev) == &ixgb_driver) ixgb_suspend(pdev, 3); } diff -uprN orig/drivers/net/skfp/drvfbi.c linux-2.6.11-rc3/drivers/net/skfp/drvfbi.c --- orig/drivers/net/skfp/drvfbi.c 2004-10-19 03:23:06.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/skfp/drvfbi.c 2005-02-14 02:07:23.000000000 +0530 @@ -1362,7 +1362,7 @@ int exist_board(struct s_smc *smc, int s ven_id = OEMID(smc,0) + (OEMID(smc,1) << 8) ; dev_id = OEMID(smc,2) + (OEMID(smc,3) << 8) ; for (i = 0; i < slot; i++) { - if (pci_find_device(i,&smc->hw.pci_handle, + if (pci_get_device(i,&smc->hw.pci_handle, dev_id,ven_id) != 0) { found = FALSE ; diff -uprN orig/drivers/net/sunhme.c linux-2.6.11-rc3/drivers/net/sunhme.c --- orig/drivers/net/sunhme.c 2005-02-11 15:19:50.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/sunhme.c 2005-02-14 02:07:29.000000000 +0530 @@ -3312,7 +3312,7 @@ static int __init happy_meal_pci_probe(v struct pci_dev *pdev = NULL; int cards = 0; - while ((pdev = pci_find_device(PCI_VENDOR_ID_SUN, + while ((pdev = pci_get_device(PCI_VENDOR_ID_SUN, PCI_DEVICE_ID_SUN_HAPPYMEAL, pdev)) != NULL) { if (pci_enable_device(pdev)) continue; diff -uprN orig/drivers/net/tg3.c linux-2.6.11-rc3/drivers/net/tg3.c --- orig/drivers/net/tg3.c 2005-02-11 15:19:50.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/tg3.c 2005-02-14 02:07:54.000000000 +0530 @@ -7825,15 +7825,15 @@ static int __devinit tg3_get_invariants( * every mailbox register write to force the writes to be * posted to the chip in order. */ - if (pci_find_device(PCI_VENDOR_ID_INTEL, + if (pci_get_device(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_8, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, + pci_get_device(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_8, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, + pci_get_device(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_11, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, + pci_get_device(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_6, NULL) || - pci_find_device(PCI_VENDOR_ID_AMD, + pci_get_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FE_GATE_700C, NULL)) tp->tg3_flags |= TG3_FLAG_MBOX_WRITE_REORDER; diff -uprN orig/drivers/net/wan/sdladrv.c linux-2.6.11-rc3/drivers/net/wan/sdladrv.c --- orig/drivers/net/wan/sdladrv.c 2004-10-19 03:23:43.000000000 +0530 +++ linux-2.6.11-rc3/drivers/net/wan/sdladrv.c 2005-02-14 02:08:15.000000000 +0530 @@ -2032,7 +2032,7 @@ static int find_s514_adapter(sdlahw_t* h slot_no = hw->S514_slot_no; - while ((pci_dev = pci_find_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) + while ((pci_dev = pci_get_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) != NULL) { pci_read_config_word(pci_dev, PCI_SUBSYS_VENDOR_WORD, @@ -2245,7 +2245,7 @@ static int pci_probe(sdlahw_t *hw) slot_no = 0; - while ((pci_dev = pci_find_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) + while ((pci_dev = pci_get_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) != NULL) { pci_read_config_word(pci_dev, PCI_SUBSYS_VENDOR_WORD, From greg@kroah.com Mon Feb 14 10:47:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 10:47:39 -0800 (PST) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EIlZZX015090 for ; Mon, 14 Feb 2005 10:47:36 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j1EIlXi30226; Mon, 14 Feb 2005 10:47:33 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D0lEd-2GH-00; Mon, 14 Feb 2005 10:46:15 -0800 Date: Mon, 14 Feb 2005 10:46:15 -0800 From: Greg KH To: Amit Gud Cc: jgarzik@pobox.com, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org, gud@eth.net Subject: Re: [KJ] [PATCH 9/18] drivers/net/ remove pci_find_{device, subsys} Message-ID: <20050214184613.GP7815@kroah.com> References: <200502141125.25185.amitg@calsoftinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502141125.25185.amitg@calsoftinc.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev Content-Length: 967 Lines: 23 On Mon, Feb 14, 2005 at 11:25:23AM +0530, Amit Gud wrote: > diff -uprN orig/drivers/net/gt96100eth.c linux-2.6.11-rc3/drivers/net/gt96100eth.c > --- orig/drivers/net/gt96100eth.c 2005-02-11 15:19:48.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/gt96100eth.c 2005-02-14 02:07:09.000000000 +0530 > @@ -615,9 +615,9 @@ static int gt96100_init_module(void) > /* > * Stupid probe because this really isn't a PCI device > */ > - if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, > + if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, > PCI_DEVICE_ID_MARVELL_GT96100, NULL)) && > - !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, > + !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, > PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) { > printk(KERN_ERR __FILE__ ": GT96100 not found!\n"); > return -ENODEV; This (and many other parts of this patch) are incorrect. Please do not apply. thanks, greg k-h From romieu@fr.zoreil.com Mon Feb 14 11:35:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 11:35:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EJZMGg016635 for ; Mon, 14 Feb 2005 11:35:23 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1EJVGsP014661; Mon, 14 Feb 2005 20:31:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1EJV6pS014642; Mon, 14 Feb 2005 20:31:06 +0100 Date: Mon, 14 Feb 2005 20:31:06 +0100 From: Francois Romieu To: Jon Mason Cc: Jeff Garzik , akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [patch 2.6.11-rc3 5/5] r8169: synchronization and balancing when the device is closed Message-ID: <20050214193106.GA14409@electric-eye.fr.zoreil.com> References: <20050211233918.GB8792@electric-eye.fr.zoreil.com> <20050211234403.GC13644@electric-eye.fr.zoreil.com> <20050211234522.GD13644@electric-eye.fr.zoreil.com> <200502141116.54441.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502141116.54441.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1620 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: 664 Lines: 23 Jon Mason : > [...] > > @@ -2399,6 +2398,8 @@ static int rtl8169_close(struct net_devi > > > > free_irq(dev->irq, dev); > > > > + netif_poll_enable(dev); > > + > > pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, > > tp->RxPhyAddr); > > pci_free_consistent(pdev, R8169_TX_RING_BYTES, tp->TxDescArray, > > > > _ > > Dumb question....Why is this needed? dev_close has already checked for the dev_open() after dev_close(): netif_rx_schedule_prep() always fails in rtl8169_interrupt() and the device can not be scheduled for poll. Sucky. So, if someone wants to push it before 2.6.11 goes out... -- Ueimor From vsu@murom.net Mon Feb 14 12:00:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 12:00:34 -0800 (PST) Received: from ns1.murom.ru (mail.murom.net [213.177.124.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EK0Q17017623 for ; Mon, 14 Feb 2005 12:00:27 -0800 Received: from [172.16.7.8] (helo=sirius.home) by ns1.murom.ru with esmtp (Exim 4.42) id 1D0mOb-0006dQ-4i; Mon, 14 Feb 2005 23:00:37 +0300 Received: by sirius.home (Postfix, from userid 500) id EB98E2C1C0B7; Mon, 14 Feb 2005 23:00:17 +0300 (MSK) Date: Mon, 14 Feb 2005 23:00:17 +0300 From: Sergey Vlasov To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 1/2] Fix documentation build failure Message-ID: <20050214200017.GA29201@sirius.home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vsu@altlinux.ru Precedence: bulk X-list: netdev Content-Length: 1743 Lines: 61 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello! In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs) fails on "DOCPROC Documentation/DocBook/kernel-api.sgml" because of these errors: Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): canno= t understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB ' Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): canno= t understand prototype: 'const char *global_mode_option; ' This patch fixes htmldocs build failure on include/linux/skbuff.h; it does not change any code. I think this patch should be merged before the 2.6.11 release. Signed-off-by: Sergey Vlasov --- linux-2.6.11-rc4-bk2/include/linux/skbuff.h.doc-build 2005-02-14 20:12:= 37 +0300 +++ linux-2.6.11-rc4-bk2/include/linux/skbuff.h 2005-02-14 22:46:20 +0300 @@ -921,6 +921,7 @@ static inline void __skb_queue_purge(str kfree_skb(skb); } =20 +#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB /** * __dev_alloc_skb - allocate an skbuff for sending * @length: length to allocate @@ -933,7 +934,6 @@ static inline void __skb_queue_purge(str * * %NULL is returned in there is no free memory. */ -#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB static inline struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask) { --=20 Sergey Vlasov --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCEQNRW82GfkQfsqIRAkzeAJ97rnrbnsS4vJ1qUXeEhAMErJodcQCfcyq1 pdxxXzgTsG3b/BLpkL4SwBs= =RSnR -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From rich@phekda.gotadsl.co.uk Mon Feb 14 12:34:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 12:35:02 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EKYtXn023168 for ; Mon, 14 Feb 2005 12:34:56 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-115-178.dyn.gotadsl.co.uk [82.133.115.178]) by smtp.nildram.co.uk (Postfix) with ESMTP id D23C52BE9C0; Mon, 14 Feb 2005 20:34:51 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 3316E318; Mon, 14 Feb 2005 20:36:45 +0000 (GMT) Message-ID: <42110BC7.7090700@phekda.gotadsl.co.uk> Date: Mon, 14 Feb 2005 20:36:23 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> <20050205204135.GA13986@electric-eye.fr.zoreil.com> <420944AB.5090501@phekda.gotadsl.co.uk> <20050212000732.GC8792@electric-eye.fr.zoreil.com> In-Reply-To: <20050212000732.GC8792@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 770 Lines: 33 Hello. Francois Romieu wrote: > Richard Dawe : > [...] > >>I find that the "ip link set dev eth0 down" command hangs, consuming >>most of the CPU time (~99%). Note that I issued the "network" commands >>with about a second's delay between each command. > > > @#$*%! > > Patch against 2.6.11-rc3: > http://www.fr.zoreil.com/people/francois/misc/20050211-2.6.11-rc3-r8169-test.patch > > Better ? [snip] Much better! That withstands: while true; /etc/init.d/network restart; done with both DHCP and statically-assigned IP addresses. I haven't seen any hangs. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From SRS0+9030dc47798e09726bfb+540+infradead.org+hch@pentafluge.srs.infradead.org Mon Feb 14 13:07:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 13:07:30 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EL7PKx025374 for ; Mon, 14 Feb 2005 13:07:26 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D0nRA-0002fX-4J; Mon, 14 Feb 2005 21:07:20 +0000 Date: Mon, 14 Feb 2005 21:07:20 +0000 From: Christoph Hellwig To: Amit Gud Cc: jgarzik@pobox.com, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org, gud@eth.net Subject: Re: [PATCH 9/18] drivers/net/ remove pci_find_{device, subsys} Message-ID: <20050214210720.GA10196@infradead.org> References: <200502141125.25185.amitg@calsoftinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502141125.25185.amitg@calsoftinc.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 5604 Lines: 128 > > diff -uprN orig/drivers/net/e1000/e1000_main.c linux-2.6.11-rc3/drivers/net/e1000/e1000_main.c > --- orig/drivers/net/e1000/e1000_main.c 2005-02-11 15:19:48.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/e1000/e1000_main.c 2005-02-14 02:02:48.000000000 +0530 > @@ -2792,7 +2792,7 @@ e1000_notify_reboot(struct notifier_bloc > case SYS_DOWN: > case SYS_HALT: > case SYS_POWER_OFF: > - while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { > + while((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { > if(pci_dev_driver(pdev) == &e1000_driver) > e1000_suspend(pdev, 3); Wrong. The driver should implement ->shutdown instead. > diff -uprN orig/drivers/net/fc/iph5526.c linux-2.6.11-rc3/drivers/net/fc/iph5526.c > --- orig/drivers/net/fc/iph5526.c 2004-10-19 03:23:43.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/fc/iph5526.c 2005-02-14 02:02:55.000000000 +0530 > @@ -3711,7 +3711,7 @@ int iph5526_detect(Scsi_Host_Template *t > fc[i] = NULL; > > for (i = 0; clone_list[i].vendor_id != 0; i++) > - while ((pdev = pci_find_device(clone_list[i].vendor_id, clone_list[i].device_id, pdev))) { > + while ((pdev = pci_get_device(clone_list[i].vendor_id, clone_list[i].device_id, pdev))) { > unsigned short pci_command; > if (pci_enable_device(pdev)) > continue; this driver will go away soon. > diff -uprN orig/drivers/net/gt96100eth.c linux-2.6.11-rc3/drivers/net/gt96100eth.c > --- orig/drivers/net/gt96100eth.c 2005-02-11 15:19:48.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/gt96100eth.c 2005-02-14 02:07:09.000000000 +0530 > @@ -615,9 +615,9 @@ static int gt96100_init_module(void) > /* > * Stupid probe because this really isn't a PCI device > */ > - if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, > + if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, > PCI_DEVICE_ID_MARVELL_GT96100, NULL)) && > - !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, > + !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, > PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) { > printk(KERN_ERR __FILE__ ": GT96100 not found!\n"); > return -ENODEV; should use pci_dev_present > diff -uprN orig/drivers/net/ixgb/ixgb_main.c linux-2.6.11-rc3/drivers/net/ixgb/ixgb_main.c > --- orig/drivers/net/ixgb/ixgb_main.c 2005-02-11 15:19:48.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/ixgb/ixgb_main.c 2005-02-14 02:07:17.000000000 +0530 > @@ -2087,7 +2087,7 @@ ixgb_notify_reboot(struct notifier_block > case SYS_DOWN: > case SYS_HALT: > case SYS_POWER_OFF: > - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { > + while ((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { > if (pci_dev_driver(pdev) == &ixgb_driver) > ixgb_suspend(pdev, 3); > } should implement ->shutdown > diff -uprN orig/drivers/net/sunhme.c linux-2.6.11-rc3/drivers/net/sunhme.c > --- orig/drivers/net/sunhme.c 2005-02-11 15:19:50.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/sunhme.c 2005-02-14 02:07:29.000000000 +0530 > @@ -3312,7 +3312,7 @@ static int __init happy_meal_pci_probe(v > struct pci_dev *pdev = NULL; > int cards = 0; > > - while ((pdev = pci_find_device(PCI_VENDOR_ID_SUN, > + while ((pdev = pci_get_device(PCI_VENDOR_ID_SUN, > PCI_DEVICE_ID_SUN_HAPPYMEAL, pdev)) != NULL) { > if (pci_enable_device(pdev)) > continue; should switch to proper hotplug-style probing. > diff -uprN orig/drivers/net/tg3.c linux-2.6.11-rc3/drivers/net/tg3.c > --- orig/drivers/net/tg3.c 2005-02-11 15:19:50.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/tg3.c 2005-02-14 02:07:54.000000000 +0530 > @@ -7825,15 +7825,15 @@ static int __devinit tg3_get_invariants( > * every mailbox register write to force the writes to be > * posted to the chip in order. > */ > - if (pci_find_device(PCI_VENDOR_ID_INTEL, > + if (pci_get_device(PCI_VENDOR_ID_INTEL, > PCI_DEVICE_ID_INTEL_82801AA_8, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > + pci_get_device(PCI_VENDOR_ID_INTEL, > PCI_DEVICE_ID_INTEL_82801AB_8, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > + pci_get_device(PCI_VENDOR_ID_INTEL, > PCI_DEVICE_ID_INTEL_82801BA_11, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > + pci_get_device(PCI_VENDOR_ID_INTEL, > PCI_DEVICE_ID_INTEL_82801BA_6, NULL) || > - pci_find_device(PCI_VENDOR_ID_AMD, > + pci_get_device(PCI_VENDOR_ID_AMD, > PCI_DEVICE_ID_AMD_FE_GATE_700C, NULL)) > tp->tg3_flags |= TG3_FLAG_MBOX_WRITE_REORDER; should use pci_dev_present. > diff -uprN orig/drivers/net/wan/sdladrv.c linux-2.6.11-rc3/drivers/net/wan/sdladrv.c > --- orig/drivers/net/wan/sdladrv.c 2004-10-19 03:23:43.000000000 +0530 > +++ linux-2.6.11-rc3/drivers/net/wan/sdladrv.c 2005-02-14 02:08:15.000000000 +0530 > @@ -2032,7 +2032,7 @@ static int find_s514_adapter(sdlahw_t* h > > slot_no = hw->S514_slot_no; > > - while ((pci_dev = pci_find_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) > + while ((pci_dev = pci_get_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) > != NULL) { > > pci_read_config_word(pci_dev, PCI_SUBSYS_VENDOR_WORD, > @@ -2245,7 +2245,7 @@ static int pci_probe(sdlahw_t *hw) > > slot_no = 0; > > - while ((pci_dev = pci_find_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) > + while ((pci_dev = pci_get_device(V3_VENDOR_ID, V3_DEVICE_ID, pci_dev)) > != NULL) { > > pci_read_config_word(pci_dev, PCI_SUBSYS_VENDOR_WORD, > should use proper hotplug-style probing From herbert@gondor.apana.org.au Mon Feb 14 14:12:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:12:49 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMCgPx003694 for ; Mon, 14 Feb 2005 14:12:43 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D0oRv-0000Cq-00; Tue, 15 Feb 2005 09:12:11 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D0oRk-0004o8-00; Tue, 15 Feb 2005 09:12:00 +1100 Date: Tue, 15 Feb 2005 09:12:00 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [2/4] [IPSEC] Add xfrm_state_mtu Message-ID: <20050214221200.GA18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20050214221006.GA18415@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2105 Lines: 76 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch introduces the function xfrm_state_mtu which calculates the MTU under a specific SA. This function can be simplified once we get rid all other uses of get_max_size as we can move the calculation into the invidual SA type. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-2 ===== include/net/xfrm.h 1.75 vs edited ===== --- 1.75/include/net/xfrm.h 2005-02-14 14:02:13 +11:00 +++ edited/include/net/xfrm.h 2005-02-14 14:11:38 +11:00 @@ -807,6 +807,7 @@ extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); extern int xfrm_state_check(struct xfrm_state *x, struct sk_buff *skb); +extern int xfrm_state_mtu(struct xfrm_state *x, int mtu); extern int xfrm4_rcv(struct sk_buff *skb); extern int xfrm4_output(struct sk_buff *skb); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); ===== net/xfrm/xfrm_state.c 1.54 vs edited ===== --- 1.54/net/xfrm/xfrm_state.c 2005-02-09 11:17:47 +11:00 +++ edited/net/xfrm/xfrm_state.c 2005-02-14 14:06:17 +11:00 @@ -966,6 +966,36 @@ } EXPORT_SYMBOL(xfrm_state_delete_tunnel); +int xfrm_state_mtu(struct xfrm_state *x, int mtu) +{ + int res = mtu; + + res -= x->props.header_len; + + for (;;) { + int m = res; + + if (m < 68) + return 68; + + spin_lock_bh(&x->lock); + if (x->km.state == XFRM_STATE_VALID && + x->type && x->type->get_max_size) + m = x->type->get_max_size(x, m); + else + m += x->props.header_len; + spin_unlock_bh(&x->lock); + + if (m <= mtu) + break; + res -= (m - mtu); + } + + return res; +} + +EXPORT_SYMBOL(xfrm_state_mtu); + void __init xfrm_state_init(void) { int i; --x+6KMIRAuhnl3hBn-- From herbert@gondor.apana.org.au Mon Feb 14 14:12:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:12:38 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMCSte003673 for ; Mon, 14 Feb 2005 14:12:29 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D0oQg-0000Ae-00; Tue, 15 Feb 2005 09:10:54 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D0oPu-0004nZ-00; Tue, 15 Feb 2005 09:10:06 +1100 Date: Tue, 15 Feb 2005 09:10:06 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [1/4] [IPSEC] Merge xfrm[46]_bundle/stale_bundle Message-ID: <20050214221006.GA18415@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5026 Lines: 174 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This series of patches adds MTU tracking in each xfrm_dst. This patch merges xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle so that later additions for MTU calculation only need to be done once. Signed-off-by: Herbert Xu BTW, the previous version of this patch contained a critical error in stale_bundle. So please disregard that one. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-1 diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2005-02-14 14:13:05 +11:00 +++ b/include/net/xfrm.h 2005-02-14 14:13:05 +11:00 @@ -857,6 +857,7 @@ extern void xfrm_policy_flush(void); extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern int xfrm_flush_bundles(void); +extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family); extern wait_queue_head_t km_waitq; extern int km_new_mapping(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/ipv4/xfrm4_policy.c 2005-02-14 14:13:05 +11:00 @@ -22,26 +22,6 @@ return __ip_route_output_key((struct rtable**)dst, fl); } -/* Check that the bundle accepts the flow and its components are - * still valid. - */ - -static int __xfrm4_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl) -{ - do { - if (xdst->u.dst.ops != &xfrm4_dst_ops) - return 1; - - if (!xfrm_selector_match(&xdst->u.dst.xfrm->sel, fl, AF_INET)) - return 0; - if (xdst->u.dst.xfrm->km.state != XFRM_STATE_VALID || - xdst->u.dst.path->obsolete > 0) - return 0; - xdst = (struct xfrm_dst*)xdst->u.dst.child; - } while (xdst); - return 0; -} - static struct dst_entry * __xfrm4_find_bundle(struct flowi *fl, struct xfrm_policy *policy) { @@ -53,7 +33,7 @@ if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && - __xfrm4_bundle_ok(xdst, fl)) { + xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; } diff -Nru a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c --- a/net/ipv6/xfrm6_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/ipv6/xfrm6_policy.c 2005-02-14 14:13:05 +11:00 @@ -31,26 +31,6 @@ return err; } -/* Check that the bundle accepts the flow and its components are - * still valid. - */ - -static int __xfrm6_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl) -{ - do { - if (xdst->u.dst.ops != &xfrm6_dst_ops) - return 1; - - if (!xfrm_selector_match(&xdst->u.dst.xfrm->sel, fl, AF_INET6)) - return 0; - if (xdst->u.dst.xfrm->km.state != XFRM_STATE_VALID || - xdst->u.dst.path->obsolete > 0) - return 0; - xdst = (struct xfrm_dst*)xdst->u.dst.child; - } while (xdst); - return 0; -} - static struct dst_entry * __xfrm6_find_bundle(struct flowi *fl, struct xfrm_policy *policy) { @@ -70,7 +50,7 @@ xdst->u.rt6.rt6i_src.plen); if (ipv6_addr_equal(&xdst->u.rt6.rt6i_dst.addr, &fl_dst_prefix) && ipv6_addr_equal(&xdst->u.rt6.rt6i_src.addr, &fl_src_prefix) && - __xfrm6_bundle_ok(xdst, fl)) { + xfrm_bundle_ok(xdst, fl, AF_INET6)) { dst_clone(dst); break; } diff -Nru a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c --- a/net/xfrm/xfrm_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/xfrm/xfrm_policy.c 2005-02-14 14:13:05 +11:00 @@ -1021,18 +1021,7 @@ static int stale_bundle(struct dst_entry *dst) { - struct dst_entry *child = dst; - - while (child) { - if (child->obsolete > 0 || - (child->dev && !netif_running(child->dev)) || - (child->xfrm && child->xfrm->km.state != XFRM_STATE_VALID)) { - return 1; - } - child = child->child; - } - - return 0; + return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC); } static void xfrm_dst_destroy(struct dst_entry *dst) @@ -1108,6 +1097,31 @@ return 0; } +/* Check that the bundle accepts the flow and its components are + * still valid. + */ + +int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family) +{ + struct dst_entry *dst = &xdst->u.dst; + + if (dst->path->obsolete > 0 || + (dst->dev && !netif_running(dst->dev))) + return 0; + + do { + if (fl && !xfrm_selector_match(&dst->xfrm->sel, fl, family)) + return 0; + if (dst->xfrm->km.state != XFRM_STATE_VALID) + return 0; + dst = dst->child; + } while (dst->xfrm); + + return 1; +} + +EXPORT_SYMBOL(xfrm_bundle_ok); + /* Well... that's _TASK_. We need to scan through transformation * list and figure out what mss tcp should generate in order to * final datagram fit to mtu. Mama mia... :-) --a8Wt8u1KmwUX3Y2C-- From herbert@gondor.apana.org.au Mon Feb 14 14:15:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:15:15 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMF8v3004676 for ; Mon, 14 Feb 2005 14:15:09 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D0oUJ-0000EH-00; Tue, 15 Feb 2005 09:14:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D0oUD-0004oW-00; Tue, 15 Feb 2005 09:14:33 +1100 Date: Tue, 15 Feb 2005 09:14:33 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [3/4] [IPSEC] Add route element to xfrm_dst Message-ID: <20050214221433.GB18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20050214221200.GA18465@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 6666 Lines: 258 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch adds a pointer to the route corresponding to the specific flow over the SA of an xfrm_dst that's being used. It also sets the next pointer of each xfrm_dst to the one above it. This allows to traverse the list upwards from the bottom. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-3 ===== include/net/xfrm.h 1.76 vs edited ===== --- 1.76/include/net/xfrm.h 2005-02-14 14:14:25 +11:00 +++ edited/include/net/xfrm.h 2005-02-14 14:24:04 +11:00 @@ -511,6 +511,7 @@ struct rtable rt; struct rt6_info rt6; } u; + struct dst_entry *route; }; /* Decapsulation state, used by the input to store data during ===== net/ipv4/xfrm4_policy.c 1.14 vs edited ===== --- 1.14/net/ipv4/xfrm4_policy.c 2005-02-14 14:02:13 +11:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-02-14 14:29:35 +11:00 @@ -55,18 +55,29 @@ struct rtable *rt = rt0; u32 remote = fl->fl4_dst; u32 local = fl->fl4_src; + struct flowi fl_tunnel = { + .nl_u = { + .ip4_u = { + .saddr = local, + .daddr = remote + } + } + }; int i; int err; int header_len = 0; int trailer_len = 0; dst = dst_prev = NULL; + dst_hold(&rt->u.dst); for (i = 0; i < nx; i++) { struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); + struct xfrm_dst *xdst; if (unlikely(dst1 == NULL)) { err = -ENOBUFS; + dst_release(&rt->u.dst); goto error; } @@ -77,6 +88,11 @@ dst1->flags |= DST_NOHASH; dst_clone(dst1); } + + xdst = (struct xfrm_dst *)dst1; + xdst->route = &rt->u.dst; + + dst1->next = dst_prev; dst_prev = dst1; if (xfrm[i]->props.mode) { remote = xfrm[i]->id.daddr.a4; @@ -84,23 +100,27 @@ } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; - } - if (remote != fl->fl4_dst) { - struct flowi fl_tunnel = { .nl_u = { .ip4_u = - { .daddr = remote, - .saddr = local } - } - }; - err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); - if (err) - goto error; - } else { - dst_hold(&rt->u.dst); + if (remote != fl_tunnel.fl4_dst) { + fl_tunnel.fl4_src = local; + fl_tunnel.fl4_dst = remote; + err = xfrm_dst_lookup((struct xfrm_dst **)&rt, + &fl_tunnel, AF_INET); + if (err) + goto error; + } else + dst_hold(&rt->u.dst); } + dst_prev->child = &rt->u.dst; + dst->path = &rt->u.dst; + + *dst_p = dst; + dst = dst_prev; + + dst_prev = *dst_p; i = 0; - for (dst_prev = dst; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { + for (; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { struct xfrm_dst *x = (struct xfrm_dst*)dst_prev; x->u.rt.fl = *fl; @@ -114,7 +134,6 @@ dst_prev->header_len = header_len; dst_prev->trailer_len = trailer_len; memcpy(&dst_prev->metrics, &rt->u.dst.metrics, sizeof(dst_prev->metrics)); - dst_prev->path = &rt->u.dst; /* Copy neighbout for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); @@ -134,7 +153,6 @@ header_len -= x->u.dst.xfrm->props.header_len; trailer_len -= x->u.dst.xfrm->props.trailer_len; } - *dst_p = dst; return 0; error: ===== net/ipv6/xfrm6_policy.c 1.25 vs edited ===== --- 1.25/net/ipv6/xfrm6_policy.c 2005-02-14 14:02:13 +11:00 +++ edited/net/ipv6/xfrm6_policy.c 2005-02-14 14:50:04 +11:00 @@ -72,18 +72,29 @@ struct rt6_info *rt = rt0; struct in6_addr *remote = &fl->fl6_dst; struct in6_addr *local = &fl->fl6_src; + struct flowi fl_tunnel = { + .nl_u = { + .ip6_u = { + .saddr = *local, + .daddr = *remote + } + } + }; int i; int err = 0; int header_len = 0; int trailer_len = 0; dst = dst_prev = NULL; + dst_hold(&rt->u.dst); for (i = 0; i < nx; i++) { struct dst_entry *dst1 = dst_alloc(&xfrm6_dst_ops); + struct xfrm_dst *xdst; if (unlikely(dst1 == NULL)) { err = -ENOBUFS; + dst_release(&rt->u.dst); goto error; } @@ -94,6 +105,11 @@ dst1->flags |= DST_NOHASH; dst_clone(dst1); } + + xdst = (struct xfrm_dst *)dst1; + xdst->route = &rt->u.dst; + + dst1->next = dst_prev; dst_prev = dst1; if (xfrm[i]->props.mode) { remote = (struct in6_addr*)&xfrm[i]->id.daddr; @@ -101,25 +117,27 @@ } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; - } - - if (!ipv6_addr_equal(remote, &fl->fl6_dst)) { - struct flowi fl_tunnel; - memset(&fl_tunnel, 0, sizeof(fl_tunnel)); - ipv6_addr_copy(&fl_tunnel.fl6_dst, remote); - ipv6_addr_copy(&fl_tunnel.fl6_src, local); - - err = xfrm_dst_lookup((struct xfrm_dst **) &rt, - &fl_tunnel, AF_INET6); - if (err) - goto error; - } else { - dst_hold(&rt->u.dst); + if (!ipv6_addr_equal(remote, &fl_tunnel.fl6_dst)) { + ipv6_addr_copy(&fl_tunnel.fl6_dst, remote); + ipv6_addr_copy(&fl_tunnel.fl6_src, local); + err = xfrm_dst_lookup((struct xfrm_dst **) &rt, + &fl_tunnel, AF_INET6); + if (err) + goto error; + } else + dst_hold(&rt->u.dst); } + dst_prev->child = &rt->u.dst; + dst->path = &rt->u.dst; + + *dst_p = dst; + dst = dst_prev; + + dst_prev = *dst_p; i = 0; - for (dst_prev = dst; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { + for (; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { struct xfrm_dst *x = (struct xfrm_dst*)dst_prev; dst_prev->xfrm = xfrm[i++]; @@ -132,7 +150,6 @@ dst_prev->header_len = header_len; dst_prev->trailer_len = trailer_len; memcpy(&dst_prev->metrics, &rt->u.dst.metrics, sizeof(dst_prev->metrics)); - dst_prev->path = &rt->u.dst; /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); @@ -150,7 +167,6 @@ header_len -= x->u.dst.xfrm->props.header_len; trailer_len -= x->u.dst.xfrm->props.trailer_len; } - *dst_p = dst; return 0; error: ===== net/xfrm/xfrm_policy.c 1.65 vs edited ===== --- 1.65/net/xfrm/xfrm_policy.c 2005-02-14 14:02:13 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-14 14:39:52 +11:00 @@ -1026,6 +1026,11 @@ static void xfrm_dst_destroy(struct dst_entry *dst) { + struct xfrm_dst *xdst = (struct xfrm_dst *)dst; + + if (xdst->route) + dst_release(xdst->route); + if (!dst->xfrm) return; xfrm_state_put(dst->xfrm); --neYutvxvOLaeuPCA-- From herbert@gondor.apana.org.au Mon Feb 14 14:17:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:17:15 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMH9RH005204 for ; Mon, 14 Feb 2005 14:17:10 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D0oVz-0000FF-00; Tue, 15 Feb 2005 09:16:23 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D0oVj-0004p5-00; Tue, 15 Feb 2005 09:16:07 +1100 Date: Tue, 15 Feb 2005 09:16:07 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [4/4] [IPSEC] Store MTU at each xfrm_dst Message-ID: <20050214221607.GC18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: <20050214221433.GB18465@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4257 Lines: 163 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Finally this is the patch that sets the MTU values of each xfrm_dst and keeps it up-to-date. Signed-off-by: Herbert Xu To recap, at this point we've obtained accurate MTU values at each xfrm_dst. The next step would be to start using it as dst_pmtu(xfrm_dst). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-4 ===== include/net/xfrm.h 1.77 vs edited ===== --- 1.77/include/net/xfrm.h 2005-02-14 14:51:26 +11:00 +++ edited/include/net/xfrm.h 2005-02-14 14:23:51 +11:00 @@ -512,6 +512,8 @@ struct rt6_info rt6; } u; struct dst_entry *route; + u32 route_mtu_cached; + u32 child_mtu_cached; }; /* Decapsulation state, used by the input to store data during @@ -860,6 +862,7 @@ extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern int xfrm_flush_bundles(void); extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family); +extern void xfrm_init_pmtu(struct dst_entry *dst); extern wait_queue_head_t km_waitq; extern int km_new_mapping(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); ===== net/ipv4/xfrm4_policy.c 1.15 vs edited ===== --- 1.15/net/ipv4/xfrm4_policy.c 2005-02-14 14:51:26 +11:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-02-14 14:53:06 +11:00 @@ -153,6 +153,8 @@ header_len -= x->u.dst.xfrm->props.header_len; trailer_len -= x->u.dst.xfrm->props.trailer_len; } + + xfrm_init_pmtu(dst); return 0; error: ===== net/ipv6/xfrm6_policy.c 1.26 vs edited ===== --- 1.26/net/ipv6/xfrm6_policy.c 2005-02-14 14:51:26 +11:00 +++ edited/net/ipv6/xfrm6_policy.c 2005-02-14 14:53:25 +11:00 @@ -167,6 +167,8 @@ header_len -= x->u.dst.xfrm->props.header_len; trailer_len -= x->u.dst.xfrm->props.trailer_len; } + + xfrm_init_pmtu(dst); return 0; error: ===== net/xfrm/xfrm_policy.c 1.66 vs edited ===== --- 1.66/net/xfrm/xfrm_policy.c 2005-02-14 14:51:26 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-14 21:29:56 +11:00 @@ -1102,25 +1102,86 @@ return 0; } +void xfrm_init_pmtu(struct dst_entry *dst) +{ + do { + struct xfrm_dst *xdst = (struct xfrm_dst *)dst; + u32 pmtu, route_mtu_cached; + + pmtu = dst_pmtu(dst->child); + xdst->child_mtu_cached = pmtu; + + pmtu = xfrm_state_mtu(dst->xfrm, pmtu); + + route_mtu_cached = dst_pmtu(xdst->route); + xdst->route_mtu_cached = route_mtu_cached; + + if (pmtu > route_mtu_cached) + pmtu = route_mtu_cached; + + dst->metrics[RTAX_MTU-1] = pmtu; + } while ((dst = dst->next)); +} + +EXPORT_SYMBOL(xfrm_init_pmtu); + /* Check that the bundle accepts the flow and its components are * still valid. */ -int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family) +int xfrm_bundle_ok(struct xfrm_dst *first, struct flowi *fl, int family) { - struct dst_entry *dst = &xdst->u.dst; + struct dst_entry *dst = &first->u.dst; + struct xfrm_dst *last; + u32 mtu; if (dst->path->obsolete > 0 || (dst->dev && !netif_running(dst->dev))) return 0; + last = NULL; + do { + struct xfrm_dst *xdst = (struct xfrm_dst *)dst; + if (fl && !xfrm_selector_match(&dst->xfrm->sel, fl, family)) return 0; if (dst->xfrm->km.state != XFRM_STATE_VALID) return 0; + + mtu = dst_pmtu(dst->child); + if (xdst->child_mtu_cached != mtu) { + last = xdst; + xdst->child_mtu_cached = mtu; + } + + mtu = dst_pmtu(xdst->route); + if (xdst->child_mtu_cached != mtu) { + last = xdst; + xdst->route_mtu_cached = mtu; + } + dst = dst->child; } while (dst->xfrm); + + if (likely(!last)) + return 1; + + mtu = last->child_mtu_cached; + for (;;) { + dst = &last->u.dst; + + mtu = xfrm_state_mtu(dst->xfrm, mtu); + if (mtu > last->route_mtu_cached) + mtu = last->route_mtu_cached; + dst->metrics[RTAX_MTU-1] = mtu; + + if (last == first) + break; + + last = last->u.next; + last->child_mtu_cached = mtu; + } return 1; } --/e2eDi0V/xtL+Mc8-- From davem@davemloft.net Mon Feb 14 14:38:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:39:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMcvxR006255 for ; Mon, 14 Feb 2005 14:38:58 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D0opZ-0001Qm-00; Mon, 14 Feb 2005 14:36:37 -0800 Date: Mon, 14 Feb 2005 14:36:36 -0800 From: "David S. Miller" To: Sergey Vlasov Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 1/2] Fix documentation build failure Message-Id: <20050214143636.3c073df6.davem@davemloft.net> In-Reply-To: <20050214200017.GA29201@sirius.home> References: <20050214200017.GA29201@sirius.home> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 568 Lines: 11 On Mon, 14 Feb 2005 23:00:17 +0300 Sergey Vlasov wrote: > In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs) > fails on "DOCPROC Documentation/DocBook/kernel-api.sgml" because of > these errors: > > Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): cannot understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB ' > Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): cannot understand prototype: 'const char *global_mode_option; ' I think the htmldoc parser should be fixed instead. From Gary.Spiess@Intermec.com Mon Feb 14 14:51:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 14:51:31 -0800 (PST) Received: from spiess2.norand.com (spiess2.norand.com [136.179.85.112]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMpLDK007071 for ; Mon, 14 Feb 2005 14:51:22 -0800 Received: from [136.179.85.111] (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id j1EMxUTh009690; Mon, 14 Feb 2005 16:59:30 -0600 Message-ID: <42112BDA.3050200@Intermec.com> Date: Mon, 14 Feb 2005 16:53:14 -0600 From: Gary Spiess User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: thockin@hockin.org Subject: Re: [PATCH] natsemi long cable fix References: <421129DE.4070101@Intermec.com> In-Reply-To: <421129DE.4070101@Intermec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 1623 Lines: 24 When used with Revision D of the DP83815, the "Recommended Registers Configuration" from page 78 of the DP83815 data sheet is not entirely compatible with the driver's "short cable patch". When the DSPCFG register is written with the value suggested in the document, then do_cable_magic() determines that all cables attached to the DP83815D are 'short', regardless of actual length. Short cables (< 30m) cause do_cable_magic to enable additional attenuation to reduce CRC and idle errors. If the extra attenuation is unintentionally enabled for long cables (> 100m?), they will not operate properly. The National Semiconductor driver, 'dp83815.c' from http://www.national.com/appinfo/networks/files/linux_2_4.tar.gz was used as a basis for this modification. --- linux-2.6.10.orig/drivers/net/natsemi.c 2004-12-24 15:33:50.000000000 -0600 +++ linux-2.6.10/drivers/net/natsemi.c 2005-02-14 16:45:46.000000000 -0600 @@ -441,6 +441,7 @@ #define DSPCFG_VAL 0x5040 #define SDCFG_VAL 0x008c /* set voltage thresholds for Signal Detect */ #define DSPCFG_LOCK 0x20 /* coefficient lock bit in DSPCFG */ +#define DSPCFG_COEF 0x1000 /* see coefficient (in TSTDAT) bit in DSPCFG */ #define TSTDAT_FIXED 0xe8 /* magic number for bad coefficients */ /* misc PCI space registers */ @@ -1243,7 +1244,8 @@ writew(1, ioaddr + PGSEL); writew(PMDCSR_VAL, ioaddr + PMDCSR); writew(TSTDAT_VAL, ioaddr + TSTDAT); - np->dspcfg = DSPCFG_VAL; + np->dspcfg = (np->srr <= SRR_DP83815_C)? + DSPCFG_VAL : DSPCFG_COEF; writew(np->dspcfg, ioaddr + DSPCFG); writew(SDCFG_VAL, ioaddr + SDCFG); writew(0, ioaddr + PGSEL); From chrisw@osdl.org Mon Feb 14 16:12:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 16:12:24 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F0CCcV017891 for ; Mon, 14 Feb 2005 16:12:12 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1F0BXqi025741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Feb 2005 16:11:34 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1F0BWCC028226; Mon, 14 Feb 2005 16:11:32 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1F0BW5Y028225; Mon, 14 Feb 2005 16:11:32 -0800 Date: Mon, 14 Feb 2005 16:11:32 -0800 From: Chris Wright To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050215001132.GA27645@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420E334B.8060805@eurodev.net> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 36 * Pablo Neira (pablo@eurodev.net) wrote: > Chris Wright wrote: > >+static int audit_check_sender(struct sk_buff *skb) > >{ > >- int err = 0; > >+ struct nlmsghdr *nlh; > >+ u16 msg_type; > >+ int err = -EINVAL; > > > >+ if (skb->len < NLMSG_LENGTH(0)) > >+ goto out; > >+ > >+ nlh = (struct nlmsghdr *)skb->data; > >+ msg_type = nlh->nlmsg_type; > > You're introducing some kind of check for malformed packets here as > well, don't you think that such thing should be done by the receiver ? This has to be done to make the capability check meaningful, as it's different per msg type. Need to have a valid header to check msg type. > I also see another option which is passing as parameter such function > which check for capabilities/audit stuff to my netlink_process_skb > function, calling it before process_msg. But in that case, the packet > sent by a sender that doesn't has the right to was already enqueued. I > understand that this is exactly what you are trying to avoid. That's how it's done now. The purpose of this patch is to guarantee the check is done in the sender's context to avoid having to add values to the control buffer to support protocol specific data (such as loginuid in this case of audit). thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From chrisw@osdl.org Mon Feb 14 16:13:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 16:13:53 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F0DmWv018095 for ; Mon, 14 Feb 2005 16:13:49 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1F0DYqi025842 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Feb 2005 16:13:36 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1F0DYHX028318; Mon, 14 Feb 2005 16:13:34 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1F0DYUa028317; Mon, 14 Feb 2005 16:13:34 -0800 Date: Mon, 14 Feb 2005 16:13:34 -0800 From: Chris Wright To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050215001334.GB27645@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420E77FA.6080007@eurodev.net> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1311 Lines: 33 * Pablo Neira (pablo@eurodev.net) wrote: > Pablo Neira wrote: > > >I also see another option which is passing as parameter such function > >which check for capabilities/audit stuff to my netlink_process_skb > >function, calling it before process_msg. But in that case, the packet > >sent by a sender that doesn't has the right to was already enqueued. I > >understand that this is exactly what you are trying to avoid. > > > With your patch, a message from user space process that doesn't have the > capabilites follows this path: > > sys_sendmsg() -> netlink_sendmsg() -> netlink_unicast() -> > netlink_sendskb() = discarded here. > > Currently, it continues, for example in case of rtnetlink: > > ... -> netlink_sendskb() -> sk_data_ready(sk, len) -> rtnetlink_rcv() -> > rtnetlink_rcv_skb() -> rtnetlink_rcv_msg() = discarded here. > > Nowadays the message is enqueued but it's discarded later. So if I'm not > missing anything, I don't see the point of adding a new function to > check for capabilities/audit stuff just a bit before. The purpose is to guarantee that the checks are done in the sender's context to avoid having to cache values such as capabilities, SELinux SID, audit loginuid. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From chrisw@osdl.org Mon Feb 14 16:17:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 16:17:58 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F0Ho2Y018966 for ; Mon, 14 Feb 2005 16:17:50 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1F0Hdqi026065 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Feb 2005 16:17:40 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1F0HdTw028514; Mon, 14 Feb 2005 16:17:39 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1F0Hd5S028513; Mon, 14 Feb 2005 16:17:39 -0800 Date: Mon, 14 Feb 2005 16:17:38 -0800 From: Chris Wright To: Stephen Smalley Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, James Morris , "Serge E. Hallyn" Subject: Re: [RFC][PATCH 1/3] netlink check sender Message-ID: <20050215001738.GC27645@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1285 Lines: 37 * Stephen Smalley (sds@epoch.ncsc.mil) wrote: > On Sat, 2005-02-12 at 04:02, Chris Wright wrote: > > ===== net/netlink/af_netlink.c 1.69 vs edited ===== > > --- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00 > > +++ edited/net/netlink/af_netlink.c 2005-02-11 18:05:59 -08:00 > > int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) > > { > > struct netlink_opt *nlk; > > - int len = skb->len; > > - > > + int err, len = skb->len; > > + > > nlk = nlk_sk(sk); > > + > > + printk("%s: %s(%d) send_check %p\n", __FUNCTION__, current->comm, current->pid, nlk->check_sender); > > + if (nlk->check_sender) > > + if ((err = nlk->check_sender(skb))) { > > + netlink_detachskb(sk, skb); > > + return err; > > + } > > + > > printk() is a leftover from debugging, I assume. Heh, yeah, just leftover gargabe. > Why place the check_sender() call here vs. just replacing the existing > security_netlink_send() call in netlink_sendmsg() with this new call? That's fine, however it needs to be this late, to get the receiver looked up. I think the sk would change in _send hook, so for RFC, I just left them separate. Ideal would be complete consolidation. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From chrisw@osdl.org Mon Feb 14 16:22:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 16:22:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F0MAxW022927 for ; Mon, 14 Feb 2005 16:22:10 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1F0M2qi026311 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Feb 2005 16:22:03 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1F0M1gW028725; Mon, 14 Feb 2005 16:22:02 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1F0M1Sk028724; Mon, 14 Feb 2005 16:22:01 -0800 Date: Mon, 14 Feb 2005 16:22:01 -0800 From: Chris Wright To: Stephen Smalley Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, James Morris , "Serge E. Hallyn" Subject: Re: [RFC][PATCH 1/3] netlink check sender Message-ID: <20050215002201.GD27645@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <1108385999.15437.18.camel@moss-spartans.epoch.ncsc.mil> <1108386320.15437.22.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108386320.15437.22.camel@moss-spartans.epoch.ncsc.mil> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 755 Lines: 18 * Stephen Smalley (sds@tycho.nsa.gov) wrote: > On Mon, 2005-02-14 at 07:59, Stephen Smalley wrote: > > printk() is a leftover from debugging, I assume. > > Why place the check_sender() call here vs. just replacing the existing > > security_netlink_send() call in netlink_sendmsg() with this new call? > > Sorry, replacing security_netlink_send() would be bad (for SELinux > checking), but I'm not clear on why you don't put the check_sender() > call right after it in netlink_sendmsg() so that you ensure that you > have complete coverage (vs. unicast-specific). The receiver hasn't been looked up, so you don't have the nlk_sk()->check_sender handy yet. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From pablo@eurodev.net Mon Feb 14 18:29:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 18:29:39 -0800 (PST) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F2TR0w026932 for ; Mon, 14 Feb 2005 18:29:28 -0800 Received: from eurodev.net ([85.136.108.170]) by smtp08.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050215022915.FJTP4106.smtp08.retemail.es@eurodev.net>; Tue, 15 Feb 2005 03:29:15 +0100 Message-ID: <42115E7E.6050909@eurodev.net> Date: Tue, 15 Feb 2005 03:29:18 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> In-Reply-To: <20050215001334.GB27645@shell0.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------040206070606070909000306" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 6931 Lines: 248 This is a multi-part message in MIME format. --------------040206070606070909000306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Wright wrote: >>With your patch, a message from user space process that doesn't have the >>capabilites follows this path: >> >>sys_sendmsg() -> netlink_sendmsg() -> netlink_unicast() -> >>netlink_sendskb() = discarded here. >> >>Currently, it continues, for example in case of rtnetlink: >> >>... -> netlink_sendskb() -> sk_data_ready(sk, len) -> rtnetlink_rcv() -> >>rtnetlink_rcv_skb() -> rtnetlink_rcv_msg() = discarded here. >> >>Nowadays the message is enqueued but it's discarded later. So if I'm not >>missing anything, I don't see the point of adding a new function to >>check for capabilities/audit stuff just a bit before. >> >> > >The purpose is to guarantee that the checks are done in the sender's >context to avoid having to cache values such as capabilities, SELinux >SID, audit loginuid. > > Thanks for the explanation. I don't still like so much the new netlink_kernel_create_check function. I think that we could get more variations of netlink_kernel_create in future just to add another feature/checking. So I prefer new function (netlink_kernel_set_check) that set check_sender if it's needed once the netlink socket is created. I've modified your patches to use this function. Comments welcome. -- Pablo --------------040206070606070909000306 Content-Type: text/plain; name="01" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="01" ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-07 06:59:39 +01:00 +++ edited/include/linux/netlink.h 2005-02-15 02:35:36 +01:00 @@ -117,6 +117,7 @@ extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern inline void netlink_kernel_set_check(struct sock *sk, int (*check)(struct sk_buff *skb)); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 +++ edited/net/netlink/af_netlink.c 2005-02-15 02:35:49 +01:00 @@ -71,6 +71,7 @@ struct netlink_callback *cb; spinlock_t cb_lock; void (*data_ready)(struct sock *sk, int bytes); + int (*check_sender)(struct sk_buff *skb); }; #define nlk_sk(__sk) ((struct netlink_opt *)(__sk)->sk_protinfo) @@ -1063,6 +1064,12 @@ return sk; } +inline void netlink_kernel_set_check(struct sock *sk, + int (*check)(struct sk_buff *skb)) +{ + nlk_sk(sk)->check_sender = check; +} + void netlink_set_nonroot(int protocol, unsigned int flags) { if ((unsigned int)protocol < MAX_LINKS) @@ -1460,6 +1467,7 @@ EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); EXPORT_SYMBOL(netlink_kernel_create); +EXPORT_SYMBOL(netlink_kernel_set_check); EXPORT_SYMBOL(netlink_register_notifier); EXPORT_SYMBOL(netlink_set_err); EXPORT_SYMBOL(netlink_set_nonroot); --------------040206070606070909000306 Content-Type: text/plain; name="02" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="02" ===== kernel/audit.c 1.9 vs edited ===== --- 1.9/kernel/audit.c 2005-01-31 07:33:47 +01:00 +++ edited/kernel/audit.c 2005-02-15 02:17:22 +01:00 @@ -309,27 +309,36 @@ * Check for appropriate CAP_AUDIT_ capabilities on incoming audit * control messages. */ -static int audit_netlink_ok(kernel_cap_t eff_cap, u16 msg_type) +static int audit_check_sender(struct sk_buff *skb) { - int err = 0; + struct nlmsghdr *nlh; + u16 msg_type; + int err = -EINVAL; + if (skb->len < NLMSG_LENGTH(0)) + goto out; + + nlh = (struct nlmsghdr *)skb->data; + msg_type = nlh->nlmsg_type; + + err = 0; switch (msg_type) { case AUDIT_GET: case AUDIT_LIST: case AUDIT_SET: case AUDIT_ADD: case AUDIT_DEL: - if (!cap_raised(eff_cap, CAP_AUDIT_CONTROL)) + if (!capable(CAP_AUDIT_CONTROL)) err = -EPERM; break; case AUDIT_USER: - if (!cap_raised(eff_cap, CAP_AUDIT_WRITE)) + if (!capable(CAP_AUDIT_WRITE)) err = -EPERM; break; default: /* bad msg */ err = -EINVAL; } - +out: return err; } @@ -338,14 +347,10 @@ u32 uid, pid, seq; void *data; struct audit_status *status_get, status_set; - int err; + int err = 0; struct audit_buffer *ab; u16 msg_type = nlh->nlmsg_type; - err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type); - if (err) - return err; - pid = NETLINK_CREDS(skb)->pid; uid = NETLINK_CREDS(skb)->uid; seq = nlh->nlmsg_seq; @@ -554,6 +559,8 @@ audit_sock = netlink_kernel_create(NETLINK_AUDIT, audit_receive); if (!audit_sock) audit_panic("cannot initialize netlink socket"); + + netlink_kernel_set_check(audit_sock, audit_check_sender); audit_initialized = 1; audit_enabled = audit_default; --------------040206070606070909000306 Content-Type: text/plain; name="03" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="03" ===== net/core/rtnetlink.c 1.33 vs edited ===== --- 1.33/net/core/rtnetlink.c 2005-01-10 22:42:22 +01:00 +++ edited/net/core/rtnetlink.c 2005-02-15 02:28:37 +01:00 @@ -462,8 +462,32 @@ static struct rtattr **rta_buf; static int rtattr_max; -/* Process one rtnetlink message. */ +static int rtnetlink_check_sender(struct sk_buff *skb) +{ + struct nlmsghdr *nlh; + int kind; + int type; + + if (skb->len < NLMSG_LENGTH(0)) + return -EINVAL; + + nlh = (struct nlmsghdr *)skb->data; + type = nlh->nlmsg_type; + + /* Unknown message: reply with EINVAL */ + if (type > RTM_MAX) + return -EINVAL; + + type -= RTM_BASE; + kind = type&3; + if (kind != 2 && !capable(CAP_NET_ADMIN)) + return -EPERM; + + return 0; +} + +/* Process one rtnetlink message. */ static __inline__ int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, int *errp) { @@ -485,10 +509,6 @@ if (type < RTM_BASE) return 0; - /* Unknown message: reply with EINVAL */ - if (type > RTM_MAX) - goto err_inval; - type -= RTM_BASE; /* All the messages must have at least 1 byte length */ @@ -509,11 +529,6 @@ sz_idx = type>>2; kind = type&3; - if (kind != 2 && security_netlink_recv(skb)) { - *errp = -EPERM; - return -1; - } - if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) { u32 rlen; @@ -693,6 +708,7 @@ rtnl = netlink_kernel_create(NETLINK_ROUTE, rtnetlink_rcv); if (rtnl == NULL) panic("rtnetlink_init: cannot initialize rtnetlink\n"); + netlink_kernel_set_check(rtnl, rtnetlink_check_sender); netlink_set_nonroot(NETLINK_ROUTE, NL_NONROOT_RECV); register_netdevice_notifier(&rtnetlink_dev_notifier); rtnetlink_links[PF_UNSPEC] = link_rtnetlink_table; --------------040206070606070909000306-- From pablo@eurodev.net Mon Feb 14 18:36:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 18:37:01 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F2atB5027939 for ; Mon, 14 Feb 2005 18:36:56 -0800 Received: from eurodev.net ([85.136.108.170]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050215023644.PYUQ9125.smtp09.retemail.es@eurodev.net>; Tue, 15 Feb 2005 03:36:44 +0100 Message-ID: <42116042.6030205@eurodev.net> Date: Tue, 15 Feb 2005 03:36:50 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> In-Reply-To: <42115E7E.6050909@eurodev.net> Content-Type: multipart/mixed; boundary="------------070102060609050907020807" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 3781 Lines: 116 This is a multi-part message in MIME format. --------------070102060609050907020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pablo Neira wrote: > Chris Wright wrote: > >>> With your patch, a message from user space process that doesn't have >>> the capabilites follows this path: >>> >>> sys_sendmsg() -> netlink_sendmsg() -> netlink_unicast() -> >>> netlink_sendskb() = discarded here. >>> >>> Currently, it continues, for example in case of rtnetlink: >>> >>> ... -> netlink_sendskb() -> sk_data_ready(sk, len) -> >>> rtnetlink_rcv() -> rtnetlink_rcv_skb() -> rtnetlink_rcv_msg() = >>> discarded here. >>> >>> Nowadays the message is enqueued but it's discarded later. So if I'm >>> not missing anything, I don't see the point of adding a new function >>> to check for capabilities/audit stuff just a bit before. >>> >> >> >> The purpose is to guarantee that the checks are done in the sender's >> context to avoid having to cache values such as capabilities, SELinux >> SID, audit loginuid. >> >> > > Thanks for the explanation. I don't still like so much the new > netlink_kernel_create_check function. I think that we could get more > variations of netlink_kernel_create in future just to add another > feature/checking. So I prefer new function (netlink_kernel_set_check) > that set check_sender if it's needed once the netlink socket is > created. I've modified your patches to use this function. Sorry, I'm stupid. Wrong patch. -- Pablo --------------070102060609050907020807 Content-Type: text/x-patch; name="netlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink.patch" ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 +++ edited/net/netlink/af_netlink.c 2005-02-15 03:34:53 +01:00 @@ -71,6 +71,7 @@ struct netlink_callback *cb; spinlock_t cb_lock; void (*data_ready)(struct sock *sk, int bytes); + int (*check_sender)(struct sk_buff *skb); }; #define nlk_sk(__sk) ((struct netlink_opt *)(__sk)->sk_protinfo) @@ -636,9 +637,15 @@ int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) { struct netlink_opt *nlk; - int len = skb->len; + int err, len = skb->len; + nlk = nlk_sk(sk); + + if (nlk->check_sender) + if ((err = nlk->check_sender(skb))) { + netlink_detachskb(sk, skb); + return err; + } - nlk = nlk_sk(sk); #ifdef NL_EMULATE_DEV if (nlk->handler) { skb_orphan(skb); @@ -1063,6 +1070,12 @@ return sk; } +inline void netlink_kernel_set_check(struct sock *sk, + int (*check)(struct sk_buff *skb)) +{ + nlk_sk(sk)->check_sender = check; +} + void netlink_set_nonroot(int protocol, unsigned int flags) { if ((unsigned int)protocol < MAX_LINKS) @@ -1460,6 +1473,7 @@ EXPORT_SYMBOL(netlink_broadcast); EXPORT_SYMBOL(netlink_dump_start); EXPORT_SYMBOL(netlink_kernel_create); +EXPORT_SYMBOL(netlink_kernel_set_check); EXPORT_SYMBOL(netlink_register_notifier); EXPORT_SYMBOL(netlink_set_err); EXPORT_SYMBOL(netlink_set_nonroot); ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-07 06:59:39 +01:00 +++ edited/include/linux/netlink.h 2005-02-15 02:53:35 +01:00 @@ -117,6 +117,7 @@ extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern inline void netlink_kernel_set_check(struct sock *sk, int (*check)(struct sk_buff *skb)); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, --------------070102060609050907020807-- From chrisw@osdl.org Mon Feb 14 19:47:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 19:47:37 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F3lO5e029921 for ; Mon, 14 Feb 2005 19:47:24 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1F3l9qi002761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Feb 2005 19:47:11 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1F3l86m002236; Mon, 14 Feb 2005 19:47:08 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1F3l8rd002235; Mon, 14 Feb 2005 19:47:08 -0800 Date: Mon, 14 Feb 2005 19:47:08 -0800 From: Chris Wright To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050215034708.GG27645@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42115E7E.6050909@eurodev.net> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 891 Lines: 21 * Pablo Neira (pablo@eurodev.net) wrote: > Thanks for the explanation. I don't still like so much the new > netlink_kernel_create_check function. I think that we could get more > variations of netlink_kernel_create in future just to add another > feature/checking. So I prefer new function (netlink_kernel_set_check) I agree, had the same concern. I breifly considered an ops struct that could be passed in during registration so that it could grow a little easier. > that set check_sender if it's needed once the netlink socket is created. > I've modified your patches to use this function. Great, thanks. This is technically racy. It's possible (albeit small window) that something could be delivered before this is set. Using a callback struct during registration would fix this. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From Gary.Spiess@Intermec.com Mon Feb 14 20:33:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Feb 2005 20:33:45 -0800 (PST) Received: from spiess2.norand.com (spiess2.norand.com [136.179.85.112]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F4XZfC002165 for ; Mon, 14 Feb 2005 20:33:38 -0800 Received: from [136.179.85.111] (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id j1F4jETh015673; Mon, 14 Feb 2005 22:45:14 -0600 Message-ID: <42117C16.8010800@Intermec.com> Date: Mon, 14 Feb 2005 22:35:34 -0600 From: Gary Spiess User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jgarzik@pobox.com CC: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi: long cable, short cable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 2006 Lines: 43 Jeff, I just read your message of Feb 10th, 2005 regarding the cable problems of natsemi.c. My investigation started late last week. On Feb 14th, I got serious and nailed it down. I submitted a patch of my own without realizing there was other work in progress on the same issue. Please consider replacing the patch you didn't like with mine. What was happening with my DP83815D was that the TSTDAT value being read in the do_cable_magic function was near 0x1f, regardless of cable length. The code that fixes short cable problems actually works for short cables, but messes up long ones. The cable magic couldn't figure out the length of the cable and always applied the fix. I went looking for the history of this patch on the Internet and found a DP83815 Linux driver written and maintained by National Semiconductor. I was struck by the difference in the initialization sequences. natsemi.c always applies the sequence documented for the DP83815B. dp83815.c applies different sequences for chip revisions B, C, and D+. I used the D initialization for my D chip, and again watched the values being returned from TSTDAT in do_cable magic. A 1m cable returned something like 0xF8 and a 90m cable return something like 0xB8. Now the register was returning a value like it must have done with previous revisions of the chip. The magic is properly applied in the proper situation. Since there is no public documentation on these PHY manipulations, I minimized the 'fix' to the setting of the DSPCFG register. If I only turn on the bit that makes the coefficient readable, do_cable_magic now appears to have the right information to decide the cable length automatically. Ain't life great? Gary in reply to http://oss.sgi.com/archives/netdev/2005-02/msg00396.html -- oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 From mika.penttila@kolumbus.fi Tue Feb 15 00:06:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 00:06:50 -0800 (PST) Received: from mail-gw.turkuamk.fi (mail-gw.turkuamk.fi [195.148.208.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F86f8O008059 for ; Tue, 15 Feb 2005 00:06:42 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 421D5F3168; Tue, 15 Feb 2005 10:06:33 +0200 (EET) Received: from mail-gw.turkuamk.fi ([127.0.0.1]) by localhost (mail-gw.turkuamk.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32119-01; Tue, 15 Feb 2005 10:06:33 +0200 (EET) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 1B134F3151; Tue, 15 Feb 2005 10:06:33 +0200 (EET) Received: from [192.168.0.34] ([193.166.136.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2005021510082407:11181 ; Tue, 15 Feb 2005 10:08:24 +0200 Message-ID: <4211AE5E.2010506@kolumbus.fi> Date: Tue, 15 Feb 2005 10:10:06 +0200 From: =?ISO-8859-15?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> In-Reply-To: <20050214221433.GB18465@gondor.apana.org.au> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 15.02.2005 10:08:24, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 15.02.2005 10:08:54, Serialize complete at 15.02.2005 10:08:54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at tekniikka.turkuamk.fi X-Virus-Status: Clean X-archive-position: 1639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 1338 Lines: 52 Herbert Xu wrote: >This patch adds a pointer to the route corresponding to the specific >flow over the SA of an xfrm_dst that's being used. > >It also sets the next pointer of each xfrm_dst to the one above it. >This allows to traverse the list upwards from the bottom. > >Signed-off-by: Herbert Xu > >Cheers, > > >------------------------------------------------------------------------ > /* Decapsulation state, used by the input to store data during >===== net/ipv4/xfrm4_policy.c 1.14 vs edited ===== >--- 1.14/net/ipv4/xfrm4_policy.c 2005-02-14 14:02:13 +11:00 >+++ edited/net/ipv4/xfrm4_policy.c 2005-02-14 14:29:35 +11:00 >@@ -55,18 +55,29 @@ > struct rtable *rt = rt0; > u32 remote = fl->fl4_dst; > u32 local = fl->fl4_src; >+ struct flowi fl_tunnel = { >+ .nl_u = { >+ .ip4_u = { >+ .saddr = local, >+ .daddr = remote >+ } >+ } >+ }; > int i; > int err; > int header_len = 0; > int trailer_len = 0; > > dst = dst_prev = NULL; > > Shouldn't this pinning happen inside the loop for eaxh xdst, to be balanced with the dst_release(xdst->route) in xfrm_dst_destroy ? >+ dst_hold(&rt->u.dst); > > for (i = 0; i < nx; i++) { > struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); >+ struct xfrm_dst *xdst; > > if (unlikely(dst1 == NULL)) { > err = -ENOBUFS; > > From wensong@linux-vs.org Tue Feb 15 00:05:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 00:05:28 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F85Geh007797 for ; Tue, 15 Feb 2005 00:05:18 -0800 Received: from penguin.linux-vs.org ([220.192.153.184]) by lb1.ctrip.com (8.12.10/8.12.10) with ESMTP id j1F849Mh030999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2005 16:04:24 +0800 Received: from penguin.linux-vs.org (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id j1F83FuA006377; Tue, 15 Feb 2005 16:03:15 +0800 Received: from localhost (wensong@localhost) by penguin.linux-vs.org (8.12.8/8.12.8/Submit) with ESMTP id j1F83Ae8006372; Tue, 15 Feb 2005 16:03:13 +0800 X-Authentication-Warning: penguin.linux-vs.org: wensong owned process doing -bs Date: Tue, 15 Feb 2005 16:03:10 +0800 (CST) From: Wensong Zhang To: "David S. Miller" , netdev@oss.sgi.com cc: Julian Anastasov Subject: [PATCH] [IPVS] update mark->cw in the WRR scheduler while service is updated Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1463811584-572891765-1097000265=:2451" Content-ID: X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev Content-Length: 2289 Lines: 51 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Hi Dave, This is the patch for the WRR scheduler in IPVS of kernel 2.4. It's a fix for better performance when server weight is adjusted. Please check and apply it to kernel 2.4. Thanks, Wensong ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-wrr.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-wrr.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5 bGUgcGF0Y2guDQojDQojIENoYW5nZVNldA0KIyAgIDIwMDUvMDIvMTUgMTU6 NTc6MTYrMDg6MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcgDQojICAgW0lQVlNd IHVwZGF0ZSBtYXJrLT5jdyBpbiB0aGUgV1JSIHNjaGVkdWxlciB3aGlsZSBz ZXJ2aWNlIGlzIHVwZGF0ZWQNCiMgICANCiMgICBJdCdzIGZvciBiZXR0ZXIg cGVyZm9ybWFuY2UgaW4gdGhlIFdSUiBzY2hlZHVsaW5nIHdoZW4gc2VydmVy IHdlaWdodCBpcyBhZGp1c3RlZC4NCiMgICBUaGUgY2hhbmdlIGlzIHBvcnRl ZCBmcm9tIHRoZSBjaGFuZ2VzIG9mIElQVlMgaW4ga2VybmVsIDIuNi4gVGhh bmtzIG11c3QgZ28gdG8NCiMgICBLZWVzIEhvZWt6ZW1hIDxrZWVzQHR3ZWFr ZXJzLm5ldD4gZm9yIGZpbmRpbmcgdGhlIFdSUiBwcm9ibGVtIGluIGtlcm5l bCAyLjYuDQojICAgDQojIA0KIyBuZXQvaXB2NC9pcHZzL2lwX3ZzX3dyci5j DQojICAgMjAwNS8wMi8xNSAxNTo1NzoxMSswODowMCB3ZW5zb25nQGxpbnV4 LXZzLm9yZyArMiAtMA0KIyAgIHJlc2V0IG1hcmstPmN3IGlmIG1hcmstPmN3 IGlzIGdyZWF0ZXIgdGhhbiB0aGUgbWF4aW11bSB3ZWlnaHQgd2hpbGUgdXBk YXRpbmcgc2VydmljZQ0KIyANCmRpZmYgLU5ydSBhL25ldC9pcHY0L2lwdnMv aXBfdnNfd3JyLmMgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX3dyci5jDQotLS0g YS9uZXQvaXB2NC9pcHZzL2lwX3ZzX3dyci5jCTIwMDUtMDItMTUgMTU6NTg6 MTcgKzA4OjAwDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX3dyci5jCTIw MDUtMDItMTUgMTU6NTg6MTcgKzA4OjAwDQpAQCAtMTQwLDYgKzE0MCw4IEBA DQogCW1hcmstPmNsID0gJnN2Yy0+ZGVzdGluYXRpb25zOw0KIAltYXJrLT5t dyA9IGlwX3ZzX3dycl9tYXhfd2VpZ2h0KHN2Yyk7DQogCW1hcmstPmRpID0g aXBfdnNfd3JyX2djZF93ZWlnaHQoc3ZjKTsNCisJaWYgKG1hcmstPmN3ID4g bWFyay0+bXcpDQorCQltYXJrLT5jdyA9IDA7DQogCXJldHVybiAwOw0KIH0N CiANCg== ---1463811584-572891765-1097000265=:2451-- From herbert@gondor.apana.org.au Tue Feb 15 01:54:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 01:54:40 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F9sVvt015403 for ; Tue, 15 Feb 2005 01:54:32 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D0zPJ-0003So-00; Tue, 15 Feb 2005 20:54:13 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D0zOs-0005jA-00; Tue, 15 Feb 2005 20:53:46 +1100 Date: Tue, 15 Feb 2005 20:53:46 +1100 To: Mika Penttil? Cc: netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst Message-ID: <20050215095346.GA21999@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <4211AE5E.2010506@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4211AE5E.2010506@kolumbus.fi> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 808 Lines: 25 On Tue, Feb 15, 2005 at 10:10:06AM +0200, Mika Penttil? wrote: > > Shouldn't this pinning happen inside the loop for eaxh xdst, to be > balanced with the dst_release(xdst->route) in xfrm_dst_destroy ? > > >+ dst_hold(&rt->u.dst); > > > > for (i = 0; i < nx; i++) { > > struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); > >+ struct xfrm_dst *xdst; > > > > if (unlikely(dst1 == NULL)) { > > err = -ENOBUFS; There is a dst_release here. The reference is either released here if the allocation fails, or it is held by dst1 which is either returned or freed as part of the bundle. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mika.penttila@kolumbus.fi Tue Feb 15 02:18:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 02:18:55 -0800 (PST) Received: from mail-gw.turkuamk.fi (mail-gw.turkuamk.fi [195.148.208.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FAIneF016590 for ; Tue, 15 Feb 2005 02:18:50 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id A32A0F30C8; Tue, 15 Feb 2005 12:18:43 +0200 (EET) Received: from mail-gw.turkuamk.fi ([127.0.0.1]) by localhost (mail-gw.turkuamk.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07350-04; Tue, 15 Feb 2005 12:18:43 +0200 (EET) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 809F2F30C4; Tue, 15 Feb 2005 12:18:43 +0200 (EET) Received: from [192.168.0.34] ([193.166.136.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2005021512203521:11631 ; Tue, 15 Feb 2005 12:20:35 +0200 Message-ID: <4211CD5A.9010804@kolumbus.fi> Date: Tue, 15 Feb 2005 12:22:18 +0200 From: =?UTF-8?B?TWlrYSBQZW50dGlsw6Q=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <4211AE5E.2010506@kolumbus.fi> <20050215095346.GA21999@gondor.apana.org.au> In-Reply-To: <20050215095346.GA21999@gondor.apana.org.au> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 15.02.2005 12:20:35, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 15.02.2005 12:21:05, Serialize complete at 15.02.2005 12:21:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at tekniikka.turkuamk.fi X-Virus-Status: Clean X-archive-position: 1641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 686 Lines: 33 Herbert Xu wrote: >On Tue, Feb 15, 2005 at 10:10:06AM +0200, Mika Penttil? wrote: > > >>Shouldn't this pinning happen inside the loop for eaxh xdst, to be >>balanced with the dst_release(xdst->route) in xfrm_dst_destroy ? >> >> >> >>>+ dst_hold(&rt->u.dst); >>> >>> for (i = 0; i < nx; i++) { >>> struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); >>>+ struct xfrm_dst *xdst; >>> >>> if (unlikely(dst1 == NULL)) { >>> err = -ENOBUFS; >>> >>> > >There is a dst_release here. > >The reference is either released here if the allocation fails, or it >is held by dst1 which is either returned or freed as part of the bundle. > >Cheers, > > ok I see now, thanks Mika From jmorris@redhat.com Tue Feb 15 07:54:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 07:54:28 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FFsLs6002366 for ; Tue, 15 Feb 2005 07:54:22 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1FFrJAR028087; Tue, 15 Feb 2005 10:53:19 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1FFrDO04126; Tue, 15 Feb 2005 10:53:13 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1FFrBZh017258; Tue, 15 Feb 2005 10:53:11 -0500 Date: Tue, 15 Feb 2005 10:53:11 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Subject: Re: [4/4] [IPSEC] Store MTU at each xfrm_dst In-Reply-To: <20050214221607.GC18465@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1642 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: 670 Lines: 25 On Tue, 15 Feb 2005, Herbert Xu wrote: > Finally this is the patch that sets the MTU values of each xfrm_dst > and keeps it up-to-date. > > Signed-off-by: Herbert Xu > > To recap, at this point we've obtained accurate MTU values at each > xfrm_dst. The next step would be to start using it as > dst_pmtu(xfrm_dst). Nice work. The only thing I'd suggest is to consider renaming the new route element of xfrm_dst to xfrm_dst_route (or xd_route), to make it easier to navigate the code. (But the other elements are not distinctive either so perhaps some future cleanup could do it). - James -- James Morris From s.rivoir@gts.it Tue Feb 15 09:07:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 09:07:25 -0800 (PST) Received: from mail.gts.it ([217.222.53.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FH7DQ7008452 for ; Tue, 15 Feb 2005 09:07:14 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.gts.it (Postfix) with ESMTP id 857871DD4BC for ; Tue, 15 Feb 2005 18:07:07 +0100 (CET) Received: from mail.gts.it ([127.0.0.1]) by localhost (gtsmail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09907-09 for ; Tue, 15 Feb 2005 18:06:48 +0100 (CET) Received: from [192.168.0.72] (pcsteu2 [192.168.0.72]) by mail.gts.it (Postfix) with ESMTP id C09FA1DD33D for ; Tue, 15 Feb 2005 18:06:47 +0100 (CET) Message-ID: <42122C27.8000305@gts.it> Date: Tue, 15 Feb 2005 18:06:47 +0100 From: Stefano Rivoir User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: Re: 2.6.11-rc3-mm2] - skge Content-Type: multipart/mixed; boundary="------------040604000906090406080809" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gts.it X-Virus-Status: Clean X-archive-position: 1643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s.rivoir@gts.it Precedence: bulk X-list: netdev Content-Length: 37121 Lines: 1573 This is a multi-part message in MIME format. --------------040604000906090406080809 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit I'm forwarding what I've sent to LKML, but probably this is the best place. Please, cc if you have replies, I'm not subscribed to the list. Bye all. -------- Original Message -------- Subject: Re: 2.6.11-rc3-mm2 Date: Mon, 14 Feb 2005 14:22:29 +0100 From: Stefano Rivoir To: Andrew Morton CC: linux-kernel@vger.kernel.org References: <20050210023508.3583cf87.akpm@osdl.org> Alle 11:35, giovedì 10 febbraio 2005, Andrew Morton ha scritto: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2. >6.11-rc3-mm2/ I was trying to use the skge module for my Intel 3c940 card, in place of the (working) sk98lin. It gives the following: Feb 14 14:16:35 nbsteu kernel: kobject_register failed for skge (-17) Feb 14 14:16:35 nbsteu kernel: [kobject_register+81/96] kobject_register+0x51/0x60 Feb 14 14:16:35 nbsteu kernel: [bus_add_driver+82/192] bus_add_driver+0x52/0xc0 Feb 14 14:16:35 nbsteu kernel: [driver_register+40/48] driver_register+0x28/0x30 Feb 14 14:16:35 nbsteu kernel: [pci_register_driver+94/128] pci_register_driver+0x5e/0x80 Feb 14 14:16:35 nbsteu kernel: [sys_init_module+313/480] sys_init_module+0x139/0x1e0 Feb 14 14:16:35 nbsteu kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75 Attached, .config and lspci -v -- Stefano Rivoir -- Stefano RIVOIR GTS Srl --------------040604000906090406080809 Content-Type: text/plain; name="lspci-v" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspci-v" 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS 645xx (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 1738 Flags: bus master, medium devsel, latency 32 Memory at e8000000 (32-bit, non-prefetchable) [size=64M] Capabilities: [c0] AGP version 2.0 0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: e7800000-e7ffffff Prefetchable memory behind bridge: eff00000-febfffff 0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 14) Flags: bus master, medium devsel, latency 0 0000:00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 Flags: medium devsel I/O ports at e800 [size=32] 0000:00:02.3 FireWire (IEEE 1394): Silicon Integrated Systems [SiS] FireWire Controller (prog-if 10 [OHCI]) Subsystem: Asustek Computer, Inc.: Unknown device 1737 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e7000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [64] Power Management version 2 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master]) Subsystem: Asustek Computer, Inc.: Unknown device 1738 Flags: bus master, medium devsel, latency 32 I/O ports at b800 [size=16] Capabilities: [58] Power Management version 2 0000:00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0) (prog-if 00 [Generic]) Subsystem: Asustek Computer, Inc.: Unknown device 1736 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b400 [size=256] I/O ports at b000 [size=128] Capabilities: [48] Power Management version 2 0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) Subsystem: Asustek Computer, Inc.: Unknown device 1733 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at a800 [size=256] I/O ports at a400 [size=128] Capabilities: [48] Power Management version 2 0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Asustek Computer, Inc.: Unknown device 1739 Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at e6800000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Asustek Computer, Inc.: Unknown device 1739 Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at e6000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 0000:00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Asustek Computer, Inc.: Unknown device 1739 Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at e5800000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI]) Subsystem: Asustek Computer, Inc.: Unknown device 173a Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at e5000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 0000:00:0a.0 CardBus bridge: ENE Technology Inc CB720 Cardbus Controller (rev 01) Subsystem: Asustek Computer, Inc.: Unknown device 1734 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 20000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 20400000-207ff000 (prefetchable) Memory window 1: 20800000-20bff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 0000:00:0a.1 CardBus bridge: ENE Technology Inc CB720 Cardbus Controller (rev 01) Subsystem: Asustek Computer, Inc.: Unknown device 1734 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 20001000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 20c00000-20fff000 (prefetchable) Memory window 1: 21000000-213ff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 0000:00:0a.2 FLASH memory: ENE Technology Inc CB710 Memory Card Reader Controller Subsystem: Asustek Computer, Inc.: Unknown device 173b Flags: medium devsel, IRQ 11 I/O ports at 9800 [size=128] Capabilities: [a0] Power Management version 2 0000:00:0d.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) Subsystem: Asustek Computer, Inc.: Unknown device 173c Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at e4000000 (32-bit, non-prefetchable) [size=16K] I/O ports at 9400 [size=256] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 1732 Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 11 Memory at f0000000 (32-bit, prefetchable) [size=128M] I/O ports at d800 [size=256] Memory at e7800000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at effe0000 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 --------------040604000906090406080809 Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc3-mm2 # Fri Feb 11 08:56:56 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_KEXEC is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m # CONFIG_PD6729 is not set # CONFIG_I82092 is not set # CONFIG_TCIC is not set CONFIG_PCCARD_NONSTATIC=m # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m # CONFIG_PARPORT_PC is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPNP=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set CONFIG_BLK_DEV_SIS5513=y # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # # Texas Instruments PCILynx requires I2C # CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set # CONFIG_IEEE1394_RAWIO is not set # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_TUNNEL is not set # CONFIG_IP_TCPDIAG is not set # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set # CONFIG_IP_NF_CONNTRACK_MARK is not set # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m # CONFIG_IP_NF_MATCH_IPRANGE is not set CONFIG_IP_NF_MATCH_MAC=m # CONFIG_IP_NF_MATCH_PKTTYPE is not set CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m # CONFIG_IP_NF_MATCH_TOS is not set # CONFIG_IP_NF_MATCH_RECENT is not set # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set # CONFIG_IP_NF_MATCH_AH_ESP is not set # CONFIG_IP_NF_MATCH_LENGTH is not set # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_MATCH_TCPMSS is not set # CONFIG_IP_NF_MATCH_HELPER is not set CONFIG_IP_NF_MATCH_STATE=m # CONFIG_IP_NF_MATCH_CONNTRACK is not set # CONFIG_IP_NF_MATCH_OWNER is not set # CONFIG_IP_NF_MATCH_ADDRTYPE is not set # CONFIG_IP_NF_MATCH_REALM is not set # CONFIG_IP_NF_MATCH_SCTP is not set # CONFIG_IP_NF_MATCH_COMMENT is not set # CONFIG_IP_NF_MATCH_HASHLIMIT is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m # CONFIG_IP_NF_TARGET_ULOG is not set # CONFIG_IP_NF_TARGET_TCPMSS is not set CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_SAME is not set # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m # CONFIG_IP_NF_TARGET_ECN is not set # CONFIG_IP_NF_TARGET_DSCP is not set # CONFIG_IP_NF_TARGET_MARK is not set # CONFIG_IP_NF_TARGET_CLASSIFY is not set # CONFIG_IP_NF_RAW is not set # CONFIG_IP_NF_ARPTABLES is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # CONFIG_NET_CLS_ROUTE is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_KGDBOE is not set # CONFIG_NETPOLL is not set # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set CONFIG_EEPRO100=m # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set CONFIG_SKGE=m CONFIG_SK98LIN=m # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=y # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_UINPUT is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m # CONFIG_SERIAL_8250_CS is not set # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set CONFIG_AGP_SIS=m # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # # CONFIG_I2C is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # SuperIO subsystem support # # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON_OLD is not set CONFIG_FB_RADEON=y # CONFIG_FB_RADEON_I2C is not set # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y # CONFIG_FONT_8x8 is not set CONFIG_FONT_8x16=y CONFIG_FONT_6x11=y CONFIG_FONT_PEARL_8x8=y CONFIG_FONT_ACORN_8x8=y CONFIG_FONT_MINI_4x6=y CONFIG_FONT_SUN8x16=y CONFIG_FONT_SUN12x22=y # # Logo configuration # # CONFIG_LOGO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_HDA_INTEL is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # PCMCIA devices # # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_UHCI_HCD is not set # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_RW_DETECT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set CONFIG_USB_STORAGE_USBAT=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_MON is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_REISER4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # # XFS support # # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # Caches # # CONFIG_FSCACHE is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set # CONFIG_TMPFS is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_PREEMPT is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_PAGE_OWNER is not set # CONFIG_DEBUG_FS is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set # CONFIG_KGDB is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Hardware crypto devices # # # Library routines # # CONFIG_CRC_CCITT is not set CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y --------------040604000906090406080809-- From davem@davemloft.net Tue Feb 15 09:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 09:16:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FHGbTj009373 for ; Tue, 15 Feb 2005 09:16:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D16Gw-000696-00; Tue, 15 Feb 2005 09:14:02 -0800 Date: Tue, 15 Feb 2005 09:14:01 -0800 From: "David S. Miller" To: "David S. Miller" Cc: peterc@gelato.unsw.edu.au, netdev@oss.sgi.com, mchan@broadcom.com Subject: Re: Fix fallout from tg3_readphy() value is zero on error Message-Id: <20050215091401.3d6174d8.davem@davemloft.net> In-Reply-To: <20050120233639.5e6088ee.davem@davemloft.net> References: <16880.24671.640491.852938@berry.gelato.unsw.EDU.AU> <20050120233639.5e6088ee.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 8470 Lines: 313 I've added missing tg3_readphy() return value checks wherever I could sanely do so. Where possible, we throw back an error return. Else, we at least try to avoid writing bogus PHY register values. In general, I just try to make sure nothing incredibly stupid happens if tg3_readphy() fails for some reason. ===== drivers/net/tg3.c 1.241 vs edited ===== --- 1.241/drivers/net/tg3.c 2005-02-11 12:44:48 -08:00 +++ edited/drivers/net/tg3.c 2005-02-15 08:41:45 -08:00 @@ -591,9 +591,10 @@ if (tp->tg3_flags2 & TG3_FLG2_NO_ETH_WIRE_SPEED) return; - tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007); - tg3_readphy(tp, MII_TG3_AUX_CTRL, &val); - tg3_writephy(tp, MII_TG3_AUX_CTRL, (val | (1 << 15) | (1 << 4))); + if (!tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007) && + !tg3_readphy(tp, MII_TG3_AUX_CTRL, &val)) + tg3_writephy(tp, MII_TG3_AUX_CTRL, + (val | (1 << 15) | (1 << 4))); } static int tg3_bmcr_reset(struct tg3 *tp) @@ -634,9 +635,10 @@ while (limit--) { u32 tmp32; - tg3_readphy(tp, 0x16, &tmp32); - if ((tmp32 & 0x1000) == 0) - break; + if (!tg3_readphy(tp, 0x16, &tmp32)) { + if ((tmp32 & 0x1000) == 0) + break; + } } if (limit <= 0) return -EBUSY; @@ -688,9 +690,9 @@ for (i = 0; i < 6; i += 2) { u32 low, high; - tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &low); - tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &high); - if (tg3_wait_macro_done(tp)) { + if (tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &low) || + tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &high) || + tg3_wait_macro_done(tp)) { *resetp = 1; return -EBUSY; } @@ -746,7 +748,9 @@ } /* Disable transmitter and interrupt. */ - tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); + if (tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) + continue; + reg32 |= 0x3000; tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); @@ -755,7 +759,9 @@ BMCR_FULLDPLX | TG3_BMCR_SPEED1000); /* Set to master mode. */ - tg3_readphy(tp, MII_TG3_CTRL, &phy9_orig); + if (tg3_readphy(tp, MII_TG3_CTRL, &phy9_orig)) + continue; + tg3_writephy(tp, MII_TG3_CTRL, (MII_TG3_CTRL_AS_MASTER | MII_TG3_CTRL_ENABLE_AS_MASTER)); @@ -793,9 +799,11 @@ tg3_writephy(tp, MII_TG3_CTRL, phy9_orig); - tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); - reg32 &= ~0x3000; - tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + if (tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) { + reg32 &= ~0x3000; + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + } else if (!err) + err = -EBUSY; return err; } @@ -859,9 +867,9 @@ u32 phy_reg; /* Set bit 14 with read-modify-write to preserve other bits */ - tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0007); - tg3_readphy(tp, MII_TG3_AUX_CTRL, &phy_reg); - tg3_writephy(tp, MII_TG3_AUX_CTRL, phy_reg | 0x4000); + if (!tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0007) && + !tg3_readphy(tp, MII_TG3_AUX_CTRL, &phy_reg)) + tg3_writephy(tp, MII_TG3_AUX_CTRL, phy_reg | 0x4000); } tg3_phy_set_wirespeed(tp); return 0; @@ -1244,7 +1252,7 @@ }; } -static int tg3_phy_copper_begin(struct tg3 *tp) +static void tg3_phy_copper_begin(struct tg3 *tp) { u32 new_adv; int i; @@ -1359,15 +1367,16 @@ if (tp->link_config.duplex == DUPLEX_FULL) bmcr |= BMCR_FULLDPLX; - tg3_readphy(tp, MII_BMCR, &orig_bmcr); - if (bmcr != orig_bmcr) { + if (!tg3_readphy(tp, MII_BMCR, &orig_bmcr) && + (bmcr != orig_bmcr)) { tg3_writephy(tp, MII_BMCR, BMCR_LOOPBACK); for (i = 0; i < 1500; i++) { u32 tmp; udelay(10); - tg3_readphy(tp, MII_BMSR, &tmp); - tg3_readphy(tp, MII_BMSR, &tmp); + if (tg3_readphy(tp, MII_BMSR, &tmp) || + tg3_readphy(tp, MII_BMSR, &tmp)) + continue; if (!(tmp & BMSR_LSTATUS)) { udelay(40); break; @@ -1380,8 +1389,6 @@ tg3_writephy(tp, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART); } - - return 0; } static int tg3_init_5401phy_dsp(struct tg3 *tp) @@ -1416,7 +1423,9 @@ { u32 adv_reg, all_mask; - tg3_readphy(tp, MII_ADVERTISE, &adv_reg); + if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg)) + return 0; + all_mask = (ADVERTISE_10HALF | ADVERTISE_10FULL | ADVERTISE_100HALF | ADVERTISE_100FULL); if ((adv_reg & all_mask) != all_mask) @@ -1424,7 +1433,9 @@ if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) { u32 tg3_ctrl; - tg3_readphy(tp, MII_TG3_CTRL, &tg3_ctrl); + if (tg3_readphy(tp, MII_TG3_CTRL, &tg3_ctrl)) + return 0; + all_mask = (MII_TG3_CTRL_ADV_1000_HALF | MII_TG3_CTRL_ADV_1000_FULL); if ((tg3_ctrl & all_mask) != all_mask) @@ -1464,8 +1475,8 @@ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) && netif_carrier_ok(tp->dev)) { tg3_readphy(tp, MII_BMSR, &bmsr); - tg3_readphy(tp, MII_BMSR, &bmsr); - if (!(bmsr & BMSR_LSTATUS)) + if (!tg3_readphy(tp, MII_BMSR, &bmsr) && + !(bmsr & BMSR_LSTATUS)) force_reset = 1; } if (force_reset) @@ -1473,9 +1484,8 @@ if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) { tg3_readphy(tp, MII_BMSR, &bmsr); - tg3_readphy(tp, MII_BMSR, &bmsr); - - if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE)) + if (tg3_readphy(tp, MII_BMSR, &bmsr) || + !(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE)) bmsr = 0; if (!(bmsr & BMSR_LSTATUS)) { @@ -1486,8 +1496,8 @@ tg3_readphy(tp, MII_BMSR, &bmsr); for (i = 0; i < 1000; i++) { udelay(10); - tg3_readphy(tp, MII_BMSR, &bmsr); - if (bmsr & BMSR_LSTATUS) { + if (!tg3_readphy(tp, MII_BMSR, &bmsr) && + (bmsr & BMSR_LSTATUS)) { udelay(40); break; } @@ -1549,8 +1559,8 @@ bmsr = 0; for (i = 0; i < 100; i++) { tg3_readphy(tp, MII_BMSR, &bmsr); - tg3_readphy(tp, MII_BMSR, &bmsr); - if (bmsr & BMSR_LSTATUS) + if (!tg3_readphy(tp, MII_BMSR, &bmsr) && + (bmsr & BMSR_LSTATUS)) break; udelay(40); } @@ -1561,8 +1571,8 @@ tg3_readphy(tp, MII_TG3_AUX_STAT, &aux_stat); for (i = 0; i < 2000; i++) { udelay(10); - tg3_readphy(tp, MII_TG3_AUX_STAT, &aux_stat); - if (aux_stat) + if (!tg3_readphy(tp, MII_TG3_AUX_STAT, &aux_stat) && + aux_stat) break; } @@ -1573,7 +1583,8 @@ bmcr = 0; for (i = 0; i < 200; i++) { tg3_readphy(tp, MII_BMCR, &bmcr); - tg3_readphy(tp, MII_BMCR, &bmcr); + if (tg3_readphy(tp, MII_BMCR, &bmcr)) + continue; if (bmcr && bmcr != 0x7fff) break; udelay(10); @@ -1610,10 +1621,13 @@ (tp->link_config.autoneg == AUTONEG_ENABLE)) { u32 local_adv, remote_adv; - tg3_readphy(tp, MII_ADVERTISE, &local_adv); + if (tg3_readphy(tp, MII_ADVERTISE, &local_adv)) + local_adv = 0; local_adv &= (ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM); - tg3_readphy(tp, MII_LPA, &remote_adv); + if (tg3_readphy(tp, MII_LPA, &remote_adv)) + remote_adv = 0; + remote_adv &= (LPA_PAUSE_CAP | LPA_PAUSE_ASYM); /* If we are not advertising full pause capability, @@ -1632,8 +1646,8 @@ tg3_phy_copper_begin(tp); tg3_readphy(tp, MII_BMSR, &tmp); - tg3_readphy(tp, MII_BMSR, &tmp); - if (tmp & BMSR_LSTATUS) + if (!tg3_readphy(tp, MII_BMSR, &tmp) && + (tmp & BMSR_LSTATUS)) current_link_up = 1; } @@ -5441,9 +5455,10 @@ u32 tmp; /* Clear CRC stats. */ - tg3_readphy(tp, 0x1e, &tmp); - tg3_writephy(tp, 0x1e, tmp | 0x8000); - tg3_readphy(tp, 0x14, &tmp); + if (!tg3_readphy(tp, 0x1e, &tmp)) { + tg3_writephy(tp, 0x1e, tmp | 0x8000); + tg3_readphy(tp, 0x14, &tmp); + } } __tg3_set_rx_mode(tp->dev); @@ -6033,9 +6048,11 @@ u32 val; spin_lock_irqsave(&tp->lock, flags); - tg3_readphy(tp, 0x1e, &val); - tg3_writephy(tp, 0x1e, val | 0x8000); - tg3_readphy(tp, 0x14, &val); + if (!tg3_readphy(tp, 0x1e, &val)) { + tg3_writephy(tp, 0x1e, val | 0x8000); + tg3_readphy(tp, 0x14, &val); + } else + val = 0; spin_unlock_irqrestore(&tp->lock, flags); tp->phy_crc_errors += val; @@ -6651,10 +6668,10 @@ int r; spin_lock_irq(&tp->lock); - tg3_readphy(tp, MII_BMCR, &bmcr); - tg3_readphy(tp, MII_BMCR, &bmcr); r = -EINVAL; - if (bmcr & BMCR_ANENABLE) { + tg3_readphy(tp, MII_BMCR, &bmcr); + if (!tg3_readphy(tp, MII_BMCR, &bmcr) && + (bmcr & BMCR_ANENABLE)) { tg3_writephy(tp, MII_BMCR, bmcr | BMCR_ANRESTART); r = 0; } @@ -7654,9 +7671,8 @@ u32 bmsr, adv_reg, tg3_ctrl; tg3_readphy(tp, MII_BMSR, &bmsr); - tg3_readphy(tp, MII_BMSR, &bmsr); - - if (bmsr & BMSR_LSTATUS) + if (!tg3_readphy(tp, MII_BMSR, &bmsr) && + (bmsr & BMSR_LSTATUS)) goto skip_phy_reset; err = tg3_phy_reset(tp); From davem@davemloft.net Tue Feb 15 10:00:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 10:00:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FI0lCJ011206 for ; Tue, 15 Feb 2005 10:00:48 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D16xh-0006Lf-00; Tue, 15 Feb 2005 09:58:13 -0800 Date: Tue, 15 Feb 2005 09:58:13 -0800 From: "David S. Miller" To: Ralf Baechle DL5RB Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 1/9] Use netdev_priv in NETROM and ROSE Message-Id: <20050215095813.6c19b2a8.davem@davemloft.net> In-Reply-To: <20050130212147.GA6399@linux-mips.org> References: <20050130212147.GA6399@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 175 Lines: 6 On Sun, 30 Jan 2005 21:21:47 +0000 Ralf Baechle DL5RB wrote: > Convert the NETROM and ROSE protocol stacks to use netdev_priv(). Applied, thanks Ralf. From mchan@broadcom.com Tue Feb 15 10:18:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 10:19:03 -0800 (PST) Received: from MMS2.broadcom.com (mms-nat.broadcom.com [63.70.210.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FIIwjF012369 for ; Tue, 15 Feb 2005 10:18:59 -0800 Received: from 63.70.210.1 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 15 Feb 2005 10:18:45 -0800 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 15 Feb 2005 10:18:29 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AKW05602; Tue, 15 Feb 2005 10:18:15 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA04796; Tue, 15 Feb 2005 10:18:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Fix fallout from tg3_readphy() value is zero on error Date: Tue, 15 Feb 2005 10:18:14 -0800 Message-ID: Thread-Topic: Fix fallout from tg3_readphy() value is zero on error Thread-Index: AcUTgjDplSoOuQ0sTkq/1tePl0nJgwAB94xA From: "Michael Chan" To: "David S. Miller" cc: peterc@gelato.unsw.edu.au, netdev@oss.sgi.com X-WSS-ID: 6E0CE28E2I85150090-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1FIIwjF012369 X-archive-position: 1646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 461 Lines: 22 > @@ -793,9 +799,11 @@ > > tg3_writephy(tp, MII_TG3_CTRL, phy9_orig); > > - tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); > - reg32 &= ~0x3000; > - tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); > + if (tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) { > + reg32 &= ~0x3000; > + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); > + } else if (!err) > + err = -EBUSY; > > return err; > } Shouldn't this be: > + if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) { From davem@davemloft.net Tue Feb 15 10:26:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 10:26:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FIQ7Je013201 for ; Tue, 15 Feb 2005 10:26:07 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D17MA-0006Sb-00; Tue, 15 Feb 2005 10:23:30 -0800 Date: Tue, 15 Feb 2005 10:23:30 -0800 From: "David S. Miller" To: Olaf Hering Cc: netdev@oss.sgi.com Subject: Re: [PATCH] fix typo in include/linux/socket.h Message-Id: <20050215102330.4bd6567d.davem@davemloft.net> In-Reply-To: <20050214174739.GA23145@suse.de> References: <20050212171521.GA3497@suse.de> <20050214174739.GA23145@suse.de> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 198 Lines: 8 On Mon, 14 Feb 2005 18:47:39 +0100 Olaf Hering wrote: > I guess we have to reduce the patch to fix just the typo. > > Signed-off-by: Olaf Hering Applied, thanks Olaf. From davem@davemloft.net Tue Feb 15 10:36:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 10:36:30 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FIaPD1014711 for ; Tue, 15 Feb 2005 10:36:25 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D17VZ-0006YR-00; Tue, 15 Feb 2005 10:33:13 -0800 Date: Tue, 15 Feb 2005 10:33:12 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [2/2] [NET] Add skb_header_cloned and use it in e1000/tg3 Message-Id: <20050215103312.6178385f.davem@davemloft.net> In-Reply-To: <20050129032210.GA7424@gondor.apana.org.au> References: <20050121204024.6f94fc26.davem@davemloft.net> <20050122054346.GA1635@gondor.apana.org.au> <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 446 Lines: 10 On Sat, 29 Jan 2005 14:22:10 +1100 Herbert Xu wrote: > This patch then uses this function in e1000/tg3 to copy the data before > the TCP/IP header is modified. The tg3 version creates an SKB leak. If pskb_expand_head() fails, we just unlock and return NETDEV_TX_OK. The upper layer assumes the driver took ownership of the SKB in such a case. I would recommend just kfree_skb()'ing the thing when this happens. From davem@davemloft.net Tue Feb 15 11:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 11:14:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FJE6Mu016277 for ; Tue, 15 Feb 2005 11:14:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D186d-0006iX-00; Tue, 15 Feb 2005 11:11:31 -0800 Date: Tue, 15 Feb 2005 11:11:31 -0800 From: "David S. Miller" To: "Michael Chan" Cc: peterc@gelato.unsw.edu.au, netdev@oss.sgi.com Subject: Re: Fix fallout from tg3_readphy() value is zero on error Message-Id: <20050215111131.29cf288b.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 622 Lines: 26 On Tue, 15 Feb 2005 10:18:14 -0800 "Michael Chan" wrote: > > @@ -793,9 +799,11 @@ > > > > tg3_writephy(tp, MII_TG3_CTRL, phy9_orig); > > > > - tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); > > - reg32 &= ~0x3000; > > - tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); > > + if (tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) { > > + reg32 &= ~0x3000; > > + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); > > + } else if (!err) > > + err = -EBUSY; > > > > return err; > > } > > Shouldn't this be: > > > + if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) { Right, fixed in my local tree. Thanks a lot. From herbert@gondor.apana.org.au Tue Feb 15 12:25:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 12:25:44 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FKPYaO022774 for ; Tue, 15 Feb 2005 12:25:35 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D19Fu-000839-00; Wed, 16 Feb 2005 07:25:10 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D19Fd-00018b-00; Wed, 16 Feb 2005 07:24:53 +1100 Date: Wed, 16 Feb 2005 07:24:53 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [2/2] [NET] Add skb_header_cloned and use it in e1000/tg3 Message-ID: <20050215202453.GA4355@gondor.apana.org.au> References: <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> <20050215103312.6178385f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20050215103312.6178385f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4016 Lines: 146 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 15, 2005 at 10:33:12AM -0800, David S. Miller wrote: > > The tg3 version creates an SKB leak. If pskb_expand_head() fails, we just > unlock and return NETDEV_TX_OK. The upper layer assumes the driver took > ownership of the SKB in such a case. I would recommend just kfree_skb()'ing > the thing when this happens. Indeed. Here is the corrected version. This patch adds skb_header_cloned which tells us whether we need to copy the data before we can modify the header part of the skb. Again, what constitutes the header is left up to the users of the skb to define. This patch then uses this function in e1000/tg3 to copy the data before the TCP/IP header is modified. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tso-mangle-2 ===== drivers/net/tg3.c 1.241 vs edited ===== --- 1.241/drivers/net/tg3.c 2005-02-12 07:44:48 +11:00 +++ edited/drivers/net/tg3.c 2005-02-16 07:21:33 +11:00 @@ -3096,6 +3096,12 @@ (mss = skb_shinfo(skb)->tso_size) != 0) { int tcp_opt_len, ip_tcp_len; + if (skb_header_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) { + dev_kfree_skb(skb); + goto out_unlock; + } + tcp_opt_len = ((skb->h.th->doff - 5) * 4); ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr); ===== drivers/net/e1000/e1000_main.c 1.147 vs edited ===== --- 1.147/drivers/net/e1000/e1000_main.c 2005-01-21 08:24:31 +11:00 +++ edited/drivers/net/e1000/e1000_main.c 2005-01-29 14:11:09 +11:00 @@ -1522,7 +1522,7 @@ #define E1000_TX_FLAGS_VLAN_MASK 0xffff0000 #define E1000_TX_FLAGS_VLAN_SHIFT 16 -static inline boolean_t +static inline int e1000_tso(struct e1000_adapter *adapter, struct sk_buff *skb) { #ifdef NETIF_F_TSO @@ -1531,8 +1531,15 @@ uint32_t cmd_length = 0; uint16_t ipcse, tucse, mss; uint8_t ipcss, ipcso, tucss, tucso, hdr_len; + int err; if(skb_shinfo(skb)->tso_size) { + if (skb_header_cloned(skb)) { + err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC); + if (err) + return err; + } + hdr_len = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); mss = skb_shinfo(skb)->tso_size; skb->nh.iph->tot_len = 0; @@ -1569,11 +1576,11 @@ if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; - return TRUE; + return 1; } #endif - return FALSE; + return 0; } static inline boolean_t @@ -1798,6 +1805,7 @@ unsigned int nr_frags = 0; unsigned int mss = 0; int count = 0; + int tso; unsigned int f; len -= skb->data_len; @@ -1869,7 +1877,13 @@ first = adapter->tx_ring.next_to_use; - if(likely(e1000_tso(adapter, skb))) + tso = e1000_tso(adapter, skb); + if (tso < 0) { + dev_kfree_skb_any(skb); + return NETDEV_TX_OK; + } + + if (likely(tso)) tx_flags |= E1000_TX_FLAGS_TSO; else if(likely(e1000_tx_csum(adapter, skb))) tx_flags |= E1000_TX_FLAGS_CSUM; ===== include/linux/skbuff.h 1.60 vs edited ===== --- 1.60/include/linux/skbuff.h 2005-01-29 14:01:43 +11:00 +++ edited/include/linux/skbuff.h 2005-01-29 14:06:35 +11:00 @@ -395,6 +395,25 @@ } /** + * skb_header_cloned - is the header a clone + * @skb: buffer to check + * + * Returns true if modifying the header part of the buffer requires + * the data to be copied. + */ +static inline int skb_header_cloned(const struct sk_buff *skb) +{ + int dataref; + + if (!skb->cloned) + return 0; + + dataref = atomic_read(&skb_shinfo(skb)->dataref); + dataref = (dataref & SKB_DATAREF_MASK) - (dataref >> SKB_DATAREF_SHIFT); + return dataref != 1; +} + +/** * skb_header_release - release reference to header * @skb: buffer to operate on * --oyUTqETQ0mS9luUI-- From dan@coverfire.com Tue Feb 15 12:28:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 12:28:56 -0800 (PST) Received: from otis.cyg.net (otis.cyg.net [69.41.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FKSoK7023359 for ; Tue, 15 Feb 2005 12:28:51 -0800 Received: from ganymede.coverfire.com (ganymede.coverfire.com [69.41.199.10]) (authenticated bits=0) by otis.cyg.net (8.12.11/8.12.11) with ESMTP id j1FKSDGD016710; Tue, 15 Feb 2005 15:28:13 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: Dan Siemon To: Thomas Graf Cc: hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20050214142710.GI31837@postel.suug.ch> References: <1106232168.1041.125.camel@jzny.localdomain> <20050120153559.GG26856@postel.suug.ch> <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> <1108340618.14978.66.camel@ganymede> <20050214142710.GI31837@postel.suug.ch> Content-Type: text/plain Date: Tue, 15 Feb 2005 15:28:14 -0500 Message-Id: <1108499294.5465.22.camel@ganymede> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dan@coverfire.com Precedence: bulk X-list: netdev Content-Length: 1452 Lines: 34 On Mon, 2005-14-02 at 15:27 +0100, Thomas Graf wrote: > > I'm curious exactly what your needs are. > > Basically I need to be able to change the beavhiour of the message > parser to for example overwrite the sequence number checking in order > to do message multiplexing. It's not like I would be represenative > though. > > > It does appear you are aiming for a somewhat more low level library than > > I am. Whether or not that precludes some kind of merger I don't know. > > Yes, it seems so. It's a pitty that we waste effort by doing the same > nearly work but I really need the low level API and the possibility to > customize the parsing and sending code. Perhaps we could agree on a single API for the low-level message parsing and netlink message construction. At least then we would not be duplicating bug-fixes in our netlink code. Whether or not this sharing would be useful probably depends on if you would continue to maintain your own non-GObject APIs for the various QDiscs and classifiers. GObject makes the creation and maintenance of the language bindings much easier so its basically necessary for my goals. I'm willing to switch the underlying implementation of LQL to use your more featureful NL implementation if that means there won't be two competing C APIs to the individual QDiscs etc. -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 From tgraf@suug.ch Tue Feb 15 12:31:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 12:31:59 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FKVsJd023928 for ; Tue, 15 Feb 2005 12:31:55 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 31788F; Tue, 15 Feb 2005 21:31:29 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id B29AC1C0EA; Tue, 15 Feb 2005 21:32:11 +0100 (CET) Date: Tue, 15 Feb 2005 21:32:11 +0100 From: Thomas Graf To: Pablo Neira , Harald Welte Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: [RFC] string matching based packet classification/filtering Message-ID: <20050215203211.GL31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1847 Lines: 39 We have been discussing string matching based packet classification and filterings a few times already and I'd like to make it serious this time to get the string matching ematch ready for 2.6.12 inclusion. I'm aware of the bayer-moore based patch by Emmanuel Roger, Gianni Tedesco, and Pablo but I also heard about a generic string matching architecture supporting various algorithms I haven't found that patchset though. Is there any effort going into the generic architecture? Any plans for a stateful string matching netfilter module? As it was mentioned already we could share some code between the ematch and netfilter. I do not care for the algorithm, actually I think it doesn't matter at all as long as it's not a naive linear search. The essential parts are to be able to define a searching range and to support paged skbs. If there is someone going for the generic architecture fullfilling the essential parts just described then I'll be more than happy to use that bit of code otherwise I'd be happy to discuss the requirements of both sides and try to find a compromise both sides can live with. The requirements from my side: In: o pattern as byte stream o length of pattern o begin of search range (skb layer + offset) o end of search range (skb layer + offset) o (p)skb Out: o true or false Applying this on the recently posted implementation by Pablo it shows that it nearly fits already except for the search range. Additionaly it could be improved by using prefix optimizations for the fragment border regions instead of a naive string search which would help for large patterns on paged skbs. If needed an additional input argument could be added specifying the algorithm to be used. Eventually it requires an additional algoirthm specific argument carrying meta data such as prefix lookup tables. Thoughts? From herbert@gondor.apana.org.au Tue Feb 15 12:32:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 12:32:47 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FKWdcq024284 for ; Tue, 15 Feb 2005 12:32:40 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D19MH-0008HV-00; Wed, 16 Feb 2005 07:31:45 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D19Lk-0004FW-00; Wed, 16 Feb 2005 07:31:12 +1100 Date: Wed, 16 Feb 2005 07:31:12 +1100 To: James Morris Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [4/4] [IPSEC] Store MTU at each xfrm_dst Message-ID: <20050215203112.GA16313@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 794 Lines: 21 On Tue, Feb 15, 2005 at 10:53:11AM -0500, James Morris wrote: > > The only thing I'd suggest is to consider renaming the new route element > of xfrm_dst to xfrm_dst_route (or xd_route), to make it easier to navigate > the code. (But the other elements are not distinctive either so perhaps > some future cleanup could do it). Thanks for your comment. I would say that not only are the other elements of xfrm_dst missing the prefixes, but the same thing applies to the rest of xfrm.h :) So if we decide to go that way, then we should do it to the entire xfrm subsystem. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Tue Feb 15 12:47:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 12:47:13 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FKl6KI025305 for ; Tue, 15 Feb 2005 12:47:07 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id EF2EEF; Tue, 15 Feb 2005 21:46:43 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 030A61C0EA; Tue, 15 Feb 2005 21:47:23 +0100 (CET) Date: Tue, 15 Feb 2005 21:47:23 +0100 From: Thomas Graf To: Dan Siemon Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050215204723.GM31837@postel.suug.ch> References: <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> <1108340618.14978.66.camel@ganymede> <20050214142710.GI31837@postel.suug.ch> <1108499294.5465.22.camel@ganymede> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108499294.5465.22.camel@ganymede> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1810 Lines: 44 > Perhaps we could agree on a single API for the low-level message parsing > and netlink message construction. At least then we would not be > duplicating bug-fixes in our netlink code. Sure, I think they're quite similiar. I abstracted the netlink message and routing attributes building a bit and added some bits for simplification. http://people.suug.ch/~tgr/libnl/doc/group__msg.html http://people.suug.ch/~tgr/libnl/doc/group__rtattr.html I do not care what to use though as long as it is easy to use. > Whether or not this sharing would be useful probably depends on if you > would continue to maintain your own non-GObject APIs for the various > QDiscs and classifiers. GObject makes the creation and maintenance of > the language bindings much easier so its basically necessary for my > goals. I see, well I can extend my objects, I'm even willing to change the architecture if needed. The only requirements from my side is to keep the generic caching header to allow putting these objects into generic caches and keep it simple to readd commit/rollback extesions later on. What is exactly required to make it GObject aware? I've never worked with GOBject so far. Basically a qdisc looks like this at the moment: struct rtnl_qdisc { NLHDR_COMMON; /* common fields required by cache */ NL_TCA_GENERIC(q); /* generic tc fields (parent, handle, ifindex ...) */ void *opts; /* qdisc specific options (e.g. rtnl_sch_fifo) */ }; The NLHDR_COMMON must stay first, the ordering of the others doesn't matter. > I'm willing to switch the underlying implementation of LQL to use your > more featureful NL implementation if that means there won't be two > competing C APIs to the individual QDiscs etc. It would be nice if we find a way to integrate both without losing the features of any side. From Gary.Spiess@Intermec.com Tue Feb 15 13:00:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:00:33 -0800 (PST) Received: from spiess2.norand.com (spiess2.norand.com [136.179.85.112]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FL0Sp1026320 for ; Tue, 15 Feb 2005 13:00:28 -0800 Received: from [136.179.85.111] (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id j1FLT6Th024785; Tue, 15 Feb 2005 15:29:06 -0600 Message-ID: <421262DF.9050503@Intermec.com> Date: Tue, 15 Feb 2005 15:00:15 -0600 From: Gary Spiess User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Manfred Spraul , Jeff Garzik Subject: Re: [PATCH] natsemi long cable fix References: <421129DE.4070101@Intermec.com> In-Reply-To: <421129DE.4070101@Intermec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 1898 Lines: 39 This is a minor modification to the previous patch submission that does not assume the default contents of the DSPCFG register are zero. When used with Revision D of the DP83815, the "Recommended Registers Configuration" from page 78 of the DP83815 data sheet is not entirely compatible with the driver's "short cable patch". When the DSPCFG register is written with the value suggested in the document, then do_cable_magic() can't read the DSP coefficient and determines that all cables attached to the DP83815D are 'short', regardless of actual length. Short cables (< 30m) cause do_cable_magic to enable additional attenuation to reduce CRC and idle errors. If the extra attenuation is unintentionally enabled for long cables (> 50m?), they will not operate properly. The National Semiconductor driver, 'dp83815.c' from http://www.national.com/appinfo/networks/files/linux_2_4.tar.gz was used as a basis for this modification. This patch applies to the driver distributed in linux-2.6.10. --- linux-2.6.10.orig/drivers/net/natsemi.c 2004-12-24 15:33:50.000000000 -0600 +++ linux-2.6.10/drivers/net/natsemi.c 2005-02-14 16:45:46.000000000 -0600 @@ -441,6 +441,7 @@ #define DSPCFG_VAL 0x5040 #define SDCFG_VAL 0x008c /* set voltage thresholds for Signal Detect */ #define DSPCFG_LOCK 0x20 /* coefficient lock bit in DSPCFG */ +#define DSPCFG_COEF 0x1000 /* see coefficient (in TSTDAT) bit in DSPCFG */ #define TSTDAT_FIXED 0xe8 /* magic number for bad coefficients */ /* misc PCI space registers */ @@ -1243,7 +1244,8 @@ writew(1, ioaddr + PGSEL); writew(PMDCSR_VAL, ioaddr + PMDCSR); writew(TSTDAT_VAL, ioaddr + TSTDAT); - np->dspcfg = DSPCFG_VAL; + np->dspcfg = (np->srr <= SRR_DP83815_C)? + DSPCFG_VAL : (DSPCFG_COEF | readw(ioaddr + DSPCFG)); writew(np->dspcfg, ioaddr + DSPCFG); writew(SDCFG_VAL, ioaddr + SDCFG); writew(0, ioaddr + PGSEL); From buytenh@wantstofly.org Tue Feb 15 13:10:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:10:28 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLALdA027155 for ; Tue, 15 Feb 2005 13:10:22 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 046282B0EC; Tue, 15 Feb 2005 22:10:20 +0100 (MET) Date: Tue, 15 Feb 2005 22:10:20 +0100 From: Lennert Buytenhek To: netdev@oss.sgi.com Subject: eepro100 broken on ARM by 2.6.11-rc1 changes Message-ID: <20050215211020.GB566@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1201 Lines: 34 Hi, eepro100 seems to have stopped working between 2.6.10 and 2.6.11-rc2 on an embedded ARM platform. In 2.6.10 I would see this: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth0: 0000:01:00.0, 00:00:50:14:56:11, IRQ 40. Receiver lock-up bug exists -- enabling work-around. Board assembly 698247-003, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x8b51f404). Receiver lock-up workaround activated. DLCI driver v0.35, 4 Jan 1997, mike.mclagan@linux.org. [...] But now I just see this: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others DLCI driver v0.35, 4 Jan 1997, mike.mclagan@linux.org. [...] Copying the eepro100 driver from 2.6.10 into 2.6.11-rc4 makes things work again on 2.6.11-rc4. Anyone else seeing this? cheers, Lennert From davem@davemloft.net Tue Feb 15 13:23:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:23:33 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLNRmN028090 for ; Tue, 15 Feb 2005 13:23:27 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1A7j-0007KI-00; Tue, 15 Feb 2005 13:20:47 -0800 Date: Tue, 15 Feb 2005 13:20:47 -0800 From: "David S. Miller" To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: eepro100 broken on ARM by 2.6.11-rc1 changes Message-Id: <20050215132047.7a33e6ec.davem@davemloft.net> In-Reply-To: <20050215211020.GB566@xi.wantstofly.org> References: <20050215211020.GB566@xi.wantstofly.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 451 Lines: 10 On Tue, 15 Feb 2005 22:10:20 +0100 Lennert Buytenhek wrote: > eepro100 seems to have stopped working between 2.6.10 and 2.6.11-rc2 > on an embedded ARM platform. In 2.6.10 I would see this: Please check to make sure ARM implements pci_iomap(), ioread*()/iowrite*() and friends correctly. eepro100 is one of the few net drivers that makes use of this newer API, and the conversion to using this new API occured post 2.6.10 From mallikarjuna.chilakala@intel.com Tue Feb 15 13:24:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:24:27 -0800 (PST) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLOL1U028368 for ; Tue, 15 Feb 2005 13:24:22 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLOG8x032687; Tue, 15 Feb 2005 21:24:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLNZBO009494; Tue, 15 Feb 2005 21:24:16 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513241600803 ; Tue, 15 Feb 2005 13:24:16 -0800 Date: Tue, 15 Feb 2005 13:24:16 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 0/10] e1000: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 685 Lines: 16 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1 Robert Olsson's fix and refinement to the poll routine 2 use netif_poll_{enable|disable} 3 Avoid race between e1000_watchdog and e1000_clean_tx_irq 4 Delay clean-up of last Tx buffer 5 Fix WOL settings in 82544 based adapters 6 Patch from Peter Kjellstroem -- fix lockup with 82547 7 Checks for desc ring/rx data bufs spanning 64k boundary 8 Report failure code when loopback test fails 9 Fixes related to Cable length estimation 10 Driver version white space, device id, comments & other From mallikarjuna.chilakala@intel.com Tue Feb 15 13:25:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:25:06 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLP2p3028825 for ; Tue, 15 Feb 2005 13:25:02 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLOum5023225; Tue, 15 Feb 2005 21:24:56 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLOsLl032298; Tue, 15 Feb 2005 21:24:56 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513245628495 ; Tue, 15 Feb 2005 13:24:56 -0800 Date: Tue, 15 Feb 2005 13:24:56 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 1/10] e1000: Robert Olsson's fix and refinement to the poll routine Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1310 Lines: 40 1 Robert Olsson's fix and refinement to the poll routine Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -2174,24 +2174,21 @@ e1000_clean(struct net_device *netdev, i int tx_cleaned; int work_done = 0; - if (!netif_carrier_ok(netdev)) - goto quit_polling; - tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - /* if no Rx and Tx cleanup work was done, exit the polling mode */ - if(!tx_cleaned || (work_done < work_to_do) || + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done < work_to_do)) || !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; } - return (work_done >= work_to_do); + return 1; } #endif From mallikarjuna.chilakala@intel.com Tue Feb 15 13:25:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:25:31 -0800 (PST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLPRx4029224 for ; Tue, 15 Feb 2005 13:25:27 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLPMf5023951; Tue, 15 Feb 2005 21:25:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLPLLh000337; Tue, 15 Feb 2005 21:25:21 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513252128548 ; Tue, 15 Feb 2005 13:25:21 -0800 Date: Tue, 15 Feb 2005 13:25:21 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 2/10] e1000: use netif_poll_{enable|disable} Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1127 Lines: 32 2 use netif_poll_{enable|disable} to synchronize between poll and i/f down/up Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -308,6 +308,9 @@ e1000_up(struct e1000_adapter *adapter) mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); +#ifdef CONFIG_E1000_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -321,6 +324,10 @@ e1000_down(struct e1000_adapter *adapter del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); + +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:25:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:25:59 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLPr5s029596 for ; Tue, 15 Feb 2005 13:25:53 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLPm8U020196; Tue, 15 Feb 2005 21:25:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLPjAw011308; Tue, 15 Feb 2005 21:25:48 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513254801077 ; Tue, 15 Feb 2005 13:25:48 -0800 Date: Tue, 15 Feb 2005 13:25:48 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 3/10] e1000: Avoid race between e1000_watchdog and e1000_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2487 Lines: 62 3 Avoid race condition between e1000_watchdog and e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h 2005-02-01 23:10:24.986106336 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h 2005-02-01 23:10:26.474880008 -0800 @@ -222,6 +222,7 @@ struct e1000_adapter { uint32_t tx_fifo_size; atomic_t tx_fifo_stall; boolean_t pcix_82544; + boolean_t detect_tx_hung; /* RX */ struct e1000_desc_ring rx_ring; diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -1432,7 +1432,6 @@ e1000_watchdog(unsigned long data) struct e1000_adapter *adapter = (struct e1000_adapter *) data; struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; uint32_t link; e1000_check_for_link(&adapter->hw); @@ -1512,12 +1511,8 @@ e1000_watchdog(unsigned long data) /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period*/ + adapter->detect_tx_hung = TRUE; /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -2245,6 +2240,16 @@ e1000_clean_tx_irq(struct e1000_adapter netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } From mallikarjuna.chilakala@intel.com Tue Feb 15 13:27:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:27:55 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLRoZo030582 for ; Tue, 15 Feb 2005 13:27:50 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLRhm5024876; Tue, 15 Feb 2005 21:27:45 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLRDMH001976; Tue, 15 Feb 2005 21:27:43 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513274225134 ; Tue, 15 Feb 2005 13:27:43 -0800 Date: Tue, 15 Feb 2005 13:27:43 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 4/10] e1000: Delay clean-up of last Tx buffer Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2860 Lines: 78 4 Delay clean-up of last Tx buffer to fix pre-mature writeback of Tx descriptors. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h 2005-02-01 23:10:24.986106336 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h 2005-02-01 23:10:26.474880008 -0800 @@ -209,6 +209,7 @@ struct e1000_adapter { /* TX */ struct e1000_desc_ring tx_ring; + struct e1000_buffer previous_buffer_info; spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -1103,6 +1103,7 @@ e1000_unmap_and_free_tx_resource(struct struct e1000_buffer *buffer_info) { struct pci_dev *pdev = adapter->pdev; + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, @@ -1131,6 +1132,11 @@ e1000_clean_tx_ring(struct e1000_adapter /* Free all the Tx ring sk_buffs */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(i = 0; i < tx_ring->count; i++) { buffer_info = &tx_ring->buffer_info[i]; e1000_unmap_and_free_tx_resource(adapter, buffer_info); @@ -2214,11 +2220,34 @@ e1000_clean_tx_irq(struct e1000_adapter eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { + /* pre-mature writeback of Tx descriptors */ + /* clear (free buffers and unmap pci_mapping) */ + /* previous_buffer_info */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; + cleaned = (i == eop); + + /* pre-mature writeback of Tx descriptors */ + /* save the cleaning of the this for the */ + /* next iteration */ + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, + 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); + } - e1000_unmap_and_free_tx_resource(adapter, buffer_info); tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; tx_desc->upper.data = 0; From mallikarjuna.chilakala@intel.com Tue Feb 15 13:28:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:28:27 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLSNWb030800 for ; Tue, 15 Feb 2005 13:28:23 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLSHdX022838; Tue, 15 Feb 2005 21:28:17 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLSGB0013299; Tue, 15 Feb 2005 21:28:17 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513281701476 ; Tue, 15 Feb 2005 13:28:17 -0800 Date: Tue, 15 Feb 2005 13:28:17 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 5/10] e1000: Fix WOL settings in 82544 based adapters Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1896 Lines: 51 5 Fix WOL settings in 82544 based adapters Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h 2005-02-01 23:10:24.986106336 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h 2005-02-01 23:10:26.474880008 -0800 @@ -138,6 +138,7 @@ struct e1000_adapter; #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ #define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0004 #define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -421,6 +421,7 @@ e1000_probe(struct pci_dev *pdev, int i; int err; uint16_t eeprom_data; + uint16_t eeprom_apme_mask = E1000_EEPROM_APME; if((err = pci_enable_device(pdev))) return err; @@ -591,6 +591,11 @@ e1000_probe(struct pci_dev *pdev, case e1000_82542_rev2_1: case e1000_82543: break; + case e1000_82544: + e1000_read_eeprom(&adapter->hw, + EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data); + eeprom_apme_mask = E1000_EEPROM_82544_APM; + break; case e1000_82546: case e1000_82546_rev_3: if((E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_FUNC_1) @@ -605,7 +611,7 @@ e1000_probe(struct pci_dev *pdev, EEPROM_INIT_CONTROL3_PORT_A, 1, &eeprom_data); break; } - if(eeprom_data & E1000_EEPROM_APME) + if(eeprom_data & eeprom_apme_mask) adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ From mallikarjuna.chilakala@intel.com Tue Feb 15 13:29:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:29:12 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLT8Tq031360 for ; Tue, 15 Feb 2005 13:29:08 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLT3m5025618; Tue, 15 Feb 2005 21:29:03 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLSnLv003212; Tue, 15 Feb 2005 21:29:02 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513290207669 ; Tue, 15 Feb 2005 13:29:02 -0800 Date: Tue, 15 Feb 2005 13:29:02 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 6/10] e1000: Patch from Peter Kjellstroem -- fix lockup with 82547 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1516 Lines: 39 6 Patch from Peter Kjellstroem -- fix lockup with 82547 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -2165,10 +2165,28 @@ e1000_intr(int irq, void *data, struct p __netif_rx_schedule(netdev); } #else + /* Writing IMC and IMS is needed for 82547. + Due to Hub Link bus being occupied, an interrupt + de-assertion message is not able to be sent. + When an interrupt assertion message is generated later, + two messages are re-ordered and sent out. + That causes APIC to think 82547 is in de-assertion + state, while 82547 is in assertion state, resulting + in dead lock. Writing IMC forces 82547 into + de-assertion state. + */ + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + } + for(i = 0; i < E1000_MAX_INTR; i++) if(unlikely(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter))) break; + + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) + e1000_irq_enable(adapter); #endif return IRQ_HANDLED; From mallikarjuna.chilakala@intel.com Tue Feb 15 13:30:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:31:03 -0800 (PST) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLUwpS032086 for ; Tue, 15 Feb 2005 13:30:59 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLUrB8019990; Tue, 15 Feb 2005 21:30:53 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLUgLp004832; Tue, 15 Feb 2005 21:30:53 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513305225511 ; Tue, 15 Feb 2005 13:30:52 -0800 Date: Tue, 15 Feb 2005 13:30:52 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 7/10] e1000: Checks for desc ring/rx data bufs spanning 64k boundary Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 6555 Lines: 202 7 Add checks for desc ring/rx data bufs spanning 64k address boundary Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -820,6 +820,31 @@ e1000_close(struct net_device *netdev) } /** + * e1000_check_64k_bound - check that memory doesn't cross 64kB boundary + * @adapter: address of board private structure + * @begin: address of beginning of memory + * @end: address of end of memory + **/ +static inline boolean_t +e1000_check_64k_bound(struct e1000_adapter *adapter, + void *start, unsigned long len) +{ + unsigned long begin = (unsigned long) start; + unsigned long end = begin + len; + + /* first rev 82545 and 82546 need to not allow any memory + * write location to cross a 64k boundary due to errata 23 */ + if (adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546 ) { + + /* check buffer doesn't cross 64kB */ + return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; + } + + return TRUE; +} + +/** * e1000_setup_tx_resources - allocate Tx resources (Descriptors) * @adapter: board private structure * @@ -849,11 +873,42 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { +setup_tx_desc_die: DPRINTK(PROBE, ERR, "Unble to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + void *olddesc = txdr->desc; + dma_addr_t olddma = txdr->dma; + DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", + txdr->size, txdr->desc); + /* try again, without freeing the previous */ + txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); + /* failed allocation, critial failure */ + if(!txdr->desc) { + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + goto setup_tx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + /* give up */ + pci_free_consistent(pdev, txdr->size, + txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the Transmit" + " descriptor ring\n"); + vfree(txdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + } + } memset(txdr->desc, 0, txdr->size); txdr->next_to_use = 0; @@ -971,11 +1027,43 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { +setup_rx_desc_die: DPRINTK(PROBE, ERR, "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + void *olddesc = rxdr->desc; + dma_addr_t olddma = rxdr->dma; + DPRINTK(RX_ERR,ERR, + "rxdr align check failed: %u bytes at %p\n", + rxdr->size, rxdr->desc); + /* try again, without freeing the previous */ + rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); + /* failed allocation, critial failure */ + if(!rxdr->desc) { + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + goto setup_rx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + /* give up */ + pci_free_consistent(pdev, rxdr->size, + rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the" + " Receive descriptor ring\n"); + vfree(rxdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + } + } memset(rxdr->desc, 0, rxdr->size); rxdr->next_to_clean = 0; @@ -2469,19 +2557,43 @@ e1000_alloc_rx_buffers(struct e1000_adap struct e1000_rx_desc *rx_desc; struct e1000_buffer *buffer_info; struct sk_buff *skb; - unsigned int i; + unsigned int i, bufsz; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); + bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; + skb = dev_alloc_skb(bufsz); if(unlikely(!skb)) { /* Better luck next round */ break; } + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + struct sk_buff *oldskb = skb; + DPRINTK(RX_ERR,ERR, + "skb align check failed: %u bytes at %p\n", + bufsz, skb->data); + /* try again, without freeing the previous */ + skb = dev_alloc_skb(bufsz); + if (!skb) { + dev_kfree_skb(oldskb); + break; + } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + /* give up */ + dev_kfree_skb(skb); + dev_kfree_skb(oldskb); + break; /* while !buffer_info->skb */ + } else { + /* move on with the new one */ + dev_kfree_skb(oldskb); + } + } + /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -2497,6 +2609,25 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + /* fix for errata 23, cant cross 64kB boundary */ + if(!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR,ERR, + "dma align check failed: %u bytes at %ld\n", + adapter->rx_buffer_len, (unsigned long)buffer_info->dma); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } + rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:31:16 -0800 (PST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLVCGB032132 for ; Tue, 15 Feb 2005 13:31:12 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLV7f5026267; Tue, 15 Feb 2005 21:31:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLV2Ll005167; Tue, 15 Feb 2005 21:31:07 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513310629287 ; Tue, 15 Feb 2005 13:31:06 -0800 Date: Tue, 15 Feb 2005 13:31:06 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 8/10] e1000: Report failure code when loopback test fails Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 37 8 Report failure code when loopback test fails Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c 2005-02-01 23:10:24.985106488 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c 2005-02-01 23:10:26.421888064 -0800 @@ -1310,7 +1310,7 @@ e1000_run_loopback_test(struct e1000_ada struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i; + int i, ret_val; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); @@ -1330,11 +1330,12 @@ e1000_run_loopback_test(struct e1000_ada rxdr->buffer_info[i].length, PCI_DMA_FROMDEVICE); - if (!e1000_check_lbtest_frame(rxdr->buffer_info[i++].skb, 1024)) - return 0; - } while (i < 64); + ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, + 1024); + i++; + } while (ret_val != 0 && i < 64); - return 13; + return ret_val; } static int From mallikarjuna.chilakala@intel.com Tue Feb 15 13:32:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:32:19 -0800 (PST) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLWFdO000601 for ; Tue, 15 Feb 2005 13:32:15 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLWA8x003811; Tue, 15 Feb 2005 21:32:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLVnBC016682; Tue, 15 Feb 2005 21:32:10 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513321002389 ; Tue, 15 Feb 2005 13:32:10 -0800 Date: Tue, 15 Feb 2005 13:32:10 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 10/10] e1000: Driver version white space, device id, comments & other Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 6697 Lines: 156 10 Driver version number, white space, comments, device id & other changes Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.c net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.6/drivers/net/e1000/e1000_hw.c 2005-02-01 23:10:24.987106184 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c 2005-02-01 23:10:26.569865568 -0800 @@ -1572,7 +1572,8 @@ e1000_phy_force_speed_duplex(struct e100 if(mii_status_reg & MII_SR_LINK_STATUS) break; msec_delay(100); } - if((i == 0) && (hw->phy_type == e1000_phy_m88)) { + if((i == 0) && + (hw->phy_type == e1000_phy_m88)) { /* We didn't get link. Reset the DSP and wait again for link. */ ret_val = e1000_phy_reset_dsp(hw); if(ret_val) { @@ -2955,8 +2956,7 @@ e1000_phy_m88_get_info(struct e1000_hw * /* Check polarity status */ ret_val = e1000_check_polarity(hw, &polarity); if(ret_val) - return ret_val; - + return ret_val; phy_info->cable_polarity = polarity; ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); @@ -4924,8 +4924,7 @@ e1000_check_downshift(struct e1000_hw *h return ret_val; hw->speed_downgraded = (phy_data & IGP01E1000_PLHR_SS_DOWNGRADE) ? 1 : 0; - } - else if(hw->phy_type == e1000_phy_m88) { + } else if(hw->phy_type == e1000_phy_m88) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); if(ret_val) diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.h net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.6/drivers/net/e1000/e1000_hw.h 2005-02-01 23:10:24.988106032 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h 2005-02-01 23:10:26.638855080 -0800 @@ -369,6 +369,7 @@ int32_t e1000_set_d3_lplu_state(struct e #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 + #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 @@ -1734,6 +1735,9 @@ struct e1000_hw { #define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */ #define PHY_EXT_STATUS 0x0F /* Extended Status Reg */ +#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ +#define MAX_PHY_MULTI_PAGE_REG 0xF /* Registers equal on all pages */ + /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ #define M88E1000_PHY_SPEC_STATUS 0x11 /* PHY Specific Status Register */ @@ -1794,8 +1798,7 @@ struct e1000_hw { #define IGP01E1000_ANALOG_REGS_PAGE 0x20C0 -#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ -#define MAX_PHY_MULTI_PAGE_REG 0xF /*Registers that are equal on all pages*/ + /* PHY Control Register */ #define MII_CR_SPEED_SELECT_MSB 0x0040 /* bits 6,13: 10=1000, 01=100, 00=10 */ #define MII_CR_COLL_TEST_ENABLE 0x0080 /* Collision test enable */ @@ -2098,7 +2101,11 @@ struct e1000_hw { #define IGP01E1000_ANALOG_FUSE_FINE_1 0x0080 #define IGP01E1000_ANALOG_FUSE_FINE_10 0x0500 + /* Bit definitions for valid PHY IDs. */ +/* I = Integrated + * E = External + */ #define M88E1000_E_PHY_ID 0x01410C50 #define M88E1000_I_PHY_ID 0x01410C30 #define M88E1011_I_PHY_ID 0x01410C20 diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 @@ -35,6 +35,14 @@ * - More errlogging support from Jon Mason * - Fix TSO issues on PPC64 machines -- Jon Mason * + * 5.7.1 12/16/04 + * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This + * fix was removed as it caused system instability. The suspected cause of + * this is the called to e1000_irq_disable in e1000_intr. Inlined the + * required piece of e1000_irq_disable into e1000_intr - Anton Blanchard + * 5.7.0 12/10/04 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 5.6.5 11/01/04 * - Enabling NETIF_F_SG without checksum offload is illegal - John Mason @@ -57,7 +57,7 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.6.10.1-k2"DRIVERNAPI; +char e1000_driver_version[] = "5.7.6-k2"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -81,6 +89,7 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x1011), INTEL_E1000_ETHERNET_DEVICE(0x1012), INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1014), INTEL_E1000_ETHERNET_DEVICE(0x1015), INTEL_E1000_ETHERNET_DEVICE(0x1016), INTEL_E1000_ETHERNET_DEVICE(0x1017), @@ -518,9 +527,6 @@ e1000_probe(struct pci_dev *pdev, } #ifdef NETIF_F_TSO - /* Disbaled for now until root-cause is found for - * hangs reported against non-IA archs. TSO can be - * enabled using ethtool -K eth tso on */ if((adapter->hw.mac_type >= e1000_82544) && (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; @@ -862,7 +868,7 @@ e1000_setup_tx_resources(struct e1000_ad txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -876,7 +867,7 @@ e1000_setup_tx_resources(struct e1000_ad if(!txdr->desc) { setup_tx_desc_die: DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } @@ -1014,7 +1020,7 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Recieve descriptor ring\n"); + "Unable to Allocate Memory for the Recieve descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:32:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:32:37 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLWXj4000696 for ; Tue, 15 Feb 2005 13:32:33 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLWSLF026194; Tue, 15 Feb 2005 21:32:28 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLVvBK016783; Tue, 15 Feb 2005 21:32:28 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513322602449 ; Tue, 15 Feb 2005 13:32:26 -0800 Date: Tue, 15 Feb 2005 13:32:26 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 0/10] e1000: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 687 Lines: 17 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1 Robert Olsson's fix and refinement to the poll routine 2 use netif_poll_{enable|disable} 3 Avoid race between e1000_watchdog and e1000_clean_tx_irq 4 Delay clean-up of last Tx buffer 5 Fix WOL settings in 82544 based adapters 6 Patch from Peter Kjellstroem -- fix lockup with 82547 7 Checks for desc ring/rx data bufs spanning 64k boundary 8 Report failure code when loopback test fails 9 Fixes related to Cable length estimation 10 Driver version white space, device id, comments & other From mallikarjuna.chilakala@intel.com Tue Feb 15 13:33:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:33:04 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLX057001101 for ; Tue, 15 Feb 2005 13:33:00 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLWtLF026392; Tue, 15 Feb 2005 21:32:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLVvBq016783; Tue, 15 Feb 2005 21:32:54 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513325402541 ; Tue, 15 Feb 2005 13:32:54 -0800 Date: Tue, 15 Feb 2005 13:32:54 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 1/10] e1000: 1 Robert Olsson's fix and refinement to the poll routine Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 40 1 Rober Olsson's fix and refinement to the poll routine Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -2155,24 +2155,21 @@ e1000_clean(struct net_device *netdev, i int tx_cleaned; int work_done = 0; - if (!netif_carrier_ok(netdev)) - goto quit_polling; - tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - /* if no Rx and Tx cleanup work was done, exit the polling mode */ - if(!tx_cleaned || (work_done < work_to_do) || + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done < work_to_do)) || !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; } - return (work_done >= work_to_do); + return 1; } #endif From mallikarjuna.chilakala@intel.com Tue Feb 15 13:33:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:33:19 -0800 (PST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLXCvT001351 for ; Tue, 15 Feb 2005 13:33:14 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLX7f5026931; Tue, 15 Feb 2005 21:33:07 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLX7Lh006935; Tue, 15 Feb 2005 21:33:07 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513330710875 ; Tue, 15 Feb 2005 13:33:07 -0800 Date: Tue, 15 Feb 2005 13:33:07 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 2/10] e1000: 2 use netif_poll_{enable|disable} Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1127 Lines: 32 2 use netif_poll_{enable|disable} to synchronize between poll and i/f down/up Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -303,6 +303,9 @@ e1000_up(struct e1000_adapter *adapter) mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); +#ifdef CONFIG_E1000_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -316,6 +319,10 @@ e1000_down(struct e1000_adapter *adapter del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); + +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:33:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:33:33 -0800 (PST) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLXRvg001626 for ; Tue, 15 Feb 2005 13:33:27 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLXMB8021312; Tue, 15 Feb 2005 21:33:22 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLXMLh007121; Tue, 15 Feb 2005 21:33:22 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513332208208 ; Tue, 15 Feb 2005 13:33:22 -0800 Date: Tue, 15 Feb 2005 13:33:22 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 3/10] e1000: Avoid race between e1000_watchdog and e1000_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2487 Lines: 62 3 Avoid race condition between e1000_watchdog and e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h 2005-02-01 23:21:49.120102160 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h 2005-02-01 23:21:50.386909576 -0800 @@ -224,6 +224,7 @@ struct e1000_adapter { uint32_t tx_fifo_size; atomic_t tx_fifo_stall; boolean_t pcix_82544; + boolean_t detect_tx_hung; /* RX */ struct e1000_desc_ring rx_ring; diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -1422,7 +1422,6 @@ e1000_watchdog(unsigned long data) struct e1000_adapter *adapter = (struct e1000_adapter *) data; struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; uint32_t link; e1000_check_for_link(&adapter->hw); @@ -1502,12 +1501,8 @@ e1000_watchdog(unsigned long data) /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period*/ + adapter->detect_tx_hung = TRUE; /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -2226,6 +2221,16 @@ e1000_clean_tx_irq(struct e1000_adapter netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } From mallikarjuna.chilakala@intel.com Tue Feb 15 13:34:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:34:17 -0800 (PST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLYC75002424 for ; Tue, 15 Feb 2005 13:34:12 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLY7f5027462; Tue, 15 Feb 2005 21:34:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLY7Lh008124; Tue, 15 Feb 2005 21:34:07 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513340629717 ; Tue, 15 Feb 2005 13:34:06 -0800 Date: Tue, 15 Feb 2005 13:34:06 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 4/10] e1000: Delay clean-up of last Tx buffer Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2860 Lines: 78 4 Delay clean-up of last Tx buffer to fix pre-mature writeback of Tx descriptors. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h 2005-02-01 23:21:49.120102160 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h 2005-02-01 23:21:50.386909576 -0800 @@ -211,6 +211,7 @@ struct e1000_adapter { /* TX */ struct e1000_desc_ring tx_ring; + struct e1000_buffer previous_buffer_info; spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -1093,6 +1093,7 @@ e1000_unmap_and_free_tx_resource(struct struct e1000_buffer *buffer_info) { struct pci_dev *pdev = adapter->pdev; + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, @@ -1121,6 +1122,11 @@ e1000_clean_tx_ring(struct e1000_adapter /* Free all the Tx ring sk_buffs */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(i = 0; i < tx_ring->count; i++) { buffer_info = &tx_ring->buffer_info[i]; e1000_unmap_and_free_tx_resource(adapter, buffer_info); @@ -2195,11 +2201,34 @@ e1000_clean_tx_irq(struct e1000_adapter eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { + /* pre-mature writeback of Tx descriptors */ + /* clear (free buffers and unmap pci_mapping) */ + /* previous_buffer_info */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; + cleaned = (i == eop); + + /* pre-mature writeback of Tx descriptors */ + /* save the cleaning of the this for the */ + /* next iteration */ + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, + 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); + } - e1000_unmap_and_free_tx_resource(adapter, buffer_info); tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; tx_desc->upper.data = 0; From mallikarjuna.chilakala@intel.com Tue Feb 15 13:34:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:34:41 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLYZIs002841 for ; Tue, 15 Feb 2005 13:34:35 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLYUm5029278; Tue, 15 Feb 2005 21:34:30 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLYLLr008463; Tue, 15 Feb 2005 21:34:30 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513342926011 ; Tue, 15 Feb 2005 13:34:29 -0800 Date: Tue, 15 Feb 2005 13:34:30 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 5/10] e1000: Fix WOL settings in 82544 based adapters Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1897 Lines: 52 5 Fix WOL settings in 82544 based adapters Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h 2005-02-01 23:21:49.120102160 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h 2005-02-01 23:21:50.386909576 -0800 @@ -140,6 +140,7 @@ struct e1000_adapter; #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ #define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0004 #define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -416,6 +416,7 @@ e1000_probe(struct pci_dev *pdev, int i; int err; uint16_t eeprom_data; + uint16_t eeprom_apme_mask = E1000_EEPROM_APME; if((err = pci_enable_device(pdev))) return err; @@ -583,6 +584,11 @@ e1000_probe(struct pci_dev *pdev, case e1000_82542_rev2_1: case e1000_82543: break; + case e1000_82544: + e1000_read_eeprom(&adapter->hw, + EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data); + eeprom_apme_mask = E1000_EEPROM_82544_APM; + break; case e1000_82546: case e1000_82546_rev_3: if((E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_FUNC_1) @@ -597,7 +603,7 @@ e1000_probe(struct pci_dev *pdev, EEPROM_INIT_CONTROL3_PORT_A, 1, &eeprom_data); break; } - if(eeprom_data & E1000_EEPROM_APME) + if(eeprom_data & eeprom_apme_mask) adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ From mallikarjuna.chilakala@intel.com Tue Feb 15 13:34:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:34:59 -0800 (PST) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLYrGN003170 for ; Tue, 15 Feb 2005 13:34:54 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLYlP7009867; Tue, 15 Feb 2005 21:34:47 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLYLM5008463; Tue, 15 Feb 2005 21:34:47 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513344626043 ; Tue, 15 Feb 2005 13:34:47 -0800 Date: Tue, 15 Feb 2005 13:34:47 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 6/10] e1000: Patch from Peter Kjellstroem -- fix lockup with 82547 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1517 Lines: 40 6 Patch from Peter Kjellstroem -- fix lockup with 82547 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -2146,10 +2146,28 @@ e1000_intr(int irq, void *data, struct p __netif_rx_schedule(netdev); } #else + /* Writing IMC and IMS is needed for 82547. + Due to Hub Link bus being occupied, an interrupt + de-assertion message is not able to be sent. + When an interrupt assertion message is generated later, + two messages are re-ordered and sent out. + That causes APIC to think 82547 is in de-assertion + state, while 82547 is in assertion state, resulting + in dead lock. Writing IMC forces 82547 into + de-assertion state. + */ + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + } + for(i = 0; i < E1000_MAX_INTR; i++) if(unlikely(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter))) break; + + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) + e1000_irq_enable(adapter); #endif return IRQ_HANDLED; From mallikarjuna.chilakala@intel.com Tue Feb 15 13:35:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:35:46 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLZfDm004040 for ; Tue, 15 Feb 2005 13:35:41 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLZam5030012; Tue, 15 Feb 2005 21:35:36 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLZaLh009532; Tue, 15 Feb 2005 21:35:36 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513353529916 ; Tue, 15 Feb 2005 13:35:35 -0800 Date: Tue, 15 Feb 2005 13:35:35 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 7/10] e1000: Checks for desc ring/rx data bufs spanning 64k boundary Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 6546 Lines: 203 7 Add checks for desc ring/rx data bufs spanning 64k address boundary Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -810,6 +810,31 @@ e1000_close(struct net_device *netdev) } /** + * e1000_check_64k_bound - check that memory doesn't cross 64kB boundary + * @adapter: address of board private structure + * @begin: address of beginning of memory + * @end: address of end of memory + **/ +static inline boolean_t +e1000_check_64k_bound(struct e1000_adapter *adapter, + void *start, unsigned long len) +{ + unsigned long begin = (unsigned long) start; + unsigned long end = begin + len; + + /* first rev 82545 and 82546 need to not allow any memory + * write location to cross a 64k boundary due to errata 23 */ + if (adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546 ) { + + /* check buffer doesn't cross 64kB */ + return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; + } + + return TRUE; +} + +/** * e1000_setup_tx_resources - allocate Tx resources (Descriptors) * @adapter: board private structure * @@ -839,11 +864,42 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { +setup_tx_desc_die: DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + void *olddesc = txdr->desc; + dma_addr_t olddma = txdr->dma; + DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", + txdr->size, txdr->desc); + /* try again, without freeing the previous */ + txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); + /* failed allocation, critial failure */ + if(!txdr->desc) { + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + goto setup_tx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + /* give up */ + pci_free_consistent(pdev, txdr->size, + txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the Transmit" + " descriptor ring\n"); + vfree(txdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + } + } memset(txdr->desc, 0, txdr->size); txdr->next_to_use = 0; @@ -961,11 +995,43 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { +setup_rx_desc_die: DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + void *olddesc = rxdr->desc; + dma_addr_t olddma = rxdr->dma; + DPRINTK(RX_ERR,ERR, + "rxdr align check failed: %u bytes at %p\n", + rxdr->size, rxdr->desc); + /* try again, without freeing the previous */ + rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); + /* failed allocation, critial failure */ + if(!rxdr->desc) { + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + goto setup_rx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + /* give up */ + pci_free_consistent(pdev, rxdr->size, + rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the" + " Receive descriptor ring\n"); + vfree(rxdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + } + } memset(rxdr->desc, 0, rxdr->size); rxdr->next_to_clean = 0; @@ -2451,20 +2455,43 @@ e1000_alloc_rx_buffers(struct e1000_adap struct e1000_buffer *buffer_info; struct sk_buff *skb; int reserve_len = 2; - unsigned int i; + unsigned int i, bufsz; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { + bufsz = adapter->rx_buffer_len + reserve_len; - skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); - + skb = dev_alloc_skb(bufsz); if(unlikely(!skb)) { /* Better luck next round */ break; } + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + struct sk_buff *oldskb = skb; + DPRINTK(RX_ERR,ERR, + "skb align check failed: %u bytes at %p\n", + bufsz, skb->data); + /* try again, without freeing the previous */ + skb = dev_alloc_skb(bufsz); + if (!skb) { + dev_kfree_skb(oldskb); + break; + } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + /* give up */ + dev_kfree_skb(skb); + dev_kfree_skb(oldskb); + break; /* while !buffer_info->skb */ + } else { + /* move on with the new one */ + dev_kfree_skb(oldskb); + } + } + /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -2480,6 +2591,25 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + /* fix for errata 23, cant cross 64kB boundary */ + if(!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR,ERR, + "dma align check failed: %u bytes at %ld\n", + adapter->rx_buffer_len, (unsigned long)buffer_info->dma); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } + rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:35:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:35:59 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLZttX004291 for ; Tue, 15 Feb 2005 13:35:55 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLZom5030159; Tue, 15 Feb 2005 21:35:50 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLZkLj009684; Tue, 15 Feb 2005 21:35:50 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513354911192 ; Tue, 15 Feb 2005 13:35:50 -0800 Date: Tue, 15 Feb 2005 13:35:49 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 8/10] e1000: Report failure code when loopback test fails Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 37 8 Report failure code when loopback test fails Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c 2005-02-01 23:21:49.119102312 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c 2005-02-01 23:21:50.368912312 -0800 @@ -1309,7 +1309,7 @@ e1000_run_loopback_test(struct e1000_ada struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i; + int i, ret_val; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); @@ -1329,11 +1331,12 @@ e1000_run_loopback_test(struct e1000_ada rxdr->buffer_info[i].length, PCI_DMA_FROMDEVICE); - if (!e1000_check_lbtest_frame(rxdr->buffer_info[i++].skb, 1024)) - return 0; - } while (i < 64); + ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, + 1024); + i++; + } while (ret_val != 0 && i < 64); - return 13; + return ret_val; } static int From mallikarjuna.chilakala@intel.com Tue Feb 15 13:36:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:36:18 -0800 (PST) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLaAPH004577 for ; Tue, 15 Feb 2005 13:36:10 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLa5P7010317; Tue, 15 Feb 2005 21:36:05 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLa5Lh009904; Tue, 15 Feb 2005 21:36:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513360511220 ; Tue, 15 Feb 2005 13:36:05 -0800 Date: Tue, 15 Feb 2005 13:36:05 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 9/10] e1000: Fixes related to Cable length estimation Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 5705 Lines: 138 9 Fixes related to Cable length estimation Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.c net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.4/drivers/net/e1000/e1000_hw.c 2005-02-01 23:21:49.121102008 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c 2005-02-01 23:21:50.444900760 -0800 @@ -2504,7 +2504,7 @@ e1000_read_phy_reg(struct e1000_hw *hw, } } - ret_val = e1000_read_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_read_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2610,7 +2610,7 @@ e1000_write_phy_reg(struct e1000_hw *hw, } } - ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_write_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2967,9 +2967,9 @@ e1000_phy_m88_get_info(struct e1000_hw * phy_info->mdix_mode = (phy_data & M88E1000_PSSR_MDIX) >> M88E1000_PSSR_MDIX_SHIFT; - if(phy_data & M88E1000_PSSR_1000MBS) { - /* Cable Length Estimation and Local/Remote Receiver Informatoion - * are only valid at 1000 Mbps + if ((phy_data & M88E1000_PSSR_SPEED) == M88E1000_PSSR_1000MBS) { + /* Cable Length Estimation and Local/Remote Receiver Information + * are only valid at 1000 Mbps. */ phy_info->cable_length = ((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> M88E1000_PSSR_CABLE_LENGTH_SHIFT); @@ -4641,41 +4641,44 @@ e1000_get_bus_info(struct e1000_hw *hw) { uint32_t status; - if(hw->mac_type < e1000_82543) { + switch (hw->mac_type) { + case e1000_82542_rev2_0: + case e1000_82542_rev2_1: hw->bus_type = e1000_bus_type_unknown; hw->bus_speed = e1000_bus_speed_unknown; hw->bus_width = e1000_bus_width_unknown; - return; - } - - status = E1000_READ_REG(hw, STATUS); - hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? - e1000_bus_type_pcix : e1000_bus_type_pci; + break; + default: + status = E1000_READ_REG(hw, STATUS); + hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? + e1000_bus_type_pcix : e1000_bus_type_pci; - if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { - hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? - e1000_bus_speed_66 : e1000_bus_speed_120; - } else if(hw->bus_type == e1000_bus_type_pci) { - hw->bus_speed = (status & E1000_STATUS_PCI66) ? - e1000_bus_speed_66 : e1000_bus_speed_33; - } else { - switch (status & E1000_STATUS_PCIX_SPEED) { - case E1000_STATUS_PCIX_SPEED_66: - hw->bus_speed = e1000_bus_speed_66; - break; - case E1000_STATUS_PCIX_SPEED_100: - hw->bus_speed = e1000_bus_speed_100; - break; - case E1000_STATUS_PCIX_SPEED_133: - hw->bus_speed = e1000_bus_speed_133; - break; - default: - hw->bus_speed = e1000_bus_speed_reserved; - break; + if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { + hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? + e1000_bus_speed_66 : e1000_bus_speed_120; + } else if(hw->bus_type == e1000_bus_type_pci) { + hw->bus_speed = (status & E1000_STATUS_PCI66) ? + e1000_bus_speed_66 : e1000_bus_speed_33; + } else { + switch (status & E1000_STATUS_PCIX_SPEED) { + case E1000_STATUS_PCIX_SPEED_66: + hw->bus_speed = e1000_bus_speed_66; + break; + case E1000_STATUS_PCIX_SPEED_100: + hw->bus_speed = e1000_bus_speed_100; + break; + case E1000_STATUS_PCIX_SPEED_133: + hw->bus_speed = e1000_bus_speed_133; + break; + default: + hw->bus_speed = e1000_bus_speed_reserved; + break; + } } + hw->bus_width = (status & E1000_STATUS_BUS64) ? + e1000_bus_width_64 : e1000_bus_width_32; + break; } - hw->bus_width = (status & E1000_STATUS_BUS64) ? - e1000_bus_width_64 : e1000_bus_width_32; } /****************************************************************************** * Reads a value from one of the devices registers using port I/O (as opposed @@ -4740,6 +4743,7 @@ e1000_get_cable_length(struct e1000_hw * uint16_t agc_value = 0; uint16_t cur_agc, min_agc = IGP01E1000_AGC_LENGTH_TABLE_SIZE; uint16_t i, phy_data; + uint16_t cable_length; DEBUGFUNC("e1000_get_cable_length"); @@ -4751,10 +4750,11 @@ e1000_get_cable_length(struct e1000_hw * &phy_data); if(ret_val) return ret_val; + cable_length = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >> + M88E1000_PSSR_CABLE_LENGTH_SHIFT; /* Convert the enum value to ranged values */ - switch((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> - M88E1000_PSSR_CABLE_LENGTH_SHIFT) { + switch (cable_length) { case e1000_cable_length_50: *min_length = 0; *max_length = e1000_igp_cable_length_50; From mallikarjuna.chilakala@intel.com Tue Feb 15 13:36:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:36:30 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLaN3w004804 for ; Tue, 15 Feb 2005 13:36:23 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLaILF027980; Tue, 15 Feb 2005 21:36:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLaDAw020466; Tue, 15 Feb 2005 21:36:18 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513361803373 ; Tue, 15 Feb 2005 13:36:18 -0800 Date: Tue, 15 Feb 2005 13:36:18 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.4 10/10] e1000: Driver version white space, device id, comments & other Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 6742 Lines: 160 10 Driver version number, white space, comments, device id & other changes Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.c net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.4/drivers/net/e1000/e1000_hw.c 2005-02-01 23:21:49.121102008 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c 2005-02-01 23:21:50.444900760 -0800 @@ -1573,7 +1573,8 @@ e1000_phy_force_speed_duplex(struct e100 if(mii_status_reg & MII_SR_LINK_STATUS) break; msec_delay(100); } - if((i == 0) && (hw->phy_type == e1000_phy_m88)) { + if((i == 0) && + (hw->phy_type == e1000_phy_m88)) { /* We didn't get link. Reset the DSP and wait again for link. */ ret_val = e1000_phy_reset_dsp(hw); if(ret_val) { @@ -2956,8 +2957,7 @@ e1000_phy_m88_get_info(struct e1000_hw * /* Check polarity status */ ret_val = e1000_check_polarity(hw, &polarity); if(ret_val) - return ret_val; - + return ret_val; phy_info->cable_polarity = polarity; ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); @@ -4926,8 +4926,7 @@ e1000_check_downshift(struct e1000_hw *h return ret_val; hw->speed_downgraded = (phy_data & IGP01E1000_PLHR_SS_DOWNGRADE) ? 1 : 0; - } - else if(hw->phy_type == e1000_phy_m88) { + } else if(hw->phy_type == e1000_phy_m88) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); if(ret_val) diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.h net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.4/drivers/net/e1000/e1000_hw.h 2005-02-01 23:21:49.121102008 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h 2005-02-01 23:21:50.480895288 -0800 @@ -36,7 +36,6 @@ #include "e1000_osdep.h" - /* Forward declarations of structures used by the shared code */ struct e1000_hw; struct e1000_hw_stats; @@ -370,6 +369,7 @@ int32_t e1000_set_d3_lplu_state(struct e #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 + #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 @@ -1735,6 +1735,9 @@ struct e1000_hw { #define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */ #define PHY_EXT_STATUS 0x0F /* Extended Status Reg */ +#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ +#define MAX_PHY_MULTI_PAGE_REG 0xF /* Registers equal on all pages */ + /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ #define M88E1000_PHY_SPEC_STATUS 0x11 /* PHY Specific Status Register */ @@ -1795,8 +1798,7 @@ struct e1000_hw { #define IGP01E1000_ANALOG_REGS_PAGE 0x20C0 -#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ -#define MAX_PHY_MULTI_PAGE_REG 0xF /*Registers that are equal on all pages*/ + /* PHY Control Register */ #define MII_CR_SPEED_SELECT_MSB 0x0040 /* bits 6,13: 10=1000, 01=100, 00=10 */ #define MII_CR_COLL_TEST_ENABLE 0x0080 /* Collision test enable */ @@ -2099,7 +2101,11 @@ struct e1000_hw { #define IGP01E1000_ANALOG_FUSE_FINE_1 0x0080 #define IGP01E1000_ANALOG_FUSE_FINE_10 0x0500 + /* Bit definitions for valid PHY IDs. */ +/* I = Integrated + * E = External + */ #define M88E1000_E_PHY_ID 0x01410C50 #define M88E1000_I_PHY_ID 0x01410C30 #define M88E1011_I_PHY_ID 0x01410C20 diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-02-01 23:21:49.122101856 -0800 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:21:50.517889664 -0800 @@ -34,6 +34,14 @@ * - if_mii support and associated kcompat for older kernels * - More errlogging support from Jon Mason * - Fix TSO issues on PPC64 machines -- Jon Mason + * 5.7.1 12/16/04 + * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This + * fix was removed as it caused system instability. The suspected cause of + * this is the called to e1000_irq_disable in e1000_intr. Inlined the + * required piece of e1000_irq_disable into e1000_intr. + * 5.7.0 12/10/04 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 5.6.5 11/01/04 * - Enabling NETIF_F_SG without checksum offload is illegal - John Mason @@ -41,8 +41,13 @@ * - Remove redundant initialization - Jamal Hadi * - Reset buffer_info->dma in tx resource cleanup logic * 5.6.2 10/12/04 + * - Avoid filling tx_ring completely - shemminger@osdl.org + * - Replace schedule_timeout() with msleep()/msleep_interruptible() - + * nacc@us.ibm.com * - Sparse cleanup - shemminger@osdl.org * - Fix tx resource cleanup logic + * - LLTX support - ak@suse.de and hadi@cyberus.ca + * - {set, get}_wol is now symmetric for 82545EM adapters */ char e1000_driver_name[] = "e1000"; @@ -52,7 +52,7 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.6.10.1-k1"DRIVERNAPI; +char e1000_driver_version[] = "5.7.6-k1"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -76,6 +89,7 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x1011), INTEL_E1000_ETHERNET_DEVICE(0x1012), INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1014), INTEL_E1000_ETHERNET_DEVICE(0x1015), INTEL_E1000_ETHERNET_DEVICE(0x1016), INTEL_E1000_ETHERNET_DEVICE(0x1017), @@ -513,9 +527,6 @@ e1000_probe(struct pci_dev *pdev, } #ifdef NETIF_F_TSO - /* Disbaled for now until root-cause is found for - * hangs reported against non-IA archs. TSO can be - * enabled using ethtool -K eth tso on */ if((adapter->hw.mac_type >= e1000_82544) && (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; @@ -1019,7 +984,7 @@ e1000_setup_rx_resources(struct e1000_ad if(!rxdr->desc) { setup_rx_desc_die: DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Recieve descriptor ring\n"); + "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } From mallikarjuna.chilakala@intel.com Tue Feb 15 13:37:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:37:15 -0800 (PST) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLbAaF005649 for ; Tue, 15 Feb 2005 13:37:10 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLb5P7010812; Tue, 15 Feb 2005 21:37:05 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLaGML010054; Tue, 15 Feb 2005 21:37:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513370526317 ; Tue, 15 Feb 2005 13:37:05 -0800 Date: Tue, 15 Feb 2005 13:37:00 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 0/5] ixgb: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 445 Lines: 11 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1 use netif_poll_{enable|disable} 2 Avoid race e1000_watchdog and ixgb_clean_tx_irq 3 Robert Olsson's fix and refinement to the poll routine 4 Invalidate software cache, when writing EEPROM. 5 Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Tue Feb 15 13:37:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:37:31 -0800 (PST) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLbQpV005889 for ; Tue, 15 Feb 2005 13:37:26 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLbKP7010946; Tue, 15 Feb 2005 21:37:20 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLbKLh010984; Tue, 15 Feb 2005 21:37:20 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513372008781 ; Tue, 15 Feb 2005 13:37:20 -0800 Date: Tue, 15 Feb 2005 13:37:20 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 1/5] ixgb: use netif_poll_{enable|disable} Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1046 Lines: 30 1 use netif_poll_{enable|disable} to synchronize between poll and i/f down/up Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-02-06 23:33:01.617884512 -0800 @@ -292,6 +292,9 @@ ixgb_up(struct ixgb_adapter *adapter) mod_timer(&adapter->watchdog_timer, jiffies); ixgb_irq_enable(adapter); +#ifdef CONFIG_IXGB_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -309,6 +312,9 @@ ixgb_down(struct ixgb_adapter *adapter, #endif if(kill_watchdog) del_timer_sync(&adapter->watchdog_timer); +#ifdef CONFIG_IXGB_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); From mallikarjuna.chilakala@intel.com Tue Feb 15 13:37:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:37:50 -0800 (PST) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLbiXP006229 for ; Tue, 15 Feb 2005 13:37:44 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLbdB8023606; Tue, 15 Feb 2005 21:37:39 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLauM3010633; Tue, 15 Feb 2005 21:37:39 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513373826408 ; Tue, 15 Feb 2005 13:37:38 -0800 Date: Tue, 15 Feb 2005 13:37:38 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 2/5] ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2350 Lines: 62 2 Avoid race between e1000_watchdog and ixgb_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb.h net-drivers-2.6/drivers/net/ixgb.new/ixgb.h --- net-drivers-2.6/drivers/net/ixgb/ixgb.h 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb.h 2005-02-06 23:33:01.521899104 -0800 @@ -176,6 +176,7 @@ struct ixgb_adapter { uint64_t hw_csum_tx_error; uint32_t tx_int_delay; boolean_t tx_int_delay_enable; + boolean_t detect_tx_hung; /* RX */ struct ixgb_desc_ring rx_ring; diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-02-06 23:33:01.617884512 -0800 @@ -1100,7 +1100,6 @@ ixgb_watchdog(unsigned long data) struct ixgb_adapter *adapter = (struct ixgb_adapter *)data; struct net_device *netdev = adapter->netdev; struct ixgb_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; ixgb_check_for_link(&adapter->hw); @@ -1143,12 +1140,8 @@ ixgb_watchdog(unsigned long data) } } - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(IXGB_READ_REG(&adapter->hw, STATUS) & IXGB_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period */ + adapter->detect_tx_hung = TRUE; /* generate an interrupt to force clean up of any stragglers */ IXGB_WRITE_REG(&adapter->hw, ICS, IXGB_INT_TXDW); @@ -1748,6 +1748,17 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a } spin_unlock(&adapter->tx_lock); + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) + && !(IXGB_READ_REG(&adapter->hw, STATUS) & + IXGB_STATUS_TXOFF)) + netif_stop_queue(netdev); + } + return cleaned; } From mallikarjuna.chilakala@intel.com Tue Feb 15 13:38:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:38:15 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLcAAs006672 for ; Tue, 15 Feb 2005 13:38:10 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLc4m5031518; Tue, 15 Feb 2005 21:38:04 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLbeM1011267; Tue, 15 Feb 2005 21:38:04 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513380411434 ; Tue, 15 Feb 2005 13:38:04 -0800 Date: Tue, 15 Feb 2005 13:38:04 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 3/5] ixgb: Robert Olsson's fix and refinement to the poll routine Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1311 Lines: 35 3 Robert Olsson's fix and refinement to the poll routine Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-02-06 23:33:01.617884512 -0800 @@ -1669,20 +1669,16 @@ ixgb_clean(struct net_device *netdev, in int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; - - if (!netif_carrier_ok(netdev)) - goto quit_polling; tx_cleaned = ixgb_clean_tx_irq(adapter); ixgb_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - - /* if no Tx cleanup and not enough Rx work done, exit the polling mode */ - if((!tx_cleaned && (work_done < work_to_do)) || - !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { + netif_rx_complete(netdev); ixgb_irq_enable(adapter); return 0; } From mallikarjuna.chilakala@intel.com Tue Feb 15 13:38:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:38:52 -0800 (PST) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLckTp007332 for ; Tue, 15 Feb 2005 13:38:46 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLcfP7011556; Tue, 15 Feb 2005 21:38:41 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLcAM1011634; Tue, 15 Feb 2005 21:38:41 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513384011528 ; Tue, 15 Feb 2005 13:38:40 -0800 Date: Tue, 15 Feb 2005 13:38:40 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 4/5] ixgb: Invalidate software cache, when writing EEPROM. Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2189 Lines: 57 4 Added code to invalidate software cache, when a write is made to the EEPROM. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c 2005-02-06 23:33:00.650031648 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c 2005-02-06 23:33:01.466907464 -0800 @@ -372,11 +372,11 @@ ixgb_update_eeprom_checksum(struct ixgb_ * *****************************************************************************/ void -ixgb_write_eeprom(struct ixgb_hw *hw, - uint16_t offset, - uint16_t data) +ixgb_write_eeprom(struct ixgb_hw *hw, uint16_t offset, uint16_t data) { - /* Prepare the EEPROM for writing */ + struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; + + /* Prepare the EEPROM for writing */ ixgb_setup_eeprom(hw); /* Send the 9-bit EWEN (write enable) command to the EEPROM (5-bit opcode @@ -410,6 +410,9 @@ /* Done with writing */ ixgb_cleanup_eeprom(hw); + /* clear the init_ctrl_reg_1 to signify that the cache is invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; + return; } @@ -478,6 +458,9 @@ ixgb_get_eeprom_data(struct ixgb_hw *hw) if (checksum != (uint16_t) EEPROM_SUM) { DEBUGOUT("ixgb_ee: Checksum invalid.\n"); + /* clear the init_ctrl_reg_1 to signify that the cache is + * invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; return (FALSE); } diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.h 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.h 2005-02-06 23:33:01.482905032 -0800 @@ -63,6 +63,7 @@ #define EEPROM_ICW1_SIGNATURE_MASK 0xC000 #define EEPROM_ICW1_SIGNATURE_VALID 0x4000 +#define EEPROM_ICW1_SIGNATURE_CLEAR 0x0000 /* For checksumming, the sum of all words in the EEPROM should equal 0xBABA. */ #define EEPROM_SUM 0xBABA From mallikarjuna.chilakala@intel.com Tue Feb 15 13:39:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:39:17 -0800 (PST) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLdBkm007783 for ; Tue, 15 Feb 2005 13:39:11 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FLd6B8024264; Tue, 15 Feb 2005 21:39:06 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FLcaM1011992; Tue, 15 Feb 2005 21:39:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021513390511575 ; Tue, 15 Feb 2005 13:39:05 -0800 Date: Tue, 15 Feb 2005 13:39:05 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 5/5] ixgb: Driver version, white space, comments, device id & other Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 10612 Lines: 217 5 Driver version number, white space, comments, device id & other changes Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c 2005-02-06 23:33:00.650031648 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c 2005-02-06 23:33:01.466907464 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.h 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.h 2005-02-06 23:33:01.482905032 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c 2005-02-06 23:33:01.503901840 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -63,6 +63,7 @@ static struct ixgb_stats ixgb_gstrings_s {"tx_dropped", IXGB_STAT(net_stats.tx_dropped)}, {"multicast", IXGB_STAT(net_stats.multicast)}, {"collisions", IXGB_STAT(net_stats.collisions)}, + /* { "rx_length_errors", IXGB_STAT(net_stats.rx_length_errors) }, */ {"rx_over_errors", IXGB_STAT(net_stats.rx_over_errors)}, {"rx_crc_errors", IXGB_STAT(net_stats.rx_crc_errors)}, @@ -98,6 +99,7 @@ static int ixgb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + ecmd->supported = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->advertising = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->port = PORT_FIBRE; @@ -119,6 +125,7 @@ static int ixgb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + if(ecmd->autoneg == AUTONEG_ENABLE || ecmd->speed + ecmd->duplex != SPEED_10000 + DUPLEX_FULL) return -EINVAL; diff -up net-drivers-2.6/drivers/net/ixgb/ixgb.h net-drivers-2.6/drivers/net/ixgb.new/ixgb.h --- net-drivers-2.6/drivers/net/ixgb/ixgb.h 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb.h 2005-02-06 23:33:01.521899104 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_hw.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_hw.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_hw.c 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_hw.c 2005-02-06 23:33:01.546895304 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_hw.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_hw.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_hw.h 2005-02-06 23:33:00.651031496 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_hw.h 2005-02-06 23:33:01.570891656 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ids.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_ids.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_ids.h 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ids.h 2005-02-06 23:33:01.586889224 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-02-06 23:33:01.617884512 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -29,6 +29,9 @@ #include "ixgb.h" /* Change Log + * 1.0.88 01/05/05 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 1.0.84 10/26/04 * - reset buffer_info->dma in Tx resource cleanup logic * 1.0.83 10/12/04 @@ -38,13 +41,14 @@ char ixgb_driver_name[] = "ixgb"; char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; + #ifndef CONFIG_IXGB_NAPI #define DRIVERNAPI #else #define DRIVERNAPI "-NAPI" #endif -char ixgb_driver_version[] = "1.0.87-k2"DRIVERNAPI; -char ixgb_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table * @@ -715,14 +719,8 @@ ixgb_configure_tx(struct ixgb_adapter *a IXGB_WRITE_REG(hw, TDH, 0); IXGB_WRITE_REG(hw, TDT, 0); - /* don't set up txdctl, it induces performance problems if - * configured incorrectly - txdctl = TXDCTL_PTHRESH_DEFAULT; // prefetch txds below this threshold - txdctl |= (TXDCTL_HTHRESH_DEFAULT // only prefetch if there are this many ready - << IXGB_TXDCTL_HTHRESH_SHIFT); - IXGB_WRITE_REG (hw, TXDCTL, txdctl); - */ - + /* don't set up txdctl, it induces performance problems if configured + * incorrectly */ /* Set the Tx Interrupt Delay register */ IXGB_WRITE_REG(hw, TIDV, adapter->tx_int_delay); @@ -855,10 +853,17 @@ ixgb_configure_rx(struct ixgb_adapter *a IXGB_WRITE_REG(hw, RDH, 0); IXGB_WRITE_REG(hw, RDT, 0); - /* burst 16 or burst when RXT0*/ - rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT - | RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT - | RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; + /* set up pre-fetching of receive buffers so we get some before we + * run out (default hardware behavior is to run out before fetching + * more). This sets up to fetch if HTHRESH rx descriptors are avail + * and the descriptors in hw cache are below PTHRESH. This avoids + * the hardware behavior of fetching <=512 descriptors in a single + * burst that pre-empts all other activity, usually causing fifo + * overflows. */ + /* use WTHRESH to burst write 16 descriptors or burst when RXT0 */ + rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT | + RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT | + RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; IXGB_WRITE_REG(hw, RXDCTL, rxdctl); /* Enable Receive Checksum Offload for TCP and UDP */ diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h 2005-02-06 23:33:01.634881928 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_param.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_param.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_param.c 2005-02-06 23:33:00.652031344 -0800 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_param.c 2005-02-06 23:33:01.653879040 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free From davem@davemloft.net Tue Feb 15 13:41:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:41:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLfWpO009434 for ; Tue, 15 Feb 2005 13:41:32 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1API-0007RG-00; Tue, 15 Feb 2005 13:38:56 -0800 Date: Tue, 15 Feb 2005 13:38:55 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCHSET] Extended matches and basic classifier Message-Id: <20050215133855.6659f7e1.davem@davemloft.net> In-Reply-To: <20050123230012.GB23931@postel.suug.ch> References: <20050123230012.GB23931@postel.suug.ch> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 266 Lines: 7 On Mon, 24 Jan 2005 00:00:12 +0100 Thomas Graf wrote: > This patchset adds the ematch API, the ematches cmp, nbyte, u32, meta, > and the basic classifier. It doesn't touch any existing code. All added to my net-2.6.12 pending tree. Thanks Thomas. From pablo@eurodev.net Tue Feb 15 13:41:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:41:54 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLflwN009470 for ; Tue, 15 Feb 2005 13:41:48 -0800 Received: from eurodev.net ([85.136.114.63]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050215214139.BHCJ9125.smtp09.retemail.es@eurodev.net>; Tue, 15 Feb 2005 22:41:39 +0100 Message-ID: <42126C9B.5060406@eurodev.net> Date: Tue, 15 Feb 2005 22:41:47 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Harald Welte , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [RFC] string matching based packet classification/filtering References: <20050215203211.GL31837@postel.suug.ch> In-Reply-To: <20050215203211.GL31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 2771 Lines: 89 Hi Thomas, Thomas Graf wrote: >We have been discussing string matching based packet classification and >filterings a few times already and I'd like to make it serious this time >to get the string matching ematch ready for 2.6.12 inclusion. > I agree with you. I'd like to finish see something usable. On the other hand, there's no need to rush anyway. > I'm aware >of the bayer-moore based patch by Emmanuel Roger, Gianni Tedesco, and Pablo >but I also heard about a generic string matching architecture supporting >various algorithms I haven't found that patchset though. > >Is there any effort going into the generic architecture? > Actually I wanted to contact Harald after this friday, once I'm done with my exams. I'd like to merge my work with his libqsearch hackings that were about to be finished. > Any plans for >a stateful string matching netfilter module? As it was mentioned already >we could share some code between the ematch and netfilter. > Indeed, I think that we must share that code. > I do not care >for the algorithm, actually I think it doesn't matter at all as long as >it's not a naive linear search. > An infrastructure based on libqsearch let us have different algorithms, so we could use whatever algorithm. This won't be a problem. > The essential parts are to be able t define a searching range and to support paged skbs. > I've been working on this, I'll pass you what I have as soon as I get time to review it again. > If there is someone >going for the generic architecture fullfilling the essential parts >just described then I'll be more than happy to use that bit of code >otherwise I'd be happy to discuss the requirements of both sides and >try to find a compromise both sides can live with. > >The requirements from my side: > In: > o pattern as byte stream > o length of pattern > o begin of search range (skb layer + offset) > o end of search range (skb layer + offset) > o (p)skb > Out: > o true or false > > Those look fine for me. Actually I also need more than a true of false, a pointer to where a matching happens. This is a requirement for conntrack helpers. >Applying this on the recently posted implementation by Pablo it shows >that it nearly fits already except for the search range. Additionaly >it could be improved by using prefix optimizations for the fragment >border regions instead of a naive string search which would help for >large patterns on paged skbs. > > Sure that you can improve current way of doing things :) >If needed an additional input argument could be added specifying the >algorithm to be used. Eventually it requires an additional algoirthm >specific argument carrying meta data such as prefix lookup tables. > >Thoughts? > > Harald,any thoughts? -- Pablo From davem@davemloft.net Tue Feb 15 13:43:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:44:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLhxFQ010478 for ; Tue, 15 Feb 2005 13:43:59 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1ARc-0007Rk-00; Tue, 15 Feb 2005 13:41:20 -0800 Date: Tue, 15 Feb 2005 13:41:20 -0800 From: "David S. Miller" To: Robert Olsson Cc: netdev@oss.sgi.com, Jens.Laas@data.slu.se, Robert.Olsson@data.slu.se Subject: Re: Some pktgen fixes for 2.6.11-rc2 Message-Id: <20050215134120.3ae4c511.davem@davemloft.net> In-Reply-To: <16890.41237.608094.933695@robur.slu.se> References: <16890.41237.608094.933695@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1FLhxFQ010478 X-archive-position: 1687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 257 Lines: 9 On Fri, 28 Jan 2005 21:31:17 +0100 Robert Olsson wrote: > Some fixes pointed out by Grant Grundler and Jens Låås but > Grant still see problems. Robert, can you send me an updated patch against current sources? Thanks a lot. From tgraf@suug.ch Tue Feb 15 13:55:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 13:55:53 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FLtn29011435 for ; Tue, 15 Feb 2005 13:55:50 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id A6F33F; Tue, 15 Feb 2005 22:55:26 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4C58E1C0EA; Tue, 15 Feb 2005 22:56:09 +0100 (CET) Date: Tue, 15 Feb 2005 22:56:09 +0100 From: Thomas Graf To: Pablo Neira Cc: Harald Welte , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [RFC] string matching based packet classification/filtering Message-ID: <20050215215609.GN31837@postel.suug.ch> References: <20050215203211.GL31837@postel.suug.ch> <42126C9B.5060406@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42126C9B.5060406@eurodev.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 723 Lines: 21 Pablo, > I agree with you. I'd like to finish see something usable. On the other > hand, there's no need to rush anyway. Agreed, I need for work though and want to make a decision wether to keep putting effort in em_kmp.c or focus on a new way. > Actually I wanted to contact Harald after this friday, once I'm done > with my exams. I'd like to merge my work with his libqsearch hackings > that were about to be finished. libqsearch, exactly. Let me know once it's finished. > Those look fine for me. Actually I also need more than a true of false, > a pointer to where a matching happens. This is a requirement for > conntrack helpers. Fine with me. I'll sit thight and wait for libqsearch to come up. Thanks. From romieu@fr.zoreil.com Tue Feb 15 14:07:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:07:28 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FM7Mli012337 for ; Tue, 15 Feb 2005 14:07:23 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1FM5tjI004247; Tue, 15 Feb 2005 23:05:55 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1FM5nu6004246; Tue, 15 Feb 2005 23:05:49 +0100 Date: Tue, 15 Feb 2005 23:05:49 +0100 From: Francois Romieu To: Malli Chilakala Cc: "jgarzik@pobox.com" , netdev Subject: Re: [PATCH net-drivers-2.6 2/10] e1000: use netif_poll_{enable|disable} Message-ID: <20050215220549.GA1755@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1689 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: 811 Lines: 24 Malli Chilakala : [...] > diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c > --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 23:10:24.989105880 -0800 > +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 23:10:26.709844288 -0800 > @@ -308,6 +308,9 @@ e1000_up(struct e1000_adapter *adapter) > mod_timer(&adapter->watchdog_timer, jiffies); > e1000_irq_enable(adapter); > > +#ifdef CONFIG_E1000_NAPI > + netif_poll_enable(netdev); > +#endif > return 0; > } > It leaves a small(*) window where the irq handler will do nothing with the events it receives. If netif_poll_enable() is issued before e1000_irq_enable(), the problem disappears. [*] Assuming CONFIG_PREEMPT=n -- Ueimor From pablo@eurodev.net Tue Feb 15 14:19:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:19:51 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMJdrL013184 for ; Tue, 15 Feb 2005 14:19:40 -0800 Received: from eurodev.net ([85.136.114.63]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050215221933.BRHC9125.smtp09.retemail.es@eurodev.net>; Tue, 15 Feb 2005 23:19:33 +0100 Message-ID: <4212757D.5070401@eurodev.net> Date: Tue, 15 Feb 2005 23:19:41 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> <20050215034708.GG27645@shell0.pdx.osdl.net> In-Reply-To: <20050215034708.GG27645@shell0.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------080905080305000803030409" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 4925 Lines: 184 This is a multi-part message in MIME format. --------------080905080305000803030409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Wright wrote: >Great, thanks. This is technically racy. It's possible (albeit small >window) that something could be delivered before this is set. > Yes, hard trigger but that can happen and doesn't tell too much in favour of me. >Using a callback struct during registration would fix this. > > I agree, maybe something like the example patch attached. Hope that helps. -- Pablo --------------080905080305000803030409 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/netlink/af_netlink.c 1.69 vs edited ===== --- 1.69/net/netlink/af_netlink.c 2005-01-21 21:25:32 +01:00 +++ edited/net/netlink/af_netlink.c 2005-02-15 23:10:47 +01:00 @@ -71,6 +71,7 @@ struct netlink_callback *cb; spinlock_t cb_lock; void (*data_ready)(struct sock *sk, int bytes); + int (*check_sender)(struct sk_buff *skb); }; #define nlk_sk(__sk) ((struct netlink_opt *)(__sk)->sk_protinfo) @@ -636,9 +637,16 @@ int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) { struct netlink_opt *nlk; - int len = skb->len; + int err, len = skb->len; + + nlk = nlk_sk(sk); + + if (nlk->check_sender) + if ((err = nlk->check_sender(skb))) { + netlink_detachskb(sk, skb); + return err; + } - nlk = nlk_sk(sk); #ifdef NL_EMULATE_DEV if (nlk->handler) { skb_orphan(skb); @@ -1033,7 +1041,7 @@ */ struct sock * -netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) +netlink_kernel_create(int unit, struct netlink_ops *nlops) { struct socket *sock; struct sock *sk; @@ -1053,8 +1061,12 @@ } sk = sock->sk; sk->sk_data_ready = netlink_data_ready; - if (input) - nlk_sk(sk)->data_ready = input; + if (nlops != NULL) { + if (nlops->input) + nlk_sk(sk)->data_ready = nlops->input; + if (nlops->check_sender) + nlk_sk(sk)->check_sender = nlops->check_sender; + } if (netlink_insert(sk, 0)) { sock_release(sock); ===== include/linux/netlink.h 1.23 vs edited ===== --- 1.23/include/linux/netlink.h 2005-02-07 06:59:39 +01:00 +++ edited/include/linux/netlink.h 2005-02-15 22:53:01 +01:00 @@ -115,8 +115,13 @@ #define NETLINK_CB(skb) (*(struct netlink_skb_parms*)&((skb)->cb)) #define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds) +struct netlink_ops +{ + void (*input)(struct sock *sk, int len); + int (*check_sender)(struct sk_buff *skb); +}; -extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); +extern struct sock *netlink_kernel_create(int unit, struct netlink_ops *nlops); extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, ===== net/core/rtnetlink.c 1.33 vs edited ===== --- 1.33/net/core/rtnetlink.c 2005-01-10 22:42:22 +01:00 +++ edited/net/core/rtnetlink.c 2005-02-15 23:08:05 +01:00 @@ -462,8 +462,32 @@ static struct rtattr **rta_buf; static int rtattr_max; -/* Process one rtnetlink message. */ +static int rtnetlink_check_sender(struct sk_buff *skb) +{ + struct nlmsghdr *nlh; + int kind; + int type; + + if (skb->len < NLMSG_LENGTH(0)) + return -EINVAL; + + nlh = (struct nlmsghdr *)skb->data; + type = nlh->nlmsg_type; + + /* Unknown message: reply with EINVAL */ + if (type > RTM_MAX) + return -EINVAL; + + type -= RTM_BASE; + kind = type&3; + if (kind != 2 && !capable(CAP_NET_ADMIN)) + return -EPERM; + + return 0; +} + +/* Process one rtnetlink message. */ static __inline__ int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, int *errp) { @@ -485,10 +509,6 @@ if (type < RTM_BASE) return 0; - /* Unknown message: reply with EINVAL */ - if (type > RTM_MAX) - goto err_inval; - type -= RTM_BASE; /* All the messages must have at least 1 byte length */ @@ -509,11 +529,6 @@ sz_idx = type>>2; kind = type&3; - if (kind != 2 && security_netlink_recv(skb)) { - *errp = -EPERM; - return -1; - } - if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) { u32 rlen; @@ -681,6 +696,10 @@ void __init rtnetlink_init(void) { int i; + struct netlink_ops rtnl_ops = { + .input = rtnetlink_rcv, + .check_sender = rtnetlink_check_sender + }; rtattr_max = 0; for (i = 0; i < ARRAY_SIZE(rta_max); i++) @@ -690,7 +709,7 @@ if (!rta_buf) panic("rtnetlink_init: cannot allocate rta_buf\n"); - rtnl = netlink_kernel_create(NETLINK_ROUTE, rtnetlink_rcv); + rtnl = netlink_kernel_create(NETLINK_ROUTE, &rtnl_ops); if (rtnl == NULL) panic("rtnetlink_init: cannot initialize rtnetlink\n"); netlink_set_nonroot(NETLINK_ROUTE, NL_NONROOT_RECV); --------------080905080305000803030409-- From davem@davemloft.net Tue Feb 15 14:20:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:20:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMKp6p013536 for ; Tue, 15 Feb 2005 14:20:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1B0q-0007cO-00; Tue, 15 Feb 2005 14:17:44 -0800 Date: Tue, 15 Feb 2005 14:17:43 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Merge xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle Message-Id: <20050215141743.1010f2e6.davem@davemloft.net> In-Reply-To: <20050129123803.GA17390@gondor.apana.org.au> References: <20050129123803.GA17390@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 577 Lines: 15 On Sat, 29 Jan 2005 23:38:03 +1100 Herbert Xu wrote: > This patch merges __xfrm4_bundle_ok/__xfrm6_bundle_ok/stale_bundle > so that when I add MTU verification code I don't have to put it in > three places. > > It also moves the tests on dst->dev and dst->obsolete outside the > loop since the former is identical throughout the bundle and the > latter can only be positive on the final element which also happens > to be dst->path. > > Signed-off-by: Herbert Xu Applied to my 2.6.12-pending tree. Thanks a lot. From chrisw@osdl.org Tue Feb 15 14:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:23:05 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMMvOK014158 for ; Tue, 15 Feb 2005 14:22:58 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1FMMkqi021698 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Feb 2005 14:22:47 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1FMMkRU025649; Tue, 15 Feb 2005 14:22:46 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1FMMk6u025648; Tue, 15 Feb 2005 14:22:46 -0800 Date: Tue, 15 Feb 2005 14:22:46 -0800 From: Chris Wright To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050215222246.GI15867@shell0.pdx.osdl.net> References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> <20050215034708.GG27645@shell0.pdx.osdl.net> <4212757D.5070401@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4212757D.5070401@eurodev.net> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 454 Lines: 15 * Pablo Neira (pablo@eurodev.net) wrote: > > I agree, maybe something like the example patch attached. Hope that helps. This is better, but... > -netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) > +netlink_kernel_create(int unit, struct netlink_ops *nlops) ...this is exported interface, so would probably require a new function. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From pablo@eurodev.net Tue Feb 15 14:27:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:27:59 -0800 (PST) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMRrkv014819 for ; Tue, 15 Feb 2005 14:27:55 -0800 Received: from eurodev.net ([85.136.114.63]) by smtp07.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050215222741.JSEY10926.smtp07.retemail.es@eurodev.net>; Tue, 15 Feb 2005 23:27:41 +0100 Message-ID: <42127764.5050507@eurodev.net> Date: Tue, 15 Feb 2005 23:27:48 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit References: <20050212010109.V24171@build.pdx.osdl.net> <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> <20050215034708.GG27645@shell0.pdx.osdl.net> <4212757D.5070401@eurodev.net> <20050215222246.GI15867@shell0.pdx.osdl.net> In-Reply-To: <20050215222246.GI15867@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 688 Lines: 29 Chris Wright wrote: >* Pablo Neira (pablo@eurodev.net) wrote: > > >>I agree, maybe something like the example patch attached. Hope that helps. >> >> > >This is better, but... > > > >>-netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)) >>+netlink_kernel_create(int unit, struct netlink_ops *nlops) >> >> > >...this is exported interface, so would probably require a new function. > > I was aware of that. Actually I think that we can modify all calls to netlink_kernel_create (that aren't that much) to fit the new interface, I can post a patch to do that. I prefer providing just one function to create a netlink socket in kernel space. -- Pablo From davem@davemloft.net Tue Feb 15 14:30:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:30:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMUFLE015322 for ; Tue, 15 Feb 2005 14:30:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1BAQ-0007dZ-00; Tue, 15 Feb 2005 14:27:38 -0800 Date: Tue, 15 Feb 2005 14:27:38 -0800 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 2/2] ipvs deadlock fix Message-Id: <20050215142738.6216e197.davem@davemloft.net> In-Reply-To: <200501310633.j0V6X1l01385@mail.osdl.org> References: <200501310633.j0V6X1l01385@mail.osdl.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 319 Lines: 11 On Sun, 30 Jan 2005 22:33:02 -0800 akpm@osdl.org wrote: > update_defense_level() is calling si_meminfo() from timer context. But > si_meminfo takes non-irq-safe locks. > > Move it all to keventd context. > > Signed-off-by: Andrew Morton Ok, both patches applied. I'll push it upstream in 2.6.12 From davem@davemloft.net Tue Feb 15 14:44:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:44:31 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMiP0A016220 for ; Tue, 15 Feb 2005 14:44:26 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1BNi-0007he-00; Tue, 15 Feb 2005 14:41:22 -0800 Date: Tue, 15 Feb 2005 14:41:21 -0800 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Make loopback idev stick around Message-Id: <20050215144121.702767c5.davem@davemloft.net> In-Reply-To: <20050205053532.GA17474@gondor.apana.org.au> References: <20050205053030.GA17412@gondor.apana.org.au> <20050205053532.GA17474@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 689 Lines: 19 On Sat, 5 Feb 2005 16:35:32 +1100 Herbert Xu wrote: > On Sat, Feb 05, 2005 at 04:30:30PM +1100, herbert wrote: > > > > As it is when loopback_dev loses all of its IPv4 addresses its > > corresponding idev will be destroyed. Unfortunately as of last > > August route.c relies on the loopback idev to kill references > > to other idev objects. > > The same problem exists for IPv6. > > Signed-off-by: Herbert Xu Both patches applied to the 2.6.12-pending tree. I wish ->notifier_call()'s value was actually checked, we could do intelligent things instead of panic()'ing when (for example) loopback's idev allocation fails. From mallikarjuna.chilakala@intel.com Tue Feb 15 14:46:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:47:03 -0800 (PST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMkvvs017105 for ; Tue, 15 Feb 2005 14:46:58 -0800 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FMkqm5005794; Tue, 15 Feb 2005 22:46:52 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FMkiLv031297; Tue, 15 Feb 2005 22:46:52 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021514465217234 ; Tue, 15 Feb 2005 14:46:52 -0800 Date: Tue, 15 Feb 2005 14:46:52 -0800 (PST) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 9/10] e1000: Fixes related to Cable length Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 5703 Lines: 136 9 Fixes related to Cable length estimation Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.c net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.6/drivers/net/e1000/e1000_hw.c 2005-02-01 23:10:24.987106184 -0800 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c 2005-02-01 23:10:26.569865568 -0800 @@ -2503,7 +2503,7 @@ e1000_read_phy_reg(struct e1000_hw *hw, } } - ret_val = e1000_read_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_read_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2609,7 +2609,7 @@ e1000_write_phy_reg(struct e1000_hw *hw, } } - ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_write_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2966,9 +2966,9 @@ e1000_phy_m88_get_info(struct e1000_hw * phy_info->mdix_mode = (phy_data & M88E1000_PSSR_MDIX) >> M88E1000_PSSR_MDIX_SHIFT; - if(phy_data & M88E1000_PSSR_1000MBS) { - /* Cable Length Estimation and Local/Remote Receiver Informatoion - * are only valid at 1000 Mbps + if ((phy_data & M88E1000_PSSR_SPEED) == M88E1000_PSSR_1000MBS) { + /* Cable Length Estimation and Local/Remote Receiver Information + * are only valid at 1000 Mbps. */ phy_info->cable_length = ((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> M88E1000_PSSR_CABLE_LENGTH_SHIFT); @@ -4639,41 +4639,44 @@ e1000_get_bus_info(struct e1000_hw *hw) { uint32_t status; - if(hw->mac_type < e1000_82543) { + switch (hw->mac_type) { + case e1000_82542_rev2_0: + case e1000_82542_rev2_1: hw->bus_type = e1000_bus_type_unknown; hw->bus_speed = e1000_bus_speed_unknown; hw->bus_width = e1000_bus_width_unknown; - return; - } - - status = E1000_READ_REG(hw, STATUS); - hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? - e1000_bus_type_pcix : e1000_bus_type_pci; + break; + default: + status = E1000_READ_REG(hw, STATUS); + hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? + e1000_bus_type_pcix : e1000_bus_type_pci; - if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { - hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? - e1000_bus_speed_66 : e1000_bus_speed_120; - } else if(hw->bus_type == e1000_bus_type_pci) { - hw->bus_speed = (status & E1000_STATUS_PCI66) ? - e1000_bus_speed_66 : e1000_bus_speed_33; - } else { - switch (status & E1000_STATUS_PCIX_SPEED) { - case E1000_STATUS_PCIX_SPEED_66: - hw->bus_speed = e1000_bus_speed_66; - break; - case E1000_STATUS_PCIX_SPEED_100: - hw->bus_speed = e1000_bus_speed_100; - break; - case E1000_STATUS_PCIX_SPEED_133: - hw->bus_speed = e1000_bus_speed_133; - break; - default: - hw->bus_speed = e1000_bus_speed_reserved; - break; + if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { + hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? + e1000_bus_speed_66 : e1000_bus_speed_120; + } else if(hw->bus_type == e1000_bus_type_pci) { + hw->bus_speed = (status & E1000_STATUS_PCI66) ? + e1000_bus_speed_66 : e1000_bus_speed_33; + } else { + switch (status & E1000_STATUS_PCIX_SPEED) { + case E1000_STATUS_PCIX_SPEED_66: + hw->bus_speed = e1000_bus_speed_66; + break; + case E1000_STATUS_PCIX_SPEED_100: + hw->bus_speed = e1000_bus_speed_100; + break; + case E1000_STATUS_PCIX_SPEED_133: + hw->bus_speed = e1000_bus_speed_133; + break; + default: + hw->bus_speed = e1000_bus_speed_reserved; + break; + } } + hw->bus_width = (status & E1000_STATUS_BUS64) ? + e1000_bus_width_64 : e1000_bus_width_32; + break; } - hw->bus_width = (status & E1000_STATUS_BUS64) ? - e1000_bus_width_64 : e1000_bus_width_32; } /****************************************************************************** * Reads a value from one of the devices registers using port I/O (as opposed @@ -4738,6 +4741,7 @@ e1000_get_cable_length(struct e1000_hw * uint16_t agc_value = 0; uint16_t cur_agc, min_agc = IGP01E1000_AGC_LENGTH_TABLE_SIZE; uint16_t i, phy_data; + uint16_t cable_length; DEBUGFUNC("e1000_get_cable_length"); @@ -4749,10 +4750,11 @@ e1000_get_cable_length(struct e1000_hw * &phy_data); if(ret_val) return ret_val; + cable_length = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >> + M88E1000_PSSR_CABLE_LENGTH_SHIFT; /* Convert the enum value to ranged values */ - switch((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> - M88E1000_PSSR_CABLE_LENGTH_SHIFT) { + switch (cable_length) { case e1000_cable_length_50: *min_length = 0; *max_length = e1000_igp_cable_length_50; From buytenh@wantstofly.org Tue Feb 15 14:48:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:48:30 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMmQrQ017593 for ; Tue, 15 Feb 2005 14:48:27 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 60F332B0EC; Tue, 15 Feb 2005 23:48:25 +0100 (MET) Date: Tue, 15 Feb 2005 23:48:25 +0100 From: Lennert Buytenhek To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: eepro100 broken on ARM by 2.6.11-rc1 changes Message-ID: <20050215224825.GB886@xi.wantstofly.org> References: <20050215211020.GB566@xi.wantstofly.org> <20050215132047.7a33e6ec.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050215132047.7a33e6ec.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 583 Lines: 19 On Tue, Feb 15, 2005 at 01:20:47PM -0800, David S. Miller wrote: > > eepro100 seems to have stopped working between 2.6.10 and 2.6.11-rc2 > > on an embedded ARM platform. In 2.6.10 I would see this: > > Please check to make sure ARM implements pci_iomap(), > ioread*()/iowrite*() and friends correctly. It doesn't. The generic implementation (lib/iomap.c) assumes that cookies below 0x10000 are I/O space, and this doesn't hold on the ARM in general. In my particular case, the e100 has its I/O space start at 0x100000. Discussion taken to linux-arm-kernel. thanks, Lennert From ganesh.venkatesan@intel.com Tue Feb 15 14:48:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:48:46 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMmdUT017635 for ; Tue, 15 Feb 2005 14:48:39 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1FMmQ8U022453; Tue, 15 Feb 2005 22:48:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1FMmKB0012933; Tue, 15 Feb 2005 22:48:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021514482530660 ; Tue, 15 Feb 2005 14:48:25 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 14:48:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH net-drivers-2.6 2/10] e1000: use netif_poll_{enable|disable} Date: Tue, 15 Feb 2005 14:48:24 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E04438B87@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH net-drivers-2.6 2/10] e1000: use netif_poll_{enable|disable} Thread-Index: AcUTqrfdjyH9arwZTs+p9xHUF3m4RAAA3PTQAABqAzA= From: "Venkatesan, Ganesh" To: "Chilakala, Mallikarjuna" Cc: , , "Francois Romieu" X-OriginalArrivalTime: 15 Feb 2005 22:48:25.0839 (UTC) FILETIME=[759E07F0:01C513B0] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1FMmdUT017635 X-archive-position: 1698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1583 Lines: 55 I agree that this causes our ISR to be called where no useful work will be done -- netif_rx_schedule_prep() will fail till netif_poll_enable is called. However, there should not be any adverse side effects due to this. Will fix this in the next release. Ganesh. >-----Original Message----- >From: Chilakala, Mallikarjuna >Sent: Tuesday, February 15, 2005 2:32 PM >To: Venkatesan, Ganesh >Subject: FW: [PATCH net-drivers-2.6 2/10] e1000: use >netif_poll_{enable|disable} > > > >-----Original Message----- >From: Francois Romieu [mailto:romieu@fr.zoreil.com] >Sent: Tuesday, February 15, 2005 2:06 PM >To: Chilakala, Mallikarjuna >Cc: jgarzik@pobox.com; netdev >Subject: Re: [PATCH net-drivers-2.6 2/10] e1000: use >netif_poll_{enable|disable} > >Malli Chilakala : >[...] >> diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers- >2.6/drivers/net/e1000.new/e1000_main.c >> --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-02-01 >23:10:24.989105880 -0800 >> +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-02-01 >23:10:26.709844288 -0800 >> @@ -308,6 +308,9 @@ e1000_up(struct e1000_adapter *adapter) >> mod_timer(&adapter->watchdog_timer, jiffies); >> e1000_irq_enable(adapter); >> >> +#ifdef CONFIG_E1000_NAPI >> + netif_poll_enable(netdev); >> +#endif >> return 0; >> } >> > >It leaves a small(*) window where the irq handler will do nothing with >the events it receives. If netif_poll_enable() is issued before >e1000_irq_enable(), the problem disappears. > >[*] Assuming CONFIG_PREEMPT=n > >-- >Ueimor From jmoyer@redhat.com Tue Feb 15 14:49:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:49:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMnlSI018551 for ; Tue, 15 Feb 2005 14:49:48 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1FMnkbo007831; Tue, 15 Feb 2005 17:49:46 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1FMnkO00603; Tue, 15 Feb 2005 17:49:46 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1FMnkZg017613; Tue, 15 Feb 2005 17:49:46 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j1FMnpc1030170; Tue, 15 Feb 2005 17:49:51 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j1FMnoPY030164; Tue, 15 Feb 2005 17:49:50 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16914.31886.665975.522710@segfault.boston.redhat.com> Date: Tue, 15 Feb 2005 17:49:50 -0500 To: Matt Mackall Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI In-Reply-To: <20050210011104.GF2366@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 3531 Lines: 88 ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: Sorry, Matt, I'm just now getting to this. mpm> On Wed, Feb 09, 2005 at 04:46:58PM -0800, David S. Miller wrote: >> On Wed, 9 Feb 2005 10:32:19 -0800 Matt Mackall wrote: >> >> > On closer inspection, there's a couple other related failure cases > >> with the new ->poll logic in netpoll. I'm afraid it looks like > >> CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock > >> on netpoll-enabled devices. >> > >> > This will mean putting a pointer to struct netpoll in struct > >> net_device (which I should have done in the first place) and will take > >> a few patches to sort out. >> >> Will this ->poll() guarding lock be acquired only in the netpoll code or >> system-wide? If the latter, this introduced an incredible performance >> regression for devices using the LLTX locking scheme (ie. the most >> important high-performance gigabit drivers in the tree use this). mpm> The lock will only be taken in net_rx_action iff netpoll is enabled mpm> for the given device. Lock contention should be basically nil. mpm> Here's my current patch (on top of -mm), which I'm struggling to find mpm> an appropriate test box for (my dual box with NAPI got pressed into mpm> service as a web server a couple weeks ago). I've attached the other mpm> two patches it relies on as well. mpm> -------------- mpm> Introduce a per-client poll lock and flag. The lock assures we never mpm> have more than one caller in dev->poll(). The flag provides recursion mpm> avoidance on UP where the lock disappears. ,---- | /* | - * Check whether delayed processing was scheduled for our current CPU, | - * and then manually invoke NAPI polling to pump data off the card. | + * Check whether delayed processing was scheduled for our NIC. If so, | + * we attempt to grab the poll lock and use ->poll() to pump the card. | + * If this fails, either we've recursed in ->poll() or it's already | + * running on another CPU. | + * | + * Note: we don't mask interrupts with this lock because we're using | + * trylock here and interrupts are already disabled in the softirq | + * case. Further, we test the poll_flag to avoid recursion on UP | + * systems where the lock doesn't exist. | * | * In cases where there is bi-directional communications, reading only | * one message at a time can lead to packets being dropped by the | @@ -74,13 +80,9 @@ | static void poll_napi(struct netpoll *np) | { | int budget = 16; | - unsigned long flags; | - struct softnet_data *queue; | | - spin_lock_irqsave(&netpoll_poll_lock, flags); | - queue = &__get_cpu_var(softnet_data); | if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && | - !list_empty(&queue->poll_list)) { | + !np->poll_flag && spin_trylock(&np->poll_lock)) { | np->rx_flags |= NETPOLL_RX_DROP; | atomic_inc(&trapped); | | @@ -88,8 +90,8 @@ | | atomic_dec(&trapped); | np->rx_flags &= ~NETPOLL_RX_DROP; | + spin_unlock(&np->poll_lock); | } | - spin_unlock_irqrestore(&netpoll_poll_lock, flags); | } Okay, I've only taken a quick glance at this, but I don't quite understand why it's safe to take out the check for the per-cpu queue. Realize that an interrupt may have been serviced on another processor, and a NAPI poll may have been scheduled there. Also, could you use the -p flag to diff when you generate your next patch? It makes it *much* easier to review. I'll look the patch over more closely tomorrow. Thanks, Jeff From herbert@gondor.apana.org.au Tue Feb 15 14:55:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:55:36 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMtPxV022071 for ; Tue, 15 Feb 2005 14:55:26 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1Bb3-0001EU-00; Wed, 16 Feb 2005 09:55:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1Bac-0007KU-00; Wed, 16 Feb 2005 09:54:42 +1100 Date: Wed, 16 Feb 2005 09:54:42 +1100 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Merge xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle Message-ID: <20050215225442.GA28142@gondor.apana.org.au> References: <20050129123803.GA17390@gondor.apana.org.au> <20050215141743.1010f2e6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20050215141743.1010f2e6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5727 Lines: 191 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 15, 2005 at 02:17:43PM -0800, David S. Miller wrote: > On Sat, 29 Jan 2005 23:38:03 +1100 > Herbert Xu wrote: > > > This patch merges __xfrm4_bundle_ok/__xfrm6_bundle_ok/stale_bundle > > so that when I add MTU verification code I don't have to put it in > > three places. > > > > It also moves the tests on dst->dev and dst->obsolete outside the > > loop since the former is identical throughout the bundle and the > > latter can only be positive on the final element which also happens > > to be dst->path. > > > > Signed-off-by: Herbert Xu > > Applied to my 2.6.12-pending tree. Thanks a lot. Sorry Dave, but that patch has a critical error in stale_bundle where I forgot to add an exclamation mark. I've resent the corrected patch in the thread containing the other MTU patches. Here it is again. This patch merges xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle so that later additions for MTU calculation only need to be done once. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-1 diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2005-02-14 14:13:05 +11:00 +++ b/include/net/xfrm.h 2005-02-14 14:13:05 +11:00 @@ -857,6 +857,7 @@ extern void xfrm_policy_flush(void); extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern int xfrm_flush_bundles(void); +extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family); extern wait_queue_head_t km_waitq; extern int km_new_mapping(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/ipv4/xfrm4_policy.c 2005-02-14 14:13:05 +11:00 @@ -22,26 +22,6 @@ return __ip_route_output_key((struct rtable**)dst, fl); } -/* Check that the bundle accepts the flow and its components are - * still valid. - */ - -static int __xfrm4_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl) -{ - do { - if (xdst->u.dst.ops != &xfrm4_dst_ops) - return 1; - - if (!xfrm_selector_match(&xdst->u.dst.xfrm->sel, fl, AF_INET)) - return 0; - if (xdst->u.dst.xfrm->km.state != XFRM_STATE_VALID || - xdst->u.dst.path->obsolete > 0) - return 0; - xdst = (struct xfrm_dst*)xdst->u.dst.child; - } while (xdst); - return 0; -} - static struct dst_entry * __xfrm4_find_bundle(struct flowi *fl, struct xfrm_policy *policy) { @@ -53,7 +33,7 @@ if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && - __xfrm4_bundle_ok(xdst, fl)) { + xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; } diff -Nru a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c --- a/net/ipv6/xfrm6_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/ipv6/xfrm6_policy.c 2005-02-14 14:13:05 +11:00 @@ -31,26 +31,6 @@ return err; } -/* Check that the bundle accepts the flow and its components are - * still valid. - */ - -static int __xfrm6_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl) -{ - do { - if (xdst->u.dst.ops != &xfrm6_dst_ops) - return 1; - - if (!xfrm_selector_match(&xdst->u.dst.xfrm->sel, fl, AF_INET6)) - return 0; - if (xdst->u.dst.xfrm->km.state != XFRM_STATE_VALID || - xdst->u.dst.path->obsolete > 0) - return 0; - xdst = (struct xfrm_dst*)xdst->u.dst.child; - } while (xdst); - return 0; -} - static struct dst_entry * __xfrm6_find_bundle(struct flowi *fl, struct xfrm_policy *policy) { @@ -70,7 +50,7 @@ xdst->u.rt6.rt6i_src.plen); if (ipv6_addr_equal(&xdst->u.rt6.rt6i_dst.addr, &fl_dst_prefix) && ipv6_addr_equal(&xdst->u.rt6.rt6i_src.addr, &fl_src_prefix) && - __xfrm6_bundle_ok(xdst, fl)) { + xfrm_bundle_ok(xdst, fl, AF_INET6)) { dst_clone(dst); break; } diff -Nru a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c --- a/net/xfrm/xfrm_policy.c 2005-02-14 14:13:05 +11:00 +++ b/net/xfrm/xfrm_policy.c 2005-02-14 14:13:05 +11:00 @@ -1021,18 +1021,7 @@ static int stale_bundle(struct dst_entry *dst) { - struct dst_entry *child = dst; - - while (child) { - if (child->obsolete > 0 || - (child->dev && !netif_running(child->dev)) || - (child->xfrm && child->xfrm->km.state != XFRM_STATE_VALID)) { - return 1; - } - child = child->child; - } - - return 0; + return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC); } static void xfrm_dst_destroy(struct dst_entry *dst) @@ -1108,6 +1097,31 @@ return 0; } +/* Check that the bundle accepts the flow and its components are + * still valid. + */ + +int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family) +{ + struct dst_entry *dst = &xdst->u.dst; + + if (dst->path->obsolete > 0 || + (dst->dev && !netif_running(dst->dev))) + return 0; + + do { + if (fl && !xfrm_selector_match(&dst->xfrm->sel, fl, family)) + return 0; + if (dst->xfrm->km.state != XFRM_STATE_VALID) + return 0; + dst = dst->child; + } while (dst->xfrm); + + return 1; +} + +EXPORT_SYMBOL(xfrm_bundle_ok); + /* Well... that's _TASK_. We need to scan through transformation * list and figure out what mss tcp should generate in order to * final datagram fit to mtu. Mama mia... :-) --bp/iNruPH9dso1Pn-- From davem@davemloft.net Tue Feb 15 14:56:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 14:56:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FMul45022478 for ; Tue, 15 Feb 2005 14:56:47 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1BZk-0007lO-00; Tue, 15 Feb 2005 14:53:48 -0800 Date: Tue, 15 Feb 2005 14:53:48 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: [IPSEC] Move dst->child loop from dst_ifdown to xfrm_dst_ifdown Message-Id: <20050215145348.36ed3508.davem@davemloft.net> In-Reply-To: <20050208013140.GB30659@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206065117.GC16057@gondor.apana.org.au> <20050208012929.GA30659@gondor.apana.org.au> <20050208013140.GB30659@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 532 Lines: 15 On Tue, 8 Feb 2005 12:31:40 +1100 Herbert Xu wrote: > On Tue, Feb 08, 2005 at 12:29:29PM +1100, herbert wrote: > > > > This one moves the dst->child processing from dst_ifdown into > > xfrm_dst_ifdown. > > This patch adds a net_device argument to ifdown. After all, > it's a bit silly to notify someone of an ifdown event without > telling them what which device it was for :) > > Signed-off-by: Herbert Xu Ok, I'm going to try and get these two patches into 2.6.11 From davem@davemloft.net Tue Feb 15 15:23:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:23:59 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNNrnD024213 for ; Tue, 15 Feb 2005 15:23:54 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1C0I-0007u3-00; Tue, 15 Feb 2005 15:21:14 -0800 Date: Tue, 15 Feb 2005 15:21:14 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: Stig.Venaas@uninett.no, netdev@oss.sgi.com Subject: Re: Problem with recvmsg() and IPV6_PKTINFO Message-Id: <20050215152114.7ac33dfe.davem@davemloft.net> In-Reply-To: <20050211.183859.77973026.yoshfuji@linux-ipv6.org> References: <20050211092107.GB12377@storhaugen.uninett.no> <20050211.183859.77973026.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (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 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1FNNrnD024213 X-archive-position: 1702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 621 Lines: 16 On Fri, 11 Feb 2005 18:38:59 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20050211092107.GB12377@storhaugen.uninett.no> (at Fri, 11 Feb 2005 10:21:07 +0100), Stig Venaas says: > > > I've found that on Linux (checked 2.4, 2.6 and USAGI cvs) this only > > happens if msg_name in the msghdr structure is set. In kernel's > > udpv6_recvmsg() you can see that datagram_recv_ctl() is only called if > > msg->msg_name is set. > > Please try this. Thanks. > > Signed-off-by: Hideaki YOSHIFUJI Applied, thank you very much. From davem@davemloft.net Tue Feb 15 15:28:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:28:11 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNS5hK025244 for ; Tue, 15 Feb 2005 15:28:05 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1C40-0007uc-00; Tue, 15 Feb 2005 15:25:04 -0800 Date: Tue, 15 Feb 2005 15:25:04 -0800 From: "David S. Miller" To: Alexey Kuznetsov Cc: kuznet@ms2.inr.ac.ru, rick.jones2@hp.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org, romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050215152504.5f0b139e.davem@davemloft.net> In-Reply-To: <20050212195246.GA28895@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <20050212112811.13a0b97d.davem@davemloft.net> <20050212195246.GA28895@yakov.inr.ac.ru> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 692 Lines: 14 On Sat, 12 Feb 2005 22:52:46 +0300 Alexey Kuznetsov wrote: > Exactly. That's why the next test should be with disabled TSO in 2.6.9. > If too rare PSHs were a problem, it will show as the same disaster there. > > [ And, to be honest, in this case, I daresay MacOS X may be left with its bugs > alone. Or we could help it with something like setting PSH when we are in slow > start and each half of CWND after completion of slow start. Or just set > PSH on each frame. ] Setting it every other frame would fix the problem, just forcing it to miss header prediction path is what is needed to avoid the silly delayed ACK behavior. And PSH is one way to do that. From davem@davemloft.net Tue Feb 15 15:27:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:27:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNRbO9025011 for ; Tue, 15 Feb 2005 15:27:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1C2s-0007uT-00; Tue, 15 Feb 2005 15:23:54 -0800 Date: Tue, 15 Feb 2005 15:23:54 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050215152354.46a08d77.davem@davemloft.net> In-Reply-To: <20050211150420.74737b2e@dxpl.pdx.osdl.net> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1027 Lines: 24 On Fri, 11 Feb 2005 15:04:20 -0800 Stephen Hemminger wrote: > Still not setting Push sufficiently to keep MacOSX happy. ... > 13:40:35.034930 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: P 1179:1230(51) ack 133132 win 65535 > 13:40:35.035304 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 133132:134580(1448) ack 1230 win 1460 > 13:40:35.035312 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 134580:136028(1448) ack 1230 win 1460 > > Big gap... because of missing P > > 13:40:35.219175 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 136028 win 63716 I am starting to understand Darwin's logic. If header prediction fast path is hit, ACK is always delayed when delack sysctl is enabled. One way to miss fast path is for PSH to be set. This will make ACK not get delayed if ACK is pending already. At least that is how it looks, and it makes sense given this trace. How mind boggling a heuristic. I bet it works by accident rather than intention and purposeful design. From davem@davemloft.net Tue Feb 15 15:30:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:30:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNU0qe026088 for ; Tue, 15 Feb 2005 15:30:00 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1C5k-0007xP-00; Tue, 15 Feb 2005 15:26:52 -0800 Date: Tue, 15 Feb 2005 15:26:51 -0800 From: "David S. Miller" To: Alexey Kuznetsov Cc: kuznet@ms2.inr.ac.ru, shemminger@osdl.org, hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050215152651.58f5ccc0.davem@davemloft.net> In-Reply-To: <20050212200318.GB28895@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> <20050212141641.GA27456@yakov.inr.ac.ru> <20050212114132.5f7b7ffe.davem@davemloft.net> <20050212200318.GB28895@yakov.inr.ac.ru> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 598 Lines: 14 On Sat, 12 Feb 2005 23:03:18 +0300 Alexey Kuznetsov wrote: > Actually, that anti-MacOS never worked well. If segment with forced PSH > was not transmitted in time, even forced PSHs could be deleted. > Your patch with setting PSH right before (or in) tcp_transmit_skb() must > work. Unless these segments are not tso. Yes, it never did work well. But now we understand more deeply the nature of this beast, we can probably refine it. In short, for properly working TCP stream with no drops and no reordering, Darwin delays ACKs until delack timer fires or PSH is seen :-) From romieu@fr.zoreil.com Tue Feb 15 15:31:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:31:29 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNVLic026606 for ; Tue, 15 Feb 2005 15:31:22 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1FNUQ96005679; Wed, 16 Feb 2005 00:30:26 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1FNUKRa005678; Wed, 16 Feb 2005 00:30:20 +0100 Date: Wed, 16 Feb 2005 00:30:20 +0100 From: Francois Romieu To: "Venkatesan, Ganesh" Cc: "Chilakala, Mallikarjuna" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH net-drivers-2.6 2/10] e1000: use netif_poll_{enable|disable} Message-ID: <20050215233020.GB1755@electric-eye.fr.zoreil.com> References: <468F3FDA28AA87429AD807992E22D07E04438B87@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04438B87@orsmsx408> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1706 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: 354 Lines: 10 Venkatesan, Ganesh : > I agree that this causes our ISR to be called where no useful work will > be done -- netif_rx_schedule_prep() will fail till netif_poll_enable is > called. > However, there should not be any adverse side effects due to this. Right, the irq does not need an extra ack. Sorry for the noise. -- Ueimor From davem@davemloft.net Tue Feb 15 15:34:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:34:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNY8JC027149 for ; Tue, 15 Feb 2005 15:34:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1C9o-0007yC-00; Tue, 15 Feb 2005 15:31:04 -0800 Date: Tue, 15 Feb 2005 15:31:04 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Merge xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle Message-Id: <20050215153104.419b1b84.davem@davemloft.net> In-Reply-To: <20050215225442.GA28142@gondor.apana.org.au> References: <20050129123803.GA17390@gondor.apana.org.au> <20050215141743.1010f2e6.davem@davemloft.net> <20050215225442.GA28142@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 469 Lines: 15 On Wed, 16 Feb 2005 09:54:42 +1100 Herbert Xu wrote: > > Applied to my 2.6.12-pending tree. Thanks a lot. > > Sorry Dave, but that patch has a critical error in stale_bundle > where I forgot to add an exclamation mark. So the relative fix is to just add a "!" to the return statement of stale_bundle() so that it reads: return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC); right? If so, I'll just add that to my tree. From herbert@gondor.apana.org.au Tue Feb 15 15:36:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:37:03 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNas3T027676 for ; Tue, 15 Feb 2005 15:36:55 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1CFJ-0001bv-00; Wed, 16 Feb 2005 10:36:45 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1CEx-0007QL-00; Wed, 16 Feb 2005 10:36:23 +1100 Date: Wed, 16 Feb 2005 10:36:23 +1100 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Merge xfrm4_bundle_ok/xfrm6_bundle_ok/stale_bundle Message-ID: <20050215233623.GA28477@gondor.apana.org.au> References: <20050129123803.GA17390@gondor.apana.org.au> <20050215141743.1010f2e6.davem@davemloft.net> <20050215225442.GA28142@gondor.apana.org.au> <20050215153104.419b1b84.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050215153104.419b1b84.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 786 Lines: 24 On Tue, Feb 15, 2005 at 03:31:04PM -0800, David S. Miller wrote: > On Wed, 16 Feb 2005 09:54:42 +1100 > Herbert Xu wrote: > > > > Applied to my 2.6.12-pending tree. Thanks a lot. > > > > Sorry Dave, but that patch has a critical error in stale_bundle > > where I forgot to add an exclamation mark. > > So the relative fix is to just add a "!" to the return statement > of stale_bundle() so that it reads: > > return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC); > > right? If so, I'll just add that to my tree. Yes. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rick.jones2@hp.com Tue Feb 15 15:42:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:42:52 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNgmJU028278 for ; Tue, 15 Feb 2005 15:42:49 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id C6D3B1C11EB2 for ; Tue, 15 Feb 2005 15:42:48 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA01260 for ; Tue, 15 Feb 2005 15:42:48 -0800 (PST) Message-ID: <421288F8.7090501@hp.com> Date: Tue, 15 Feb 2005 15:42:48 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050211170740.2608419b.davem@davemloft.net> <20050212141641.GA27456@yakov.inr.ac.ru> <20050212114132.5f7b7ffe.davem@davemloft.net> <20050212200318.GB28895@yakov.inr.ac.ru> <20050215152651.58f5ccc0.davem@davemloft.net> In-Reply-To: <20050215152651.58f5ccc0.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 428 Lines: 11 > In short, for properly working TCP stream with no drops and no > reordering, Darwin delays ACKs until delack timer fires or PSH > is seen :-) As a supporter of ACK avoidance heuristics in general, I will come-out and say that the heuristic above does indeed sound quite broken. It is not the heuristic with which I am familiar, which has a configurable maximum number of segments for which to delay the ACK. rick jones From fubar@us.ibm.com Tue Feb 15 15:51:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 15:51:10 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FNp5K4029042 for ; Tue, 15 Feb 2005 15:51:05 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1FNov0D429542 for ; Tue, 15 Feb 2005 18:50:57 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1FNovp8438212 for ; Tue, 15 Feb 2005 16:50:57 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1FNouhL001987 for ; Tue, 15 Feb 2005 16:50:56 -0700 Received: from death.nxdomain.ibm.com (sig-9-65-31-201.mts.ibm.com [9.65.31.201]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1FNouj4001964; Tue, 15 Feb 2005 16:50:56 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j1FNosNn030809; Tue, 15 Feb 2005 15:50:54 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j1FNoq6f030802; Tue, 15 Feb 2005 15:50:53 -0800 Message-Id: <200502152350.j1FNoq6f030802@death.nxdomain.ibm.com> To: Olaf Kirch cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] VLAN over bonding In-Reply-To: Message from Olaf Kirch of "Mon, 14 Feb 2005 12:29:05 +0100." <20050214112905.GF23861@suse.de> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 15 Feb 2005 15:50:52 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2069 Lines: 57 Olaf Kirch wrote: >It seems when you create a VLAN configuration on top of a bonding >device, any normal (non-VLAN) traffic stops completely. The reason >is that bond_dev_queue_xmit() drops all outgoing frames that have >no VLAN tag. > >The attached patch tries to fix this - is this the right way to do this, >or does that break other areas of VLAN-over-bonding? Logically this looks good. I tried it out on a non-VLAN aware e100, and it seems to the do right thing. I tweaked the patch to update the comments to reflect the new reality (and fix a typo while I was there). -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh --- linux-2.6.11-rc4-netdev1-virgin/drivers/net/bonding/bond_main.c 2005-02-15 11:31:40.000000000 -0800 +++ linux-2.6.11-rc4-netdev1/drivers/net/bonding/bond_main.c 2005-02-15 16:09:10.000000000 -0800 @@ -793,29 +793,20 @@ * @skb: hw accel VLAN tagged skb to transmit * @slave_dev: slave that is supposed to xmit this skbuff * - * When the bond gets an skb to tarnsmit that is + * When the bond gets an skb to transmit that is * already hardware accelerated VLAN tagged, and it * needs to relay this skb to a slave that is not * hw accel capable, the skb needs to be "unaccelerated", * i.e. strip the hwaccel tag and re-insert it as part * of the payload. - * - * Assumption - once a VLAN device is created over the bond device, all - * packets are going to be hardware accelerated VLAN tagged since the IP - * binding is done over the VLAN device */ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev) { unsigned short vlan_id; - int res; if (!list_empty(&bond->vlan_list) && - !(slave_dev->features & NETIF_F_HW_VLAN_TX)) { - res = vlan_get_tag(skb, &vlan_id); - if (res) { - return -EINVAL; - } - + !(slave_dev->features & NETIF_F_HW_VLAN_TX) && + vlan_get_tag(skb, &vlan_id) == 0) { skb->dev = slave_dev; skb = vlan_put_tag(skb, vlan_id); if (!skb) { From chrisw@osdl.org Tue Feb 15 16:11:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 16:11:42 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1G0BViF030409 for ; Tue, 15 Feb 2005 16:11:32 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1G0BLqi027798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Feb 2005 16:11:21 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1G0BKut029804; Tue, 15 Feb 2005 16:11:20 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j1G0BKBC029803; Tue, 15 Feb 2005 16:11:20 -0800 Date: Tue, 15 Feb 2005 16:11:20 -0800 From: Chris Wright To: Pablo Neira Cc: Chris Wright , netdev@oss.sgi.com, davem@davemloft.net, jmorris@redhat.com, sds@epoch.ncsc.mil, serue@us.ibm.com Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit Message-ID: <20050216001120.GJ15867@shell0.pdx.osdl.net> References: <20050212010243.W24171@build.pdx.osdl.net> <20050212010504.X24171@build.pdx.osdl.net> <420E334B.8060805@eurodev.net> <420E77FA.6080007@eurodev.net> <20050215001334.GB27645@shell0.pdx.osdl.net> <42115E7E.6050909@eurodev.net> <20050215034708.GG27645@shell0.pdx.osdl.net> <4212757D.5070401@eurodev.net> <20050215222246.GI15867@shell0.pdx.osdl.net> <42127764.5050507@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42127764.5050507@eurodev.net> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 510 Lines: 13 * Pablo Neira (pablo@eurodev.net) wrote: > I was aware of that. Actually I think that we can modify all calls to > netlink_kernel_create (that aren't that much) to fit the new interface, > I can post a patch to do that. I prefer providing just one function to > create a netlink socket in kernel space. My only thought is as an exported symobl it's harder to be clear on who's using it (possibly out-of-tree). thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From jmorris@redhat.com Tue Feb 15 19:42:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 19:43:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1G3gtol012461 for ; Tue, 15 Feb 2005 19:42:55 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1G3gmBC005801; Tue, 15 Feb 2005 22:42:48 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1G3gmO00748; Tue, 15 Feb 2005 22:42:48 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1G3glZh001750; Tue, 15 Feb 2005 22:42:47 -0500 Date: Tue, 15 Feb 2005 22:42:47 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Chris Wright cc: Pablo Neira , , , , Subject: Re: [RFC][PATCH 2/3] netlink check sender, audit In-Reply-To: <20050216001120.GJ15867@shell0.pdx.osdl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1712 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: 630 Lines: 23 On Tue, 15 Feb 2005, Chris Wright wrote: > * Pablo Neira (pablo@eurodev.net) wrote: > > I was aware of that. Actually I think that we can modify all calls to > > netlink_kernel_create (that aren't that much) to fit the new interface, > > I can post a patch to do that. I prefer providing just one function to > > create a netlink socket in kernel space. > > My only thought is as an exported symobl it's harder to be clear on > who's using it (possibly out-of-tree). Doesn't matter, the kernel has no ABI. http://www.kroah.com/log/linux/stable_api_nonsense.html?seemore=y - James -- James Morris From oxymoron@waste.org Tue Feb 15 21:07:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Feb 2005 21:07:34 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1G57SGY020594 for ; Tue, 15 Feb 2005 21:07:29 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1G57ML8003549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Feb 2005 23:07:22 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j1G57MHm003546; Tue, 15 Feb 2005 23:07:22 -0600 Date: Tue, 15 Feb 2005 21:07:22 -0800 From: Matt Mackall To: Jeff Moyer Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050216050722.GC3358@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16914.31886.665975.522710@segfault.boston.redhat.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1713 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: 3998 Lines: 94 On Tue, Feb 15, 2005 at 05:49:50PM -0500, Jeff Moyer wrote: > ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: > > Sorry, Matt, I'm just now getting to this. > > mpm> On Wed, Feb 09, 2005 at 04:46:58PM -0800, David S. Miller wrote: > >> On Wed, 9 Feb 2005 10:32:19 -0800 Matt Mackall wrote: > >> > >> > On closer inspection, there's a couple other related failure cases > > >> with the new ->poll logic in netpoll. I'm afraid it looks like > > >> CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock > > >> on netpoll-enabled devices. > >> > > >> > This will mean putting a pointer to struct netpoll in struct > > >> net_device (which I should have done in the first place) and will take > > >> a few patches to sort out. > >> > >> Will this ->poll() guarding lock be acquired only in the netpoll code or > >> system-wide? If the latter, this introduced an incredible performance > >> regression for devices using the LLTX locking scheme (ie. the most > >> important high-performance gigabit drivers in the tree use this). > > mpm> The lock will only be taken in net_rx_action iff netpoll is enabled > mpm> for the given device. Lock contention should be basically nil. > > mpm> Here's my current patch (on top of -mm), which I'm struggling to find > mpm> an appropriate test box for (my dual box with NAPI got pressed into > mpm> service as a web server a couple weeks ago). I've attached the other > mpm> two patches it relies on as well. > > mpm> -------------- > > mpm> Introduce a per-client poll lock and flag. The lock assures we never > mpm> have more than one caller in dev->poll(). The flag provides recursion > mpm> avoidance on UP where the lock disappears. > > ,---- > | /* > | - * Check whether delayed processing was scheduled for our current CPU, > | - * and then manually invoke NAPI polling to pump data off the card. > | + * Check whether delayed processing was scheduled for our NIC. If so, > | + * we attempt to grab the poll lock and use ->poll() to pump the card. > | + * If this fails, either we've recursed in ->poll() or it's already > | + * running on another CPU. > | + * > | + * Note: we don't mask interrupts with this lock because we're using > | + * trylock here and interrupts are already disabled in the softirq > | + * case. Further, we test the poll_flag to avoid recursion on UP > | + * systems where the lock doesn't exist. > | * > | * In cases where there is bi-directional communications, reading only > | * one message at a time can lead to packets being dropped by the > | @@ -74,13 +80,9 @@ > | static void poll_napi(struct netpoll *np) > | { > | int budget = 16; > | - unsigned long flags; > | - struct softnet_data *queue; > | > | - spin_lock_irqsave(&netpoll_poll_lock, flags); > | - queue = &__get_cpu_var(softnet_data); > | if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && > | - !list_empty(&queue->poll_list)) { > | + !np->poll_flag && spin_trylock(&np->poll_lock)) { > | np->rx_flags |= NETPOLL_RX_DROP; > | atomic_inc(&trapped); > | > | @@ -88,8 +90,8 @@ > | > | atomic_dec(&trapped); > | np->rx_flags &= ~NETPOLL_RX_DROP; > | + spin_unlock(&np->poll_lock); > | } > | - spin_unlock_irqrestore(&netpoll_poll_lock, flags); > | } > > Okay, I've only taken a quick glance at this, but I don't quite understand > why it's safe to take out the check for the per-cpu queue. Realize that an > interrupt may have been serviced on another processor, and a NAPI poll may > have been scheduled there. Because dev->np->poll_lock now serializes all access to ->poll (when netpoll is enabled on said device). > Also, could you use the -p flag to diff when you generate your next patch? > It makes it *much* easier to review. Hmm, somehow my QUILT_DIFF_OPTS got lost, thanks. I've just now recovered my SMP+NAPI box, so I can take a stab at actually testing this shortly. -- Mathematics is the supreme nostalgia of our time. From kuznet@yakov.inr.ac.ru Wed Feb 16 01:14:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 01:14:31 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1G9EKhF005234 for ; Wed, 16 Feb 2005 01:14:21 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=cTXipgTGw4eWpG9R5c0YlEDNHJBqz3t0j7hGNglaBU2GfAaWlBYO5la+VYeEnA9A/KODMx7c8n1/5UidFLn/Oc0ctnOV/Fz+DQ4Yg3Q46JzIvb1uZj8yGMIhI0YqPtiTQVHWzubolJfi47tNbt6KFCGUJmBcGiZAJJXAjXPdNlI=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id MAA26821; Wed, 16 Feb 2005 12:13:23 +0300 Date: Wed, 16 Feb 2005 12:13:23 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Stephen Hemminger , hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050216091323.GA26758@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050215152354.46a08d77.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050215152354.46a08d77.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1714 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: 406 Lines: 14 Hello! > How mind boggling a heuristic. I bet it works by accident rather > than intention and purposeful design. Yup. It is definitely not an "ack avoidance algorithm" :-) :-) BTW it is still a puzzle why 2.6.9 works. With disabled TSO it should insert PSHs quite rarely, similarly to tso. And it is still a puzzle how that bunch of PSHless segments not followed by PSH appeared in TSO case. Alexey From herbert@gondor.apana.org.au Wed Feb 16 02:13:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 02:13:56 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GADite008829 for ; Wed, 16 Feb 2005 02:13:45 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1MBL-0004kO-00; Wed, 16 Feb 2005 21:13:19 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1MAo-0008QG-00; Wed, 16 Feb 2005 21:12:46 +1100 Date: Wed, 16 Feb 2005 21:12:45 +1100 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Make loopback idev stick around Message-ID: <20050216101245.GA32341@gondor.apana.org.au> References: <20050205053030.GA17412@gondor.apana.org.au> <20050205053532.GA17474@gondor.apana.org.au> <20050215144121.702767c5.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <20050215144121.702767c5.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4144 Lines: 158 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 15, 2005 at 02:41:21PM -0800, David S. Miller wrote: > > I wish ->notifier_call()'s value was actually checked, we could > do intelligent things instead of panic()'ing when (for example) > loopback's idev allocation fails. Yes I missed the ipv6 module case. It would be very nice to be able to return errors there. Since we initiate the loopback registration from addrconf_init, perhaps we can get away for the time being by checking the error there? Let's also clean up loopback's ipv6 structure in addrconf_cleanup even though it never happens currently :) Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/addrconf.h 1.22 vs edited ===== --- 1.22/include/net/addrconf.h 2005-01-15 08:30:07 +11:00 +++ edited/include/net/addrconf.h 2005-02-16 21:01:59 +11:00 @@ -49,7 +49,7 @@ #define IN6_ADDR_HSIZE 16 -extern void addrconf_init(void); +extern int addrconf_init(void); extern void addrconf_cleanup(void); extern int addrconf_add_ifaddr(void __user *arg); ===== net/ipv6/addrconf.c 1.130 vs edited ===== --- 1.130/net/ipv6/addrconf.c 2005-02-16 09:10:14 +11:00 +++ edited/net/ipv6/addrconf.c 2005-02-16 21:01:40 +11:00 @@ -1914,11 +1914,6 @@ struct inet6_dev *idev = __in6_dev_get(dev); switch(event) { - case NETDEV_REGISTER: - if (dev == &loopback_dev && !ipv6_find_idev(dev)) - panic("addrconf: Failed to create loopback\n"); - break; - case NETDEV_UP: switch(dev->type) { case ARPHRD_SIT: @@ -2003,7 +1998,7 @@ ASSERT_RTNL(); - if (dev == &loopback_dev) + if (dev == &loopback_dev && how == 1) how = 0; rt6_ifdown(dev); @@ -3432,8 +3427,10 @@ * Init / cleanup code */ -void __init addrconf_init(void) +int __init addrconf_init(void) { + int err = 0; + /* The addrconf netdev notifier requires that loopback_dev * has it's ipv6 private information allocated and setup * before it can bring up and give link-local addresses @@ -3447,13 +3444,17 @@ * first, then loopback_dev, which cases all the non-loopback_dev * devices to fail to get a link-local address. * - * So, as a temporary fix, register loopback_dev first by hand. + * So, as a temporary fix, allocate the ipv6 structure for + * loopback_dev first by hand. * Longer term, all of the dependencies ipv6 has upon the loopback * device and it being up should be removed. */ rtnl_lock(); - addrconf_notify(&ipv6_dev_notf, NETDEV_REGISTER, &loopback_dev); + if (!ipv6_add_dev(&loopback_dev)) + err = -ENOMEM; rtnl_unlock(); + if (err) + return err; register_netdevice_notifier(&ipv6_dev_notf); @@ -3471,6 +3472,8 @@ register_sysctl_table(addrconf_sysctl.addrconf_root_dir, 0); addrconf_sysctl_register(NULL, &ipv6_devconf_dflt); #endif + + return 0; } void __exit addrconf_cleanup(void) @@ -3499,6 +3502,7 @@ continue; addrconf_ifdown(dev, 1); } + addrconf_ifdown(&loopback_dev, 2); /* * Check hash table. ===== net/ipv6/af_inet6.c 1.88 vs edited ===== --- 1.88/net/ipv6/af_inet6.c 2005-01-14 15:41:05 +11:00 +++ edited/net/ipv6/af_inet6.c 2005-02-16 20:54:25 +11:00 @@ -782,7 +782,9 @@ ipv6_packet_init(); ip6_route_init(); ip6_flowlabel_init(); - addrconf_init(); + err = addrconf_init(); + if (err) + goto addrconf_fail; sit_init(); /* Init v6 extension headers. */ @@ -798,7 +800,12 @@ out: return err; +addrconf_fail: + ip6_flowlabel_cleanup(); + ip6_route_cleanup(); + ipv6_packet_cleanup(); #ifdef CONFIG_PROC_FS + if6_proc_exit(); proc_if6_fail: ac6_proc_exit(); proc_anycast6_fail: @@ -810,8 +817,8 @@ proc_tcp6_fail: raw6_proc_exit(); proc_raw6_fail: - igmp6_cleanup(); #endif + igmp6_cleanup(); igmp_fail: ndisc_cleanup(); ndisc_fail: --LQksG6bCIzRHxTLp-- From jeroens@office.netland.nl Wed Feb 16 02:40:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 02:40:28 -0800 (PST) Received: from services-04.netland.nl (mx1.netland.nl [217.170.32.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GAeLn8013016 for ; Wed, 16 Feb 2005 02:40:22 -0800 Received: from n010095.nbs.netland.nl (fw.office.netland.nl [217.170.32.40]) by services-04.netland.nl (Postfix) with ESMTP id 9B0F154008 for ; Wed, 16 Feb 2005 11:40:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 300B7A4FF for ; Wed, 16 Feb 2005 11:40:13 +0100 (CET) Received: from n010095.nbs.netland.nl ([127.0.0.1]) by localhost (n010095.nbs.netland.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03711-03-4 for ; Wed, 16 Feb 2005 11:40:12 +0100 (CET) Received: from [192.168.170.121] (ts2.office.netland.nl [192.168.170.121]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 704F2A4FC for ; Wed, 16 Feb 2005 11:40:12 +0100 (CET) Subject: 2.6.10 dst cache overflow From: "J. Simonetti" To: netdev@oss.sgi.com Content-Type: text/plain Organization: Netland Internet Services Message-Id: <1108550412.3799.81.camel@ts2.office.netland.nl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Feb 2005 11:40:13 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at n010095.nbs.netland.nl X-Virus-Status: Clean X-archive-position: 1717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroens@office.netland.nl Precedence: bulk X-list: netdev Content-Length: 757 Lines: 23 Hi list, I was directed to this list for my question. I searched many archives but could not find any recent posts about this subject so I ask again. I have a linux (Fedora core 3) based router. I does approximately 50Mbps aggregated traffic. However once every week (approx) the router dies with 'kernel: dst cache overflow' messages flooding syslog. I have tracked it down to being an issue with the routing cache. I was hoping someone here could give me some more information on how to address this issue. In particular info about /proc/sys/net/route/* and the meaning of its values (in essence the garbage collection routines). Regards, Jeroen Simonetti -- Netland Internet Services http://www.netland.nl Never look up when dragons fly overhead. From herbert@gondor.apana.org.au Wed Feb 16 02:39:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 02:39:19 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GAd9hL010758 for ; Wed, 16 Feb 2005 02:39:10 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1MZV-0004qm-00; Wed, 16 Feb 2005 21:38:17 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1MYy-00008G-00; Wed, 16 Feb 2005 21:37:44 +1100 Date: Wed, 16 Feb 2005 21:37:44 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [5/*] [IPSEC] Use dst_mtu in xfrm[46]_output Message-ID: <20050216103744.GA476@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20050214221607.GC18465@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2156 Lines: 74 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There was a lot of fun in laying the foundations. Now it's time to start using it. This patch fixes the calculations in xfrm[46]_output so that we don't reject properly sized packets from the TCP stack. The previous calculation is wrong because the xfrm overhead is not constant. Signed-off-by: Herbert Xu After this I'll start cleaning stuff up. For example, tcp's ext2_header_len and dst's path can both be removed. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-5 ===== include/net/dst.h 1.25 vs edited ===== --- 1.25/include/net/dst.h 2005-02-06 14:23:59 +11:00 +++ edited/include/net/dst.h 2005-02-16 21:29:56 +11:00 @@ -123,6 +123,16 @@ return mtu; } +static inline u32 dst_mtu(const struct dst_entry *dst) +{ + u32 mtu = dst_metric(dst, RTAX_MTU); + /* + * Alexey put it here, so ask him about it :) + */ + barrier(); + return mtu; +} + static inline int dst_metric_locked(struct dst_entry *dst, int metric) { ===== net/ipv4/xfrm4_output.c 1.5 vs edited ===== --- 1.5/net/ipv4/xfrm4_output.c 2004-10-26 09:10:25 +10:00 +++ edited/net/ipv4/xfrm4_output.c 2005-02-16 21:31:32 +11:00 @@ -82,7 +82,7 @@ goto out; dst = skb->dst; - mtu = dst_pmtu(dst) - dst->header_len - dst->trailer_len; + mtu = dst_mtu(dst); if (skb->len > mtu) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ret = -EMSGSIZE; ===== net/ipv6/xfrm6_output.c 1.7 vs edited ===== --- 1.7/net/ipv6/xfrm6_output.c 2004-11-16 13:52:34 +11:00 +++ edited/net/ipv6/xfrm6_output.c 2005-02-16 21:31:46 +11:00 @@ -79,7 +79,7 @@ int mtu, ret = 0; struct dst_entry *dst = skb->dst; - mtu = dst_pmtu(dst) - dst->header_len - dst->trailer_len; + mtu = dst_mtu(dst); if (mtu < IPV6_MIN_MTU) mtu = IPV6_MIN_MTU; --dDRMvlgZJXvWKvBx-- From herbert@gondor.apana.org.au Wed Feb 16 03:09:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 03:10:03 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GB9sBn015408 for ; Wed, 16 Feb 2005 03:09:55 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1N3N-00055Z-00; Wed, 16 Feb 2005 22:09:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1N2w-0000H5-00; Wed, 16 Feb 2005 22:08:42 +1100 Date: Wed, 16 Feb 2005 22:08:42 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [6/*] [IPSEC] Fix xfrm[46]_update_pmtu to update top dst Message-ID: <20050216110842.GA1024@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20050216103744.GA476@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1938 Lines: 65 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Let's also fix IPsec PMTU storage. When we get an MTU update for an xfrm_dst, it should be done to the top dst, not the bottom dst. For example, when we get a need-to-frag message for host C behind a our IPsec peer B, we should be updating the dst entry for C and not B as we do now. I've removed the boundary checks since the same checks are done in ipv[46]/route.c already. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-6 ===== net/ipv4/xfrm4_policy.c 1.16 vs edited ===== --- 1.16/net/ipv4/xfrm4_policy.c 2005-02-14 14:59:25 +11:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-02-16 22:01:56 +11:00 @@ -235,10 +235,8 @@ static void xfrm4_update_pmtu(struct dst_entry *dst, u32 mtu) { - struct dst_entry *path = dst->path; - - if (mtu < 68 + dst->header_len) - return; + struct xfrm_dst *xdst = (struct xfrm_dst *)dst; + struct dst_entry *path = xdst->route; path->ops->update_pmtu(path, mtu); } ===== net/ipv6/xfrm6_policy.c 1.27 vs edited ===== --- 1.27/net/ipv6/xfrm6_policy.c 2005-02-14 14:59:25 +11:00 +++ edited/net/ipv6/xfrm6_policy.c 2005-02-16 22:03:06 +11:00 @@ -243,12 +243,10 @@ static void xfrm6_update_pmtu(struct dst_entry *dst, u32 mtu) { - struct dst_entry *path = dst->path; + struct xfrm_dst *xdst = (struct xfrm_dst *)dst; + struct dst_entry *path = xdst->route; - if (mtu >= IPV6_MIN_MTU && mtu < dst_pmtu(dst)) - path->ops->update_pmtu(path, mtu); - - return; + path->ops->update_pmtu(path, mtu); } static struct dst_ops xfrm6_dst_ops = { --cWoXeonUoKmBZSoM-- From herbert@gondor.apana.org.au Wed Feb 16 03:40:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 03:40:08 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GBdxji016941 for ; Wed, 16 Feb 2005 03:39:59 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1NWP-0005D3-00; Wed, 16 Feb 2005 22:39:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1NVs-0000R2-00; Wed, 16 Feb 2005 22:38:36 +1100 Date: Wed, 16 Feb 2005 22:38:36 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [7/*] [IPSEC] Get metrics for xfrm_dst from top dst Message-ID: <20050216113836.GA1652@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050216110842.GA1024@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20050216110842.GA1024@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1884 Lines: 49 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline For the metrics other than MTU, we should also be getting it from the top dst as opposed to the bottom dst. With this change, the user is able to manipulate values such as advmss for individual hosts behind a remote IPsec gateway. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-7 ===== net/ipv4/xfrm4_policy.c 1.17 vs edited ===== --- 1.17/net/ipv4/xfrm4_policy.c 2005-02-16 22:09:18 +11:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-02-16 22:35:09 +11:00 @@ -133,7 +133,7 @@ dst_prev->lastuse = jiffies; dst_prev->header_len = header_len; dst_prev->trailer_len = trailer_len; - memcpy(&dst_prev->metrics, &rt->u.dst.metrics, sizeof(dst_prev->metrics)); + memcpy(&dst_prev->metrics, &x->route->metrics, sizeof(dst_prev->metrics)); /* Copy neighbout for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); ===== net/ipv6/xfrm6_policy.c 1.28 vs edited ===== --- 1.28/net/ipv6/xfrm6_policy.c 2005-02-16 22:09:18 +11:00 +++ edited/net/ipv6/xfrm6_policy.c 2005-02-16 22:35:15 +11:00 @@ -149,7 +149,7 @@ dst_prev->lastuse = jiffies; dst_prev->header_len = header_len; dst_prev->trailer_len = trailer_len; - memcpy(&dst_prev->metrics, &rt->u.dst.metrics, sizeof(dst_prev->metrics)); + memcpy(&dst_prev->metrics, &x->route->metrics, sizeof(dst_prev->metrics)); /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); --pf9I7BMVVzbSWLtt-- From ebiederm@xmission.com Wed Feb 16 04:28:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 04:28:18 -0800 (PST) Received: from ebiederm.dsl.xmission.com (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GCSDh3023173 for ; Wed, 16 Feb 2005 04:28:13 -0800 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1GCQ29N003923; Wed, 16 Feb 2005 05:26:02 -0700 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) id j1GCPv9u003919; Wed, 16 Feb 2005 05:25:57 -0700 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: Malli Chilakala Cc: "jgarzik@pobox.com" , netdev Subject: e1000: driver reboot/kexec bug. References: From: ebiederm@xmission.com (Eric W. Biederman) Date: 16 Feb 2005 05:25:56 -0700 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Content-Length: 1861 Lines: 46 When I kexec a new kernel on hardware that includes some revs of the e1000 (see below for lscpi -n) the e1000 driver is not able to reinitialize the NIC. I have seen this in both 2.4.29 and 2.6.10. Tracking it down it appears to be some side effect to powering down the nic. If I remove the pci_set_power_state call in e1000_suspend or I simply apply the attached patch so I get that affect when rebooting everything works. pci_enable_device brings the device up to full power before the driver initialization code does anything else so I don't have a clue what is really going on but it is. Boot messages on failure: > Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k1 > Copyright (c) 1999-2004 Intel Corporation. > PCI: Enabling device 03:04.0 (0000 -> 0003) > e1000: 03:04.0: e1000_probe: The EEPROM Checksum Is Not Valid > PCI: Enabling device 03:04.1 (0000 -> 0003) > e1000: 03:04.1: e1000_probe: The EEPROM Checksum Is Not Valid lspci -n of the problem onboard e1000 NIC. > 03:04.0 Class 0200: 8086:1079 (rev 03) > 03:04.1 Class 0200: 8086:1079 (rev 03) Patch which avoids the problem. diff -uNrX linux-exclude-files linux-2.4.29-kexec-apic-virtwire-on-shutdownx86_64/drivers/net/e1000/e1000_main.c linux-2.4.29-kexec7.build.x86_64/drivers/net/e1000/e1000_main.c --- linux-2.4.29-kexec-apic-virtwire-on-shutdownx86_64/drivers/net/e1000/e1000_main.c Tue Feb 15 14:17:09 2005 +++ linux-2.4.29-kexec7.build.x86_64/drivers/net/e1000/e1000_main.c Wed Feb 16 04:58:18 2005 @@ -2777,7 +2777,7 @@ case SYS_POWER_OFF: while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { if(pci_dev_driver(pdev) == &e1000_driver) - e1000_suspend(pdev, 3); + e1000_suspend(pdev, (event == SYS_DOWN)?0:3); } } return NOTIFY_DONE; Any help to track down why this is happening so we can apply a clean fix would be appreciated. Eric From david@davidcoulson.net Wed Feb 16 05:44:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 05:44:19 -0800 (PST) Received: from mail.mx.davidcoulson.net (ns1.openconsultancy.com [207.166.203.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GDiAgI029103 for ; Wed, 16 Feb 2005 05:44:11 -0800 Received: (qmail 13872 invoked for bounce); 16 Feb 2005 13:44:04 +0000 Received: from unknown (HELO mx1.cluster.davidcoulson.net) (qmailr@10.1.1.2) by tailtiu.dmz.davidcoulson.net (qmail 1.03-djc-2) with SMTP; 16 Feb 2005 13:44:04 +0000 Received: (qmail 23612 invoked by uid 1002); 16 Feb 2005 13:44:04 -0000 Received: from 10.2.0.36 by cr1 (envelope-from , uid 64011) with qmail-scanner-1.24st (clamdscan: 0.80/694. spamassassin: 3.0.2. perlscan: 1.24st. Clear:RC:1(10.2.0.36):SA:0(-4.0/6.0):. Processed in 1.947607 secs); 16 Feb 2005 13:44:04 -0000 Received: from unknown (HELO mx3.openconsultancy.com) (10.2.0.36) by gi0-100-cr1.core.davidcoulson.net with SMTP; 16 Feb 2005 13:44:02 -0000 Received: (qmail 20186 invoked from network); 16 Feb 2005 13:44:02 -0000 Received: from unknown (HELO ?10.6.1.3?) (10.6.1.3) by vlan-102.core.davidcoulson.net with SMTP; 16 Feb 2005 13:44:02 -0000 Message-ID: <42134E22.4030808@davidcoulson.net> Date: Wed, 16 Feb 2005 08:44:02 -0500 From: David Coulson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J. Simonetti" CC: netdev@oss.sgi.com Subject: Re: 2.6.10 dst cache overflow References: <1108550412.3799.81.camel@ts2.office.netland.nl> In-Reply-To: <1108550412.3799.81.camel@ts2.office.netland.nl> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@davidcoulson.net Precedence: bulk X-list: netdev Content-Length: 947 Lines: 24 J. Simonetti wrote: > I have a linux (Fedora core 3) based router. I does approximately 50Mbps > aggregated traffic. However once every week (approx) the router dies > with 'kernel: dst cache overflow' messages flooding syslog. I have > tracked it down to being an issue with the routing cache. Funny this came up now - One of my core routers failed last night with the identical problem. The route cache was set to 131k routes, although I couldn't get a sh prompt on the box even once the switch ports were down... Had to sysrq-b it. I'm running 2.6.11-rc1-bk8 right now on those boxes. 20ish day uptime until yesterday and handling around 12Mbit of traffic. 'route -Cn | wc -l' right now shows around 29k routes cached. I cranked the route cache up to 1m entries, but I figure that's probably excessive. David -- David J. Coulson email: david@davidcoulson.net web: http://www.davidcoulson.net/ phone: (216) 920-3100 / (216) 258-4942 From Robert.Olsson@data.slu.se Wed Feb 16 06:28:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 06:28:38 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GESWux031459 for ; Wed, 16 Feb 2005 06:28:33 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j1GESVMu009098 for ; Wed, 16 Feb 2005 15:28:31 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 4D7CBEE2A4; Wed, 16 Feb 2005 15:28:31 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.22671.276946.919243@robur.slu.se> Date: Wed, 16 Feb 2005 15:28:31 +0100 To: David Coulson Cc: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: 2.6.10 dst cache overflow In-Reply-To: <42134E22.4030808@davidcoulson.net> References: <1108550412.3799.81.camel@ts2.office.netland.nl> <42134E22.4030808@davidcoulson.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1722 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: 1433 Lines: 39 David Coulson writes: > J. Simonetti wrote: > > I have a linux (Fedora core 3) based router. I does approximately 50Mbps > > aggregated traffic. However once every week (approx) the router dies > > with 'kernel: dst cache overflow' messages flooding syslog. I have > > tracked it down to being an issue with the routing cache. > > Funny this came up now - One of my core routers failed last night with > the identical problem. The route cache was set to 131k routes, although > I couldn't get a sh prompt on the box even once the switch ports were > down... Had to sysrq-b it. > > I'm running 2.6.11-rc1-bk8 right now on those boxes. 20ish day uptime > until yesterday and handling around 12Mbit of traffic. 'route -Cn | wc > -l' right now shows around 29k routes cached. I cranked the route cache > up to 1m entries, but I figure that's probably excessive. Hello! Very recently here on netdev "Memory leak in 2.6.11-rc1" was discussed this resulted in: > ===== net/ipv4/ip_output.c 1.74 vs edited ===== > --- 1.74/net/ipv4/ip_output.c 2005-01-25 01:40:10 +01:00 > +++ edited/net/ipv4/ip_output.c 2005-01-30 18:54:43 +01:00 > @@ -389,6 +389,7 @@ > to->priority = from->priority; > to->protocol = from->protocol; > to->security = from->security; > + dst_release(to->dst); > to->dst = dst_clone(from->dst); > to->dev = from->dev; and a similar patch for ipv6. Should be a start. --ro From Robert.Olsson@data.slu.se Wed Feb 16 06:59:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 06:59:57 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GExp9u000986 for ; Wed, 16 Feb 2005 06:59:52 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j1GExmjg016219; Wed, 16 Feb 2005 15:59:48 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 2EB5BEE2A4; Wed, 16 Feb 2005 15:59:48 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.24548.149702.188195@robur.slu.se> Date: Wed, 16 Feb 2005 15:59:48 +0100 To: "David S. Miller" Cc: Robert Olsson , netdev@oss.sgi.com, Jens.Laas@data.slu.se Subject: Re: Some pktgen fixes for 2.6.11-rc2 In-Reply-To: <20050215134120.3ae4c511.davem@davemloft.net> References: <16890.41237.608094.933695@robur.slu.se> <20050215134120.3ae4c511.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1723 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: 3290 Lines: 122 David S. Miller writes: > Robert, can you send me an updated patch against current > sources? Thanks a lot. Hello! Against linux-2.6.11-rc4 Some minor bugfixes and some clean ups. Yes version jumps with two. --ro --- net/core/pktgen.c.foo 2005-01-28 13:16:50.965630000 +0100 +++ net/core/pktgen.c 2005-01-28 16:51:32.932273576 +0100 @@ -148,7 +148,7 @@ #include -#define VERSION "pktgen v2.54: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.56: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -167,9 +167,6 @@ #define F_TXSIZE_RND (1<<6) /* Transmit size is random */ #define F_IPV6 (1<<7) /* Interface in IPV6 Mode */ -#define L_PUSH(t, i) {i->next = t; t=i;} -#define L_POP(t, i) {i=t; if(i) t = i->next;} - /* Thread control flag bits */ #define T_TERMINATE (1<<0) #define T_STOP (1<<1) /* Stop run */ @@ -1366,19 +1363,15 @@ p += sprintf(p, "Running: "); if_lock(t); - pkt_dev = t->if_list; - while (pkt_dev && pkt_dev->running) { - p += sprintf(p, "%s ", pkt_dev->ifname); - pkt_dev = pkt_dev->next; - } + for(pkt_dev = t->if_list;pkt_dev; pkt_dev = pkt_dev->next) + if(pkt_dev->running) + p += sprintf(p, "%s ", pkt_dev->ifname); + p += sprintf(p, "\nStopped: "); - pkt_dev = t->if_list; - while (pkt_dev && !pkt_dev->running) { - p += sprintf(p, "%s ", pkt_dev->ifname); - pkt_dev = pkt_dev->next; - } - + for(pkt_dev = t->if_list;pkt_dev; pkt_dev = pkt_dev->next) + if(!pkt_dev->running) + p += sprintf(p, "%s ", pkt_dev->ifname); if (t->result[0]) p += sprintf(p, "\nResult: %s\n", t->result); @@ -2393,7 +2386,7 @@ thread_unlock(); } -static int running(struct pktgen_thread *t ) +static int thread_is_running(struct pktgen_thread *t ) { struct pktgen_dev *next; int res = 0; @@ -2415,7 +2408,7 @@ if_lock(t); - while(running(t)) { + while(thread_is_running(t)) { if_unlock(t); interruptible_sleep_on_timeout(&queue, HZ/10); @@ -2520,13 +2513,15 @@ return -EINVAL; } - if (pkt_dev->skb) - kfree_skb(pkt_dev->skb); - pkt_dev->stopped_at = getCurUs(); pkt_dev->running = 0; show_results(pkt_dev, skb_shinfo(pkt_dev->skb)->nr_frags); + + if (pkt_dev->skb) + kfree_skb(pkt_dev->skb); + + pkt_dev->skb = NULL; return 0; } @@ -2855,10 +2850,10 @@ for(pkt_dev=t->if_list; pkt_dev; pkt_dev = pkt_dev->next ) { if (strcmp(pkt_dev->ifname, ifname) == 0) { - goto out; + break; } } - out: + if_unlock(t); PG_DEBUG(printk("pktgen: find_dev(%s) returning %p\n", ifname,pkt_dev)); return pkt_dev; @@ -2879,8 +2874,7 @@ rv = -EBUSY; goto out; } - - L_PUSH(t->if_list, pkt_dev); + pkt_dev->next =t->if_list; t->if_list=pkt_dev; pkt_dev->pg_thread = t; pkt_dev->running = 0; From david@davidcoulson.net Wed Feb 16 07:12:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 07:12:12 -0800 (PST) Received: from mail.mx.davidcoulson.net (ns1.openconsultancy.com [207.166.203.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GFC6FJ002135 for ; Wed, 16 Feb 2005 07:12:06 -0800 Received: (qmail 23705 invoked for bounce); 16 Feb 2005 15:12:00 +0000 Received: from unknown (HELO mx1.cluster.davidcoulson.net) (qmailr@10.1.1.2) by tailtiu.dmz.davidcoulson.net (qmail 1.03-djc-2) with SMTP; 16 Feb 2005 15:12:00 +0000 Received: (qmail 25273 invoked by uid 1002); 16 Feb 2005 15:12:00 -0000 Received: from 10.2.0.36 by cr1 (envelope-from , uid 64011) with qmail-scanner-1.24st (clamdscan: 0.80/694. spamassassin: 3.0.2. perlscan: 1.24st. Clear:RC:1(10.2.0.36):SA:0(-4.7/6.0):. Processed in 1.077094 secs); 16 Feb 2005 15:12:00 -0000 Received: from unknown (HELO mx3.openconsultancy.com) (10.2.0.36) by gi0-100-cr1.core.davidcoulson.net with SMTP; 16 Feb 2005 15:11:59 -0000 Received: (qmail 20432 invoked from network); 16 Feb 2005 15:11:58 -0000 Received: from unknown (HELO ?10.6.1.3?) (10.6.1.3) by vlan-102.core.davidcoulson.net with SMTP; 16 Feb 2005 15:11:58 -0000 Message-ID: <421362BD.7050708@davidcoulson.net> Date: Wed, 16 Feb 2005 10:11:57 -0500 From: David Coulson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: 2.6.10 dst cache overflow References: <1108550412.3799.81.camel@ts2.office.netland.nl> <42134E22.4030808@davidcoulson.net> <16915.22671.276946.919243@robur.slu.se> In-Reply-To: <16915.22671.276946.919243@robur.slu.se> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@davidcoulson.net Precedence: bulk X-list: netdev Content-Length: 341 Lines: 16 Robert Olsson wrote: > Very recently here on netdev "Memory leak in 2.6.11-rc1" was discussed > this resulted in: I see it's in 2.6.11-rc4 - I should probably just upgrade to that and see what happens :) David -- David J. Coulson email: david@davidcoulson.net web: http://www.davidcoulson.net/ phone: (216) 920-3100 / (216) 258-4942 From davem@davemloft.net Wed Feb 16 08:42:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 08:42:32 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GGgPaM009195 for ; Wed, 16 Feb 2005 08:42:26 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1SD8-0003vO-00; Wed, 16 Feb 2005 08:39:34 -0800 Date: Wed, 16 Feb 2005 08:39:34 -0800 From: "David S. Miller" To: Robert Olsson Cc: netdev@oss.sgi.com, Jens.Laas@data.slu.se Subject: Re: Some pktgen fixes for 2.6.11-rc2 Message-Id: <20050216083934.41bae852.davem@davemloft.net> In-Reply-To: <16915.24548.149702.188195@robur.slu.se> References: <16890.41237.608094.933695@robur.slu.se> <20050215134120.3ae4c511.davem@davemloft.net> <16915.24548.149702.188195@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 215 Lines: 7 On Wed, 16 Feb 2005 15:59:48 +0100 Robert Olsson wrote: > Against linux-2.6.11-rc4 > Some minor bugfixes and some clean ups. Yes version jumps with two. Applied, thanks a lot Robert. From mroos@linux.ee Wed Feb 16 09:27:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 09:27:51 -0800 (PST) Received: from math.ut.ee (math.ut.ee [193.40.36.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GHRhFm013196 for ; Wed, 16 Feb 2005 09:27:44 -0800 Received: from math.ut.ee (localhost [IPv6:::1]) by math.ut.ee (8.12.8+Sun/8.12.8/math-1.2) with ESMTP id j1GHRfaW012929 for ; Wed, 16 Feb 2005 19:27:41 +0200 (EET) Received: from localhost (mroos@localhost) by math.ut.ee (8.12.8+Sun/8.12.2/Submit) with ESMTP id j1GHRexJ012914 for ; Wed, 16 Feb 2005 19:27:41 +0200 (EET) X-Authentication-Warning: math.ut.ee: mroos owned process doing -bs Date: Wed, 16 Feb 2005 19:27:40 +0200 (EET) From: Meelis Roos To: netdev@oss.sgi.com Subject: Quieten privacy extensions message Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev Content-Length: 797 Lines: 25 It's not nice to see kernel internal pointers like this in dmesg: Disabled Privacy Extensions on device 00000000006a2970(lo) The patch removes the pointer from dmesg, resulting in Disabled Privacy Extensions on device lo Signed-off-by: Meelis Roos ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-17 23:13:31 +02:00 +++ edited/net/ipv6/addrconf.c 2005-02-16 19:21:59 +02:00 @@ -364,8 +364,8 @@ dev->type == ARPHRD_TUNNEL || dev->type == ARPHRD_SIT) { printk(KERN_INFO - "Disabled Privacy Extensions on device %p(%s)\n", - dev, dev->name); + "Disabled Privacy Extensions on device %s\n", + dev->name); ndev->cnf.use_tempaddr = -1; } else { in6_dev_hold(ndev); -- Meelis Roos (mroos@linux.ee) From megh.bhatt@gmail.com Wed Feb 16 09:36:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 09:36:08 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GHa4st014018 for ; Wed, 16 Feb 2005 09:36:04 -0800 Received: by wproxy.gmail.com with SMTP id 68so141620wri for ; Wed, 16 Feb 2005 09:35:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Z1XdxlnNs4z+OrbYwMWSJBHQk8A8UFtpy8U4bQhWpQicYkn2NTAuZeMKCAapbRKU1xiiqI7spvy4m7pxolZQdDuUHnsSQnqlwTkuhWaZJmRG6r9DQGzOVevlfsgqr7fX+1Txg3BnBxFc0hXrMBko76OonXQdHfPS5DJSenXXgjM= Received: by 10.54.35.49 with SMTP id i49mr277678wri; Wed, 16 Feb 2005 09:35:57 -0800 (PST) Received: by 10.54.41.7 with HTTP; Wed, 16 Feb 2005 09:35:57 -0800 (PST) Message-ID: <5d1f895705021609356e34aeec@mail.gmail.com> Date: Wed, 16 Feb 2005 12:35:57 -0500 From: Megh Bhatt Reply-To: Megh Bhatt To: netdev@oss.sgi.com Subject: Question about Linux routing - ip_route_output_key vs fib_lookup Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: megh.bhatt@gmail.com Precedence: bulk X-list: netdev Content-Length: 449 Lines: 10 Hi, I had a question about Linux routing functions, suppose I want to find out what interface does a route to an IP address belong to - is it better (in terms of performance) to use ip_route_output_key or fib_lookup. My initial guess from looking at the source code is fib_lookup since the routing cache wont be helpful since I wont have any interface information (rather want to find out interface information) but wanted to be sure. Thanks. Megh From davem@davemloft.net Wed Feb 16 09:54:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 09:54:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GHsBQv015173 for ; Wed, 16 Feb 2005 09:54:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1TJM-0004Fm-00; Wed, 16 Feb 2005 09:50:04 -0800 Date: Wed, 16 Feb 2005 09:50:04 -0800 From: "David S. Miller" To: Alexey Kuznetsov Cc: shemminger@osdl.org, hubert.tonneau@fullpliant.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-Id: <20050216095004.61f2ba4d.davem@davemloft.net> In-Reply-To: <20050216091323.GA26758@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <20050211150420.74737b2e@dxpl.pdx.osdl.net> <20050215152354.46a08d77.davem@davemloft.net> <20050216091323.GA26758@yakov.inr.ac.ru> X-Mailer: Sylpheed version 1.0.1 (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=_Wed__16_Feb_2005_09_50_04_-0800_Zbi.SACP4ddtnNZC" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 48657 Lines: 653 This is a multi-part message in MIME format. --Multipart=_Wed__16_Feb_2005_09_50_04_-0800_Zbi.SACP4ddtnNZC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 16 Feb 2005 12:13:23 +0300 Alexey Kuznetsov wrote: > BTW it is still a puzzle why 2.6.9 works. With disabled TSO it should > insert PSHs quite rarely, similarly to tso. Yes. Hubert, do you have netfilter enabled in the 2.6.10 kernel you are running? I'm asking because the TCP changes in 2.6.10 are pretty benign (attached for the curious who want to review along), whereas netfilter had major updates particularly in the TCP connection tracking code. I also reviewed 2.6.10-ac11 for anything interesting wrt. TCP and the only thing in there is the tcp_retrans_try_collapse() missing check to avoid collapsing TSO segments. --Multipart=_Wed__16_Feb_2005_09_50_04_-0800_Zbi.SACP4ddtnNZC Content-Type: application/octet-stream; name="tcp-2.6.10" Content-Disposition: attachment; filename="tcp-2.6.10" Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGEvaW5jbHVkZS9saW51eC90Y3AuaCBiL2luY2x1ZGUvbGludXgvdGNwLmgKLS0t IGEvaW5jbHVkZS9saW51eC90Y3AuaAkyMDA0LTEyLTI0IDEzOjM2OjQ5IC0wODowMAorKysgYi9p bmNsdWRlL2xpbnV4L3RjcC5oCTIwMDQtMTItMjQgMTM6MzY6NDkgLTA4OjAwCkBAIC0xODYsNiAr MTg2LDggQEAKIAogCV9fdTMyCXRjcGlfcmN2X3J0dDsKIAlfX3UzMgl0Y3BpX3Jjdl9zcGFjZTsK KworCV9fdTMyCXRjcGlfdG90YWxfcmV0cmFuczsKIH07CiAKICNpZmRlZiBfX0tFUk5FTF9fCkBA IC0zNjMsNiArMzY1LDggQEAKIAlfX3U4CXBlbmRpbmc7CS8qIFNjaGVkdWxlZCB0aW1lciBldmVu dAkqLwogCV9fdTgJdXJnX21vZGU7CS8qIEluIHVyZ2VudCBtb2RlCQkqLwogCV9fdTMyCXNuZF91 cDsJCS8qIFVyZ2VudCBwb2ludGVyCQkqLworCisJX191MzIJdG90YWxfcmV0cmFuczsJLyogVG90 YWwgcmV0cmFuc21pdHMgZm9yIGVudGlyZSBjb25uZWN0aW9uICovCiAKIAkvKiBUaGUgc3luX3dh aXRfbG9jayBpcyBuZWNlc3Nhcnkgb25seSB0byBhdm9pZCBwcm9jIGludGVyZmFjZSBoYXZpbmcK IAkgKiB0byBncmFiIHRoZSBtYWluIGxvY2sgc29jayB3aGlsZSBicm93c2luZyB0aGUgbGlzdGVu aW5nIGhhc2gKZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvdGNwLmggYi9pbmNsdWRlL25ldC90Y3Au aAotLS0gYS9pbmNsdWRlL25ldC90Y3AuaAkyMDA0LTEyLTI0IDEzOjM2OjE4IC0wODowMAorKysg Yi9pbmNsdWRlL25ldC90Y3AuaAkyMDA0LTEyLTI0IDEzOjM2OjE4IC0wODowMApAQCAtMTU5LDcg KzE1OSw2IEBACiBleHRlcm4gdm9pZCB0Y3BfYnVja2V0X2Rlc3Ryb3koc3RydWN0IHRjcF9iaW5k X2J1Y2tldCAqdGIpOwogZXh0ZXJuIHZvaWQgdGNwX2J1Y2tldF91bmxvY2soc3RydWN0IHNvY2sg KnNrKTsKIGV4dGVybiBpbnQgdGNwX3BvcnRfcm92ZXI7Ci1leHRlcm4gc3RydWN0IHNvY2sgKnRj cF92NF9sb29rdXBfbGlzdGVuZXIodTMyIGFkZHIsIHVuc2lnbmVkIHNob3J0IGhudW0sIGludCBk aWYpOwogCiAvKiBUaGVzZSBhcmUgQUYgaW5kZXBlbmRlbnQuICovCiBzdGF0aWMgX19pbmxpbmVf XyBpbnQgdGNwX2JoYXNoZm4oX191MTYgbHBvcnQpCkBAIC0zNjIsOCArMzYxLDggQEAKICNkZWZp bmUgVENQX0lQVjZfTUFUQ0goX19zaywgX19zYWRkciwgX19kYWRkciwgX19wb3J0cywgX19kaWYp CSAgIFwKIAkoKCgqKChfX3UzMiAqKSYoaW5ldF9zayhfX3NrKS0+ZHBvcnQpKSk9PSAoX19wb3J0 cykpICAgCSYmIFwKIAkgKChfX3NrKS0+c2tfZmFtaWx5CQk9PSBBRl9JTkVUNikJCSYmIFwKLQkg IWlwdjZfYWRkcl9jbXAoJmluZXQ2X3NrKF9fc2spLT5kYWRkciwgKF9fc2FkZHIpKQkmJiBcCi0J ICFpcHY2X2FkZHJfY21wKCZpbmV0Nl9zayhfX3NrKS0+cmN2X3NhZGRyLCAoX19kYWRkcikpCSYm IFwKKwkgaXB2Nl9hZGRyX2VxdWFsKCZpbmV0Nl9zayhfX3NrKS0+ZGFkZHIsIChfX3NhZGRyKSkJ JiYgXAorCSBpcHY2X2FkZHJfZXF1YWwoJmluZXQ2X3NrKF9fc2spLT5yY3Zfc2FkZHIsIChfX2Rh ZGRyKSkJJiYgXAogCSAoISgoX19zayktPnNrX2JvdW5kX2Rldl9pZikgfHwgKChfX3NrKS0+c2tf Ym91bmRfZGV2X2lmID09IChfX2RpZikpKSkKIAogLyogVGhlc2UgY2FuIGhhdmUgd2lsZGNhcmRz LCBkb24ndCB0cnkgdG9vIGhhcmQuICovCkBAIC05NjEsMTIgKzk2MCwxNCBAQAogZXh0ZXJuIHZv aWQgdGNwX2luaXRfeG1pdF90aW1lcnMoc3RydWN0IHNvY2sgKik7CiBleHRlcm4gdm9pZCB0Y3Bf Y2xlYXJfeG1pdF90aW1lcnMoc3RydWN0IHNvY2sgKik7CiAKLWV4dGVybiB2b2lkIHRjcF9kZWxl dGVfa2VlcGFsaXZlX3RpbWVyIChzdHJ1Y3Qgc29jayAqKTsKLWV4dGVybiB2b2lkIHRjcF9yZXNl dF9rZWVwYWxpdmVfdGltZXIgKHN0cnVjdCBzb2NrICosIHVuc2lnbmVkIGxvbmcpOworZXh0ZXJu IHZvaWQgdGNwX2RlbGV0ZV9rZWVwYWxpdmVfdGltZXIoc3RydWN0IHNvY2sgKik7CitleHRlcm4g dm9pZCB0Y3BfcmVzZXRfa2VlcGFsaXZlX3RpbWVyKHN0cnVjdCBzb2NrICosIHVuc2lnbmVkIGxv bmcpOwogZXh0ZXJuIHVuc2lnbmVkIGludCB0Y3Bfc3luY19tc3Moc3RydWN0IHNvY2sgKnNrLCB1 MzIgcG10dSk7CiBleHRlcm4gdW5zaWduZWQgaW50IHRjcF9jdXJyZW50X21zcyhzdHJ1Y3Qgc29j ayAqc2ssIGludCBsYXJnZSk7CiAKLWV4dGVybiBjb25zdCBjaGFyIHRpbWVyX2J1Z19tc2dbXTsK KyNpZmRlZiBUQ1BfREVCVUcKK2V4dGVybiBjb25zdCBjaGFyIHRjcF90aW1lcl9idWdfbXNnW107 CisjZW5kaWYKIAogLyogdGNwX2RpYWcuYyAqLwogZXh0ZXJuIHZvaWQgdGNwX2dldF9pbmZvKHN0 cnVjdCBzb2NrICosIHN0cnVjdCB0Y3BfaW5mbyAqKTsKQEAgLTk5OSw3ICsxMDAwLDkgQEAKICNl bmRpZgogCQlicmVhazsKIAlkZWZhdWx0OgotCQlwcmludGsodGltZXJfYnVnX21zZyk7CisjaWZk ZWYgVENQX0RFQlVHCisJCXByaW50ayh0Y3BfdGltZXJfYnVnX21zZyk7CisjZW5kaWYKIAkJcmV0 dXJuOwogCX07CiAKQEAgLTEwMzQsNyArMTAzNyw5IEBACiAJCWJyZWFrOwogCiAJZGVmYXVsdDoK LQkJcHJpbnRrKHRpbWVyX2J1Z19tc2cpOworI2lmZGVmIFRDUF9ERUJVRworCQlwcmludGsodGNw X3RpbWVyX2J1Z19tc2cpOworI2VuZGlmCiAJfTsKIH0KIApAQCAtMTA4Myw3ICsxMDg4LDcgQEAK ICAqIFJjdl9ueHQgY2FuIGJlIGFmdGVyIHRoZSB3aW5kb3cgaWYgb3VyIHBlZXIgcHVzaCBtb3Jl IGRhdGEKICAqIHRoYW4gdGhlIG9mZmVyZWQgd2luZG93LgogICovCi1zdGF0aWMgX19pbmxpbmVf XyB1MzIgdGNwX3JlY2VpdmVfd2luZG93KHN0cnVjdCB0Y3Bfb3B0ICp0cCkKK3N0YXRpYyBfX2lu bGluZV9fIHUzMiB0Y3BfcmVjZWl2ZV93aW5kb3coY29uc3Qgc3RydWN0IHRjcF9vcHQgKnRwKQog ewogCXMzMiB3aW4gPSB0cC0+cmN2X3d1cCArIHRwLT5yY3Zfd25kIC0gdHAtPnJjdl9ueHQ7CiAK QEAgLTExNjEsMTggKzExNjYsMTkgQEAKIC8qIER1ZSB0byBUU08sIGFuIFNLQiBjYW4gYmUgY29t cG9zZWQgb2YgbXVsdGlwbGUgYWN0dWFsCiAgKiBwYWNrZXRzLiAgVG8ga2VlcCB0aGVzZSB0cmFj a2VkIHByb3Blcmx5LCB3ZSB1c2UgdGhpcy4KICAqLwotc3RhdGljIGlubGluZSBpbnQgdGNwX3Nr Yl9wY291bnQoc3RydWN0IHNrX2J1ZmYgKnNrYikKK3N0YXRpYyBpbmxpbmUgaW50IHRjcF9za2Jf cGNvdW50KGNvbnN0IHN0cnVjdCBza19idWZmICpza2IpCiB7CiAJcmV0dXJuIHNrYl9zaGluZm8o c2tiKS0+dHNvX3NlZ3M7CiB9CiAKIC8qIFRoaXMgaXMgdmFsaWQgaWZmIHRjcF9za2JfcGNvdW50 KCkgPiAxLiAqLwotc3RhdGljIGlubGluZSBpbnQgdGNwX3NrYl9tc3Moc3RydWN0IHNrX2J1ZmYg KnNrYikKK3N0YXRpYyBpbmxpbmUgaW50IHRjcF9za2JfbXNzKGNvbnN0IHN0cnVjdCBza19idWZm ICpza2IpCiB7CiAJcmV0dXJuIHNrYl9zaGluZm8oc2tiKS0+dHNvX3NpemU7CiB9CiAKLXN0YXRp YyBpbmxpbmUgdm9pZCB0Y3BfaW5jX3Bjb3VudCh0Y3BfcGNvdW50X3QgKmNvdW50LCBzdHJ1Y3Qg c2tfYnVmZiAqc2tiKQorc3RhdGljIGlubGluZSB2b2lkIHRjcF9pbmNfcGNvdW50KHRjcF9wY291 bnRfdCAqY291bnQsCisJCQkJICBjb25zdCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogewogCWNvdW50 LT52YWwgKz0gdGNwX3NrYl9wY291bnQoc2tiKTsKIH0KQEAgLTExODcsMTMgKzExOTMsMTQgQEAK IAljb3VudC0+dmFsIC09IGFtdDsKIH0KIAotc3RhdGljIGlubGluZSB2b2lkIHRjcF9kZWNfcGNv dW50KHRjcF9wY291bnRfdCAqY291bnQsIHN0cnVjdCBza19idWZmICpza2IpCitzdGF0aWMgaW5s aW5lIHZvaWQgdGNwX2RlY19wY291bnQodGNwX3Bjb3VudF90ICpjb3VudCwgCisJCQkJICBjb25z dCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogewogCWNvdW50LT52YWwgLT0gdGNwX3NrYl9wY291bnQo c2tiKTsKIH0KIAogc3RhdGljIGlubGluZSB2b2lkIHRjcF9kZWNfcGNvdW50X2FwcHJveCh0Y3Bf cGNvdW50X3QgKmNvdW50LAotCQkJCQkgc3RydWN0IHNrX2J1ZmYgKnNrYikKKwkJCQkJIGNvbnN0 IHN0cnVjdCBza19idWZmICpza2IpCiB7CiAJaWYgKGNvdW50LT52YWwpIHsKIAkJY291bnQtPnZh bCAtPSB0Y3Bfc2tiX3Bjb3VudChza2IpOwpAQCAtMTIwMiw3ICsxMjA5LDcgQEAKIAl9CiB9CiAK LXN0YXRpYyBpbmxpbmUgX191MzIgdGNwX2dldF9wY291bnQodGNwX3Bjb3VudF90ICpjb3VudCkK K3N0YXRpYyBpbmxpbmUgX191MzIgdGNwX2dldF9wY291bnQoY29uc3QgdGNwX3Bjb3VudF90ICpj b3VudCkKIHsKIAlyZXR1cm4gY291bnQtPnZhbDsKIH0KQEAgLTEyMTIsOCArMTIxOSw5IEBACiAJ Y291bnQtPnZhbCA9IHZhbDsKIH0KIAotc3RhdGljIGlubGluZSB2b2lkIHRjcF9wYWNrZXRzX291 dF9pbmMoc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgdGNwX29wdCAqdHAsCi0JCQkJICAgICAgIHN0 cnVjdCBza19idWZmICpza2IpCitzdGF0aWMgaW5saW5lIHZvaWQgdGNwX3BhY2tldHNfb3V0X2lu YyhzdHJ1Y3Qgc29jayAqc2ssIAorCQkJCSAgICAgICBzdHJ1Y3QgdGNwX29wdCAqdHAsCisJCQkJ ICAgICAgIGNvbnN0IHN0cnVjdCBza19idWZmICpza2IpCiB7CiAJaW50IG9yaWcgPSB0Y3BfZ2V0 X3Bjb3VudCgmdHAtPnBhY2tldHNfb3V0KTsKIApAQCAtMTIyMiw3ICsxMjMwLDggQEAKIAkJdGNw X3Jlc2V0X3htaXRfdGltZXIoc2ssIFRDUF9USU1FX1JFVFJBTlMsIHRwLT5ydG8pOwogfQogCi1z dGF0aWMgaW5saW5lIHZvaWQgdGNwX3BhY2tldHNfb3V0X2RlYyhzdHJ1Y3QgdGNwX29wdCAqdHAs IHN0cnVjdCBza19idWZmICpza2IpCitzdGF0aWMgaW5saW5lIHZvaWQgdGNwX3BhY2tldHNfb3V0 X2RlYyhzdHJ1Y3QgdGNwX29wdCAqdHAsIAorCQkJCSAgICAgICBjb25zdCBzdHJ1Y3Qgc2tfYnVm ZiAqc2tiKQogewogCXRjcF9kZWNfcGNvdW50KCZ0cC0+cGFja2V0c19vdXQsIHNrYik7CiB9CkBA IC0xMjQxLDcgKzEyNTAsNyBAQAogICoJIlBhY2tldHMgbGVmdCBuZXR3b3JrLCBidXQgbm90IGhv bmVzdGx5IEFDS2VkIHlldCIgUExVUwogICoJIlBhY2tldHMgZmFzdCByZXRyYW5zbWl0dGVkIgog ICovCi1zdGF0aWMgX19pbmxpbmVfXyB1bnNpZ25lZCBpbnQgdGNwX3BhY2tldHNfaW5fZmxpZ2h0 KHN0cnVjdCB0Y3Bfb3B0ICp0cCkKK3N0YXRpYyBfX2lubGluZV9fIHVuc2lnbmVkIGludCB0Y3Bf cGFja2V0c19pbl9mbGlnaHQoY29uc3Qgc3RydWN0IHRjcF9vcHQgKnRwKQogewogCXJldHVybiAo dGNwX2dldF9wY291bnQoJnRwLT5wYWNrZXRzX291dCkgLQogCQl0Y3BfZ2V0X3Bjb3VudCgmdHAt PmxlZnRfb3V0KSArCkBAIC0xNDA4LDE4ICsxNDE3LDE5IEBACiAvKiBTbG93IHN0YXJ0IHdpdGgg ZGVsYWNrIHByb2R1Y2VzIDMgcGFja2V0cyBvZiBidXJzdCwgc28gdGhhdAogICogaXQgaXMgc2Fm ZSAiZGUgZmFjdG8iLgogICovCi1zdGF0aWMgX19pbmxpbmVfXyBfX3UzMiB0Y3BfbWF4X2J1cnN0 KHN0cnVjdCB0Y3Bfb3B0ICp0cCkKK3N0YXRpYyBfX2lubGluZV9fIF9fdTMyIHRjcF9tYXhfYnVy c3QoY29uc3Qgc3RydWN0IHRjcF9vcHQgKnRwKQogewogCXJldHVybiAzOwogfQogCi1zdGF0aWMg X19pbmxpbmVfXyBpbnQgdGNwX21pbnNoYWxsX2NoZWNrKHN0cnVjdCB0Y3Bfb3B0ICp0cCkKK3N0 YXRpYyBfX2lubGluZV9fIGludCB0Y3BfbWluc2hhbGxfY2hlY2soY29uc3Qgc3RydWN0IHRjcF9v cHQgKnRwKQogewogCXJldHVybiBhZnRlcih0cC0+c25kX3NtbCx0cC0+c25kX3VuYSkgJiYKIAkJ IWFmdGVyKHRwLT5zbmRfc21sLCB0cC0+c25kX254dCk7CiB9CiAKLXN0YXRpYyBfX2lubGluZV9f IHZvaWQgdGNwX21pbnNoYWxsX3VwZGF0ZShzdHJ1Y3QgdGNwX29wdCAqdHAsIGludCBtc3MsIHN0 cnVjdCBza19idWZmICpza2IpCitzdGF0aWMgX19pbmxpbmVfXyB2b2lkIHRjcF9taW5zaGFsbF91 cGRhdGUoc3RydWN0IHRjcF9vcHQgKnRwLCBpbnQgbXNzLCAKKwkJCQkJICAgY29uc3Qgc3RydWN0 IHNrX2J1ZmYgKnNrYikKIHsKIAlpZiAoc2tiLT5sZW4gPCBtc3MpCiAJCXRwLT5zbmRfc21sID0g VENQX1NLQl9DQihza2IpLT5lbmRfc2VxOwpAQCAtMTQzNCw3ICsxNDQ0LDggQEAKICAqLwogCiBz dGF0aWMgX19pbmxpbmVfXyBpbnQKLXRjcF9uYWdsZV9jaGVjayhzdHJ1Y3QgdGNwX29wdCAqdHAs IHN0cnVjdCBza19idWZmICpza2IsIHVuc2lnbmVkIG1zc19ub3csIGludCBub25hZ2xlKQordGNw X25hZ2xlX2NoZWNrKGNvbnN0IHN0cnVjdCB0Y3Bfb3B0ICp0cCwgY29uc3Qgc3RydWN0IHNrX2J1 ZmYgKnNrYiwgCisJCXVuc2lnbmVkIG1zc19ub3csIGludCBub25hZ2xlKQogewogCXJldHVybiAo c2tiLT5sZW4gPCBtc3Nfbm93ICYmCiAJCSEoVENQX1NLQl9DQihza2IpLT5mbGFncyAmIFRDUENC X0ZMQUdfRklOKSAmJgpAQCAtMTQ0OSw3ICsxNDYwLDggQEAKIC8qIFRoaXMgY2hlY2tzIGlmIHRo ZSBkYXRhIGJlYXJpbmcgcGFja2V0IFNLQiAodXN1YWxseSBzay0+c2tfc2VuZF9oZWFkKQogICog c2hvdWxkIGJlIHB1dCBvbiB0aGUgd2lyZSByaWdodCBub3cuCiAgKi8KLXN0YXRpYyBfX2lubGlu ZV9fIGludCB0Y3Bfc25kX3Rlc3Qoc3RydWN0IHRjcF9vcHQgKnRwLCBzdHJ1Y3Qgc2tfYnVmZiAq c2tiLAorc3RhdGljIF9faW5saW5lX18gaW50IHRjcF9zbmRfdGVzdChjb25zdCBzdHJ1Y3QgdGNw X29wdCAqdHAsIAorCQkJCSAgIHN0cnVjdCBza19idWZmICpza2IsCiAJCQkJICAgdW5zaWduZWQg Y3VyX21zcywgaW50IG5vbmFnbGUpCiB7CiAJaW50IHBrdHMgPSB0Y3Bfc2tiX3Bjb3VudChza2Ip OwpAQCAtMTQ5Niw3ICsxNTA4LDggQEAKIAkJdGNwX3Jlc2V0X3htaXRfdGltZXIoc2ssIFRDUF9U SU1FX1BST0JFMCwgdHAtPnJ0byk7CiB9CiAKLXN0YXRpYyBfX2lubGluZV9fIGludCB0Y3Bfc2ti X2lzX2xhc3Qoc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQorc3RhdGljIF9f aW5saW5lX18gaW50IHRjcF9za2JfaXNfbGFzdChjb25zdCBzdHJ1Y3Qgc29jayAqc2ssIAorCQkJ CSAgICAgIGNvbnN0IHN0cnVjdCBza19idWZmICpza2IpCiB7CiAJcmV0dXJuIHNrYi0+bmV4dCA9 PSAoc3RydWN0IHNrX2J1ZmYgKikmc2stPnNrX3dyaXRlX3F1ZXVlOwogfQpAQCAtMTU0Nyw3ICsx NTYwLDcgQEAKIAl0cC0+c25kX3dsMSA9IHNlcTsKIH0KIAotZXh0ZXJuIHZvaWQJCQl0Y3BfZGVz dHJveV9zb2NrKHN0cnVjdCBzb2NrICpzayk7CitleHRlcm4gdm9pZCB0Y3BfZGVzdHJveV9zb2Nr KHN0cnVjdCBzb2NrICpzayk7CiAKIAogLyoKQEAgLTE2MjEsNyArMTYzNCw3IEBACiAjdW5kZWYg U1RBVEVfVFJBQ0UKIAogI2lmZGVmIFNUQVRFX1RSQUNFCi1zdGF0aWMgY2hhciAqc3RhdGVuYW1l W109eworc3RhdGljIGNvbnN0IGNoYXIgKnN0YXRlbmFtZVtdPXsKIAkiVW51c2VkIiwiRXN0YWJs aXNoZWQiLCJTeW4gU2VudCIsIlN5biBSZWN2IiwKIAkiRmluIFdhaXQgMSIsIkZpbiBXYWl0IDIi LCJUaW1lIFdhaXQiLCAiQ2xvc2UiLAogCSJDbG9zZSBXYWl0IiwiTGFzdCBBQ0siLCJMaXN0ZW4i LCJDbG9zaW5nIgpAQCAtMTg5MiwxNyArMTkwNSwxNyBAQAogCQl3YWtlX3VwKCZ0Y3BfbGhhc2hf d2FpdCk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgaW50IGtlZXBhbGl2ZV9pbnR2bF93aGVuKHN0cnVj dCB0Y3Bfb3B0ICp0cCkKK3N0YXRpYyBpbmxpbmUgaW50IGtlZXBhbGl2ZV9pbnR2bF93aGVuKGNv bnN0IHN0cnVjdCB0Y3Bfb3B0ICp0cCkKIHsKIAlyZXR1cm4gdHAtPmtlZXBhbGl2ZV9pbnR2bCA/ IDogc3lzY3RsX3RjcF9rZWVwYWxpdmVfaW50dmw7CiB9CiAKLXN0YXRpYyBpbmxpbmUgaW50IGtl ZXBhbGl2ZV90aW1lX3doZW4oc3RydWN0IHRjcF9vcHQgKnRwKQorc3RhdGljIGlubGluZSBpbnQg a2VlcGFsaXZlX3RpbWVfd2hlbihjb25zdCBzdHJ1Y3QgdGNwX29wdCAqdHApCiB7CiAJcmV0dXJu IHRwLT5rZWVwYWxpdmVfdGltZSA/IDogc3lzY3RsX3RjcF9rZWVwYWxpdmVfdGltZTsKIH0KIAot c3RhdGljIGlubGluZSBpbnQgdGNwX2Zpbl90aW1lKHN0cnVjdCB0Y3Bfb3B0ICp0cCkKK3N0YXRp YyBpbmxpbmUgaW50IHRjcF9maW5fdGltZShjb25zdCBzdHJ1Y3QgdGNwX29wdCAqdHApCiB7CiAJ aW50IGZpbl90aW1lb3V0ID0gdHAtPmxpbmdlcjIgPyA6IHN5c2N0bF90Y3BfZmluX3RpbWVvdXQ7 CiAKQEAgLTE5MTIsNyArMTkyNSw3IEBACiAJcmV0dXJuIGZpbl90aW1lb3V0OwogfQogCi1zdGF0 aWMgaW5saW5lIGludCB0Y3BfcGF3c19jaGVjayhzdHJ1Y3QgdGNwX29wdCAqdHAsIGludCByc3Qp CitzdGF0aWMgaW5saW5lIGludCB0Y3BfcGF3c19jaGVjayhjb25zdCBzdHJ1Y3QgdGNwX29wdCAq dHAsIGludCByc3QpCiB7CiAJaWYgKChzMzIpKHRwLT5yY3ZfdHN2YWwgLSB0cC0+dHNfcmVjZW50 KSA+PSAwKQogCQlyZXR1cm4gMDsKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwLmMgYi9uZXQvaXB2 NC90Y3AuYwotLS0gYS9uZXQvaXB2NC90Y3AuYwkyMDA0LTEyLTI0IDEzOjM2OjMxIC0wODowMAor KysgYi9uZXQvaXB2NC90Y3AuYwkyMDA0LTEyLTI0IDEzOjM2OjMxIC0wODowMApAQCAtNDY3LDcg KzQ2Nyw3IEBACiAJc2stPnNrX21heF9hY2tfYmFja2xvZyA9IDA7CiAJc2stPnNrX2Fja19iYWNr bG9nID0gMDsKIAl0cC0+YWNjZXB0X3F1ZXVlID0gdHAtPmFjY2VwdF9xdWV1ZV90YWlsID0gTlVM TDsKLQl0cC0+c3luX3dhaXRfbG9jayA9IFJXX0xPQ0tfVU5MT0NLRUQ7CisJcndsb2NrX2luaXQo JnRwLT5zeW5fd2FpdF9sb2NrKTsKIAl0Y3BfZGVsYWNrX2luaXQodHApOwogCiAJbG9wdCA9IGtt YWxsb2Moc2l6ZW9mKHN0cnVjdCB0Y3BfbGlzdGVuX29wdCksIEdGUF9LRVJORUwpOwpAQCAtMjA5 NSw2ICsyMDk1LDY1IEBACiAJcmV0dXJuIGVycjsKIH0KIAorLyogUmV0dXJuIGluZm9ybWF0aW9u IGFib3V0IHN0YXRlIG9mIHRjcCBlbmRwb2ludCBpbiBBUEkgZm9ybWF0LiAqLwordm9pZCB0Y3Bf Z2V0X2luZm8oc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgdGNwX2luZm8gKmluZm8pCit7CisJc3Ry dWN0IHRjcF9vcHQgKnRwID0gdGNwX3NrKHNrKTsKKwl1MzIgbm93ID0gdGNwX3RpbWVfc3RhbXA7 CisKKwltZW1zZXQoaW5mbywgMCwgc2l6ZW9mKCppbmZvKSk7CisKKwlpbmZvLT50Y3BpX3N0YXRl ID0gc2stPnNrX3N0YXRlOworCWluZm8tPnRjcGlfY2Ffc3RhdGUgPSB0cC0+Y2Ffc3RhdGU7CisJ aW5mby0+dGNwaV9yZXRyYW5zbWl0cyA9IHRwLT5yZXRyYW5zbWl0czsKKwlpbmZvLT50Y3BpX3By b2JlcyA9IHRwLT5wcm9iZXNfb3V0OworCWluZm8tPnRjcGlfYmFja29mZiA9IHRwLT5iYWNrb2Zm OworCisJaWYgKHRwLT50c3RhbXBfb2spCisJCWluZm8tPnRjcGlfb3B0aW9ucyB8PSBUQ1BJX09Q VF9USU1FU1RBTVBTOworCWlmICh0cC0+c2Fja19vaykKKwkJaW5mby0+dGNwaV9vcHRpb25zIHw9 IFRDUElfT1BUX1NBQ0s7CisJaWYgKHRwLT53c2NhbGVfb2spIHsKKwkJaW5mby0+dGNwaV9vcHRp b25zIHw9IFRDUElfT1BUX1dTQ0FMRTsKKwkJaW5mby0+dGNwaV9zbmRfd3NjYWxlID0gdHAtPnNu ZF93c2NhbGU7CisJCWluZm8tPnRjcGlfcmN2X3dzY2FsZSA9IHRwLT5yY3Zfd3NjYWxlOworCX0g CisKKwlpZiAodHAtPmVjbl9mbGFncyZUQ1BfRUNOX09LKQorCQlpbmZvLT50Y3BpX29wdGlvbnMg fD0gVENQSV9PUFRfRUNOOworCisJaW5mby0+dGNwaV9ydG8gPSBqaWZmaWVzX3RvX3VzZWNzKHRw LT5ydG8pOworCWluZm8tPnRjcGlfYXRvID0gamlmZmllc190b191c2Vjcyh0cC0+YWNrLmF0byk7 CisJaW5mby0+dGNwaV9zbmRfbXNzID0gdHAtPm1zc19jYWNoZV9zdGQ7CisJaW5mby0+dGNwaV9y Y3ZfbXNzID0gdHAtPmFjay5yY3ZfbXNzOworCisJaW5mby0+dGNwaV91bmFja2VkID0gdGNwX2dl dF9wY291bnQoJnRwLT5wYWNrZXRzX291dCk7CisJaW5mby0+dGNwaV9zYWNrZWQgPSB0Y3BfZ2V0 X3Bjb3VudCgmdHAtPnNhY2tlZF9vdXQpOworCWluZm8tPnRjcGlfbG9zdCA9IHRjcF9nZXRfcGNv dW50KCZ0cC0+bG9zdF9vdXQpOworCWluZm8tPnRjcGlfcmV0cmFucyA9IHRjcF9nZXRfcGNvdW50 KCZ0cC0+cmV0cmFuc19vdXQpOworCWluZm8tPnRjcGlfZmFja2V0cyA9IHRjcF9nZXRfcGNvdW50 KCZ0cC0+ZmFja2V0c19vdXQpOworCisJaW5mby0+dGNwaV9sYXN0X2RhdGFfc2VudCA9IGppZmZp ZXNfdG9fbXNlY3Mobm93IC0gdHAtPmxzbmR0aW1lKTsKKwlpbmZvLT50Y3BpX2xhc3RfZGF0YV9y ZWN2ID0gamlmZmllc190b19tc2Vjcyhub3cgLSB0cC0+YWNrLmxyY3Z0aW1lKTsKKwlpbmZvLT50 Y3BpX2xhc3RfYWNrX3JlY3YgPSBqaWZmaWVzX3RvX21zZWNzKG5vdyAtIHRwLT5yY3ZfdHN0YW1w KTsKKworCWluZm8tPnRjcGlfcG10dSA9IHRwLT5wbXR1X2Nvb2tpZTsKKwlpbmZvLT50Y3BpX3Jj dl9zc3RocmVzaCA9IHRwLT5yY3Zfc3N0aHJlc2g7CisJaW5mby0+dGNwaV9ydHQgPSBqaWZmaWVz X3RvX3VzZWNzKHRwLT5zcnR0KT4+MzsKKwlpbmZvLT50Y3BpX3J0dHZhciA9IGppZmZpZXNfdG9f dXNlY3ModHAtPm1kZXYpPj4yOworCWluZm8tPnRjcGlfc25kX3NzdGhyZXNoID0gdHAtPnNuZF9z c3RocmVzaDsKKwlpbmZvLT50Y3BpX3NuZF9jd25kID0gdHAtPnNuZF9jd25kOworCWluZm8tPnRj cGlfYWR2bXNzID0gdHAtPmFkdm1zczsKKwlpbmZvLT50Y3BpX3Jlb3JkZXJpbmcgPSB0cC0+cmVv cmRlcmluZzsKKworCWluZm8tPnRjcGlfcmN2X3J0dCA9IGppZmZpZXNfdG9fdXNlY3ModHAtPnJj dl9ydHRfZXN0LnJ0dCk+PjM7CisJaW5mby0+dGNwaV9yY3Zfc3BhY2UgPSB0cC0+cmN2cV9zcGFj ZS5zcGFjZTsKKworCWluZm8tPnRjcGlfdG90YWxfcmV0cmFucyA9IHRwLT50b3RhbF9yZXRyYW5z OworfQorCitFWFBPUlRfU1lNQk9MX0dQTCh0Y3BfZ2V0X2luZm8pOworCiBpbnQgdGNwX2dldHNv Y2tvcHQoc3RydWN0IHNvY2sgKnNrLCBpbnQgbGV2ZWwsIGludCBvcHRuYW1lLCBjaGFyIF9fdXNl ciAqb3B0dmFsLAogCQkgICBpbnQgX191c2VyICpvcHRsZW4pCiB7CkBAIC0yMjUwLDcgKzIzMDks NyBAQAogCWlmICghdGNwX2VoYXNoKQogCQlwYW5pYygiRmFpbGVkIHRvIGFsbG9jYXRlIFRDUCBl c3RhYmxpc2hlZCBoYXNoIHRhYmxlXG4iKTsKIAlmb3IgKGkgPSAwOyBpIDwgKHRjcF9laGFzaF9z aXplIDw8IDEpOyBpKyspIHsKLQkJdGNwX2VoYXNoW2ldLmxvY2sgPSBSV19MT0NLX1VOTE9DS0VE OworCQlyd2xvY2tfaW5pdCgmdGNwX2VoYXNoW2ldLmxvY2spOwogCQlJTklUX0hMSVNUX0hFQUQo JnRjcF9laGFzaFtpXS5jaGFpbik7CiAJfQogCkBAIC0yMjY2LDcgKzIzMjUsNyBAQAogCWlmICgh dGNwX2JoYXNoKQogCQlwYW5pYygiRmFpbGVkIHRvIGFsbG9jYXRlIFRDUCBiaW5kIGhhc2ggdGFi bGVcbiIpOwogCWZvciAoaSA9IDA7IGkgPCB0Y3BfYmhhc2hfc2l6ZTsgaSsrKSB7Ci0JCXRjcF9i aGFzaFtpXS5sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VEOworCQlzcGluX2xvY2tfaW5pdCgmdGNw X2JoYXNoW2ldLmxvY2spOwogCQlJTklUX0hMSVNUX0hFQUQoJnRjcF9iaGFzaFtpXS5jaGFpbik7 CiAJfQogCkBAIC0yMzAxLDEzICsyMzYwLDEwIEBACiAJcHJpbnRrKEtFUk5fSU5GTyAiVENQOiBI YXNoIHRhYmxlcyBjb25maWd1cmVkICIKIAkgICAgICAgIihlc3RhYmxpc2hlZCAlZCBiaW5kICVk KVxuIiwKIAkgICAgICAgdGNwX2VoYXNoX3NpemUgPDwgMSwgdGNwX2JoYXNoX3NpemUpOwotCi0J dGNwZGlhZ19pbml0KCk7CiB9CiAKIEVYUE9SVF9TWU1CT0wodGNwX2FjY2VwdCk7CiBFWFBPUlRf U1lNQk9MKHRjcF9jbG9zZSk7Ci1FWFBPUlRfU1lNQk9MKHRjcF9jbG9zZV9zdGF0ZSk7CiBFWFBP UlRfU1lNQk9MKHRjcF9kZXN0cm95X3NvY2spOwogRVhQT1JUX1NZTUJPTCh0Y3BfZGlzY29ubmVj dCk7CiBFWFBPUlRfU1lNQk9MKHRjcF9nZXRzb2Nrb3B0KTsKZGlmZiAtTnJ1IGEvbmV0L2lwdjQv dGNwX2RpYWcuYyBiL25ldC9pcHY0L3RjcF9kaWFnLmMKLS0tIGEvbmV0L2lwdjQvdGNwX2RpYWcu YwkyMDA0LTEyLTI0IDEzOjM2OjE3IC0wODowMAorKysgYi9uZXQvaXB2NC90Y3BfZGlhZy5jCTIw MDQtMTItMjQgMTM6MzY6MTcgLTA4OjAwCkBAIC0xOCw2ICsxOCw3IEBACiAjaW5jbHVkZSA8bGlu dXgvcmFuZG9tLmg+CiAjaW5jbHVkZSA8bGludXgvY2FjaGUuaD4KICNpbmNsdWRlIDxsaW51eC9p bml0Lmg+CisjaW5jbHVkZSA8bGludXgvdGltZS5oPgogCiAjaW5jbHVkZSA8bmV0L2ljbXAuaD4K ICNpbmNsdWRlIDxuZXQvdGNwLmg+CkBAIC0yOSw2ICszMCwxNiBAQAogCiAjaW5jbHVkZSA8bGlu dXgvdGNwX2RpYWcuaD4KIAorc3RydWN0IHRjcGRpYWdfZW50cnkKK3sKKwl1MzIgKnNhZGRyOwor CXUzMiAqZGFkZHI7CisJdTE2IHNwb3J0OworCXUxNiBkcG9ydDsKKwl1MTYgZmFtaWx5OworCXUx NiB1c2VybG9ja3M7Cit9OworCiBzdGF0aWMgc3RydWN0IHNvY2sgKnRjcG5sOwogCiAKQEAgLTQx LDYzICs1Miw4IEBACiAgICBydGEtPnJ0YV9sZW4gPSBydGFsZW47ICAgICAgICAgICAgICAgICAg IFwKICAgIFJUQV9EQVRBKHJ0YSk7IH0pCiAKLS8qIFJldHVybiBpbmZvcm1hdGlvbiBhYm91dCBz dGF0ZSBvZiB0Y3AgZW5kcG9pbnQgaW4gQVBJIGZvcm1hdC4gKi8KLXZvaWQgdGNwX2dldF9pbmZv KHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHRjcF9pbmZvICppbmZvKQotewotCXN0cnVjdCB0Y3Bf b3B0ICp0cCA9IHRjcF9zayhzayk7Ci0JdTMyIG5vdyA9IHRjcF90aW1lX3N0YW1wOwotCi0JbWVt c2V0KGluZm8sIDAsIHNpemVvZigqaW5mbykpOwotCi0JaW5mby0+dGNwaV9zdGF0ZSA9IHNrLT5z a19zdGF0ZTsKLQlpbmZvLT50Y3BpX2NhX3N0YXRlID0gdHAtPmNhX3N0YXRlOwotCWluZm8tPnRj cGlfcmV0cmFuc21pdHMgPSB0cC0+cmV0cmFuc21pdHM7Ci0JaW5mby0+dGNwaV9wcm9iZXMgPSB0 cC0+cHJvYmVzX291dDsKLQlpbmZvLT50Y3BpX2JhY2tvZmYgPSB0cC0+YmFja29mZjsKLQotCWlm ICh0cC0+dHN0YW1wX29rKQotCQlpbmZvLT50Y3BpX29wdGlvbnMgfD0gVENQSV9PUFRfVElNRVNU QU1QUzsKLQlpZiAodHAtPnNhY2tfb2spCi0JCWluZm8tPnRjcGlfb3B0aW9ucyB8PSBUQ1BJX09Q VF9TQUNLOwotCWlmICh0cC0+d3NjYWxlX29rKSB7Ci0JCWluZm8tPnRjcGlfb3B0aW9ucyB8PSBU Q1BJX09QVF9XU0NBTEU7Ci0JCWluZm8tPnRjcGlfc25kX3dzY2FsZSA9IHRwLT5zbmRfd3NjYWxl OwotCQlpbmZvLT50Y3BpX3Jjdl93c2NhbGUgPSB0cC0+cmN2X3dzY2FsZTsKLQl9IAotCi0JaWYg KHRwLT5lY25fZmxhZ3MmVENQX0VDTl9PSykKLQkJaW5mby0+dGNwaV9vcHRpb25zIHw9IFRDUElf T1BUX0VDTjsKLQotCWluZm8tPnRjcGlfcnRvID0gamlmZmllc190b191c2Vjcyh0cC0+cnRvKTsK LQlpbmZvLT50Y3BpX2F0byA9IGppZmZpZXNfdG9fdXNlY3ModHAtPmFjay5hdG8pOwotCWluZm8t PnRjcGlfc25kX21zcyA9IHRwLT5tc3NfY2FjaGVfc3RkOwotCWluZm8tPnRjcGlfcmN2X21zcyA9 IHRwLT5hY2sucmN2X21zczsKLQotCWluZm8tPnRjcGlfdW5hY2tlZCA9IHRjcF9nZXRfcGNvdW50 KCZ0cC0+cGFja2V0c19vdXQpOwotCWluZm8tPnRjcGlfc2Fja2VkID0gdGNwX2dldF9wY291bnQo JnRwLT5zYWNrZWRfb3V0KTsKLQlpbmZvLT50Y3BpX2xvc3QgPSB0Y3BfZ2V0X3Bjb3VudCgmdHAt Pmxvc3Rfb3V0KTsKLQlpbmZvLT50Y3BpX3JldHJhbnMgPSB0Y3BfZ2V0X3Bjb3VudCgmdHAtPnJl dHJhbnNfb3V0KTsKLQlpbmZvLT50Y3BpX2ZhY2tldHMgPSB0Y3BfZ2V0X3Bjb3VudCgmdHAtPmZh Y2tldHNfb3V0KTsKLQotCWluZm8tPnRjcGlfbGFzdF9kYXRhX3NlbnQgPSBqaWZmaWVzX3RvX21z ZWNzKG5vdyAtIHRwLT5sc25kdGltZSk7Ci0JaW5mby0+dGNwaV9sYXN0X2RhdGFfcmVjdiA9IGpp ZmZpZXNfdG9fbXNlY3Mobm93IC0gdHAtPmFjay5scmN2dGltZSk7Ci0JaW5mby0+dGNwaV9sYXN0 X2Fja19yZWN2ID0gamlmZmllc190b19tc2Vjcyhub3cgLSB0cC0+cmN2X3RzdGFtcCk7Ci0KLQlp bmZvLT50Y3BpX3BtdHUgPSB0cC0+cG10dV9jb29raWU7Ci0JaW5mby0+dGNwaV9yY3Zfc3N0aHJl c2ggPSB0cC0+cmN2X3NzdGhyZXNoOwotCWluZm8tPnRjcGlfcnR0ID0gamlmZmllc190b191c2Vj cyh0cC0+c3J0dCk+PjM7Ci0JaW5mby0+dGNwaV9ydHR2YXIgPSBqaWZmaWVzX3RvX3VzZWNzKHRw LT5tZGV2KT4+MjsKLQlpbmZvLT50Y3BpX3NuZF9zc3RocmVzaCA9IHRwLT5zbmRfc3N0aHJlc2g7 Ci0JaW5mby0+dGNwaV9zbmRfY3duZCA9IHRwLT5zbmRfY3duZDsKLQlpbmZvLT50Y3BpX2Fkdm1z cyA9IHRwLT5hZHZtc3M7Ci0JaW5mby0+dGNwaV9yZW9yZGVyaW5nID0gdHAtPnJlb3JkZXJpbmc7 Ci0KLQlpbmZvLT50Y3BpX3Jjdl9ydHQgPSBqaWZmaWVzX3RvX3VzZWNzKHRwLT5yY3ZfcnR0X2Vz dC5ydHQpPj4zOwotCWluZm8tPnRjcGlfcmN2X3NwYWNlID0gdHAtPnJjdnFfc3BhY2Uuc3BhY2U7 Ci19Ci0KIHN0YXRpYyBpbnQgdGNwZGlhZ19maWxsKHN0cnVjdCBza19idWZmICpza2IsIHN0cnVj dCBzb2NrICpzaywKLQkJCWludCBleHQsIHUzMiBwaWQsIHUzMiBzZXEpCisJCQlpbnQgZXh0LCB1 MzIgcGlkLCB1MzIgc2VxLCB1MTYgbmxtc2dfZmxhZ3MpCiB7CiAJc3RydWN0IGluZXRfb3B0ICpp bmV0ID0gaW5ldF9zayhzayk7CiAJc3RydWN0IHRjcF9vcHQgKnRwID0gdGNwX3NrKHNrKTsKQEAg LTEwOSw2ICs2NSw3IEBACiAJdW5zaWduZWQgY2hhcgkgKmIgPSBza2ItPnRhaWw7CiAKIAlubGgg PSBOTE1TR19QVVQoc2tiLCBwaWQsIHNlcSwgVENQRElBR19HRVRTT0NLLCBzaXplb2YoKnIpKTsK KwlubGgtPm5sbXNnX2ZsYWdzID0gbmxtc2dfZmxhZ3M7CiAJciA9IE5MTVNHX0RBVEEobmxoKTsK IAlpZiAoc2stPnNrX3N0YXRlICE9IFRDUF9USU1FX1dBSVQpIHsKIAkJaWYgKGV4dCAmICgxPDwo VENQRElBR19NRU1JTkZPLTEpKSkKQEAgLTE0Niw3ICsxMDMsNyBAQAogCQlyLT50Y3BkaWFnX3dx dWV1ZSA9IDA7CiAJCXItPnRjcGRpYWdfdWlkID0gMDsKIAkJci0+dGNwZGlhZ19pbm9kZSA9IDA7 Ci0jaWZkZWYgQ09ORklHX0lQVjYKKyNpZmRlZiBDT05GSUdfSVBfVENQRElBR19JUFY2CiAJCWlm IChyLT50Y3BkaWFnX2ZhbWlseSA9PSBBRl9JTkVUNikgewogCQkJaXB2Nl9hZGRyX2NvcHkoKHN0 cnVjdCBpbjZfYWRkciAqKXItPmlkLnRjcGRpYWdfc3JjLAogCQkJCSAgICAgICAmdHctPnR3X3Y2 X3Jjdl9zYWRkcik7CkBAIC0xNjMsNyArMTIwLDcgQEAKIAlyLT5pZC50Y3BkaWFnX3NyY1swXSA9 IGluZXQtPnJjdl9zYWRkcjsKIAlyLT5pZC50Y3BkaWFnX2RzdFswXSA9IGluZXQtPmRhZGRyOwog Ci0jaWZkZWYgQ09ORklHX0lQVjYKKyNpZmRlZiBDT05GSUdfSVBfVENQRElBR19JUFY2CiAJaWYg KHItPnRjcGRpYWdfZmFtaWx5ID09IEFGX0lORVQ2KSB7CiAJCXN0cnVjdCBpcHY2X3BpbmZvICpu cCA9IGluZXQ2X3NrKHNrKTsKIApAQCAtMjMxLDExICsxODgsMTkgQEAKIAlyZXR1cm4gLTE7CiB9 CiAKLWV4dGVybiBzdHJ1Y3Qgc29jayAqdGNwX3Y0X2xvb2t1cCh1MzIgc2FkZHIsIHUxNiBzcG9y dCwgdTMyIGRhZGRyLCB1MTYgZHBvcnQsIGludCBkaWYpOwotI2lmZGVmIENPTkZJR19JUFY2Citl eHRlcm4gc3RydWN0IHNvY2sgKnRjcF92NF9sb29rdXAodTMyIHNhZGRyLCB1MTYgc3BvcnQsIHUz MiBkYWRkciwgdTE2IGRwb3J0LAorCQkJCSAgaW50IGRpZik7CisjaWZkZWYgQ09ORklHX0lQX1RD UERJQUdfSVBWNgogZXh0ZXJuIHN0cnVjdCBzb2NrICp0Y3BfdjZfbG9va3VwKHN0cnVjdCBpbjZf YWRkciAqc2FkZHIsIHUxNiBzcG9ydCwKIAkJCQkgIHN0cnVjdCBpbjZfYWRkciAqZGFkZHIsIHUx NiBkcG9ydCwKIAkJCQkgIGludCBkaWYpOworI2Vsc2UKK3N0YXRpYyBpbmxpbmUgc3RydWN0IHNv Y2sgKnRjcF92Nl9sb29rdXAoc3RydWN0IGluNl9hZGRyICpzYWRkciwgdTE2IHNwb3J0LAorCQkJ CQkgc3RydWN0IGluNl9hZGRyICpkYWRkciwgdTE2IGRwb3J0LAorCQkJCQkgaW50IGRpZikKK3sK KwlyZXR1cm4gTlVMTDsKK30KICNlbmRpZgogCiBzdGF0aWMgaW50IHRjcGRpYWdfZ2V0X2V4YWN0 KHN0cnVjdCBza19idWZmICppbl9za2IsIGNvbnN0IHN0cnVjdCBubG1zZ2hkciAqbmxoKQpAQCAt MjUwLDcgKzIxNSw3IEBACiAJCQkJICAgcmVxLT5pZC50Y3BkaWFnX3NyY1swXSwgcmVxLT5pZC50 Y3BkaWFnX3Nwb3J0LAogCQkJCSAgIHJlcS0+aWQudGNwZGlhZ19pZik7CiAJfQotI2lmZGVmIENP TkZJR19JUFY2CisjaWZkZWYgQ09ORklHX0lQX1RDUERJQUdfSVBWNgogCWVsc2UgaWYgKHJlcS0+ dGNwZGlhZ19mYW1pbHkgPT0gQUZfSU5FVDYpIHsKIAkJc2sgPSB0Y3BfdjZfbG9va3VwKChzdHJ1 Y3QgaW42X2FkZHIqKXJlcS0+aWQudGNwZGlhZ19kc3QsIHJlcS0+aWQudGNwZGlhZ19kcG9ydCwK IAkJCQkgICAoc3RydWN0IGluNl9hZGRyKilyZXEtPmlkLnRjcGRpYWdfc3JjLCByZXEtPmlkLnRj cGRpYWdfc3BvcnQsCkBAIC0yODAsNyArMjQ1LDcgQEAKIAogCWlmICh0Y3BkaWFnX2ZpbGwocmVw LCBzaywgcmVxLT50Y3BkaWFnX2V4dCwKIAkJCSBORVRMSU5LX0NCKGluX3NrYikucGlkLAotCQkJ IG5saC0+bmxtc2dfc2VxKSA8PSAwKQorCQkJIG5saC0+bmxtc2dfc2VxLCAwKSA8PSAwKQogCQlC VUcoKTsKIAogCWVyciA9IG5ldGxpbmtfdW5pY2FzdCh0Y3BubCwgcmVwLCBORVRMSU5LX0NCKGlu X3NrYikucGlkLCBNU0dfRE9OVFdBSVQpOwpAQCAtMzI0LDExICsyODksMTEgQEAKIH0KIAogCi1z dGF0aWMgaW50IHRjcGRpYWdfYmNfcnVuKGNvbnN0IHZvaWQgKmJjLCBpbnQgbGVuLCBzdHJ1Y3Qg c29jayAqc2spCitzdGF0aWMgaW50IHRjcGRpYWdfYmNfcnVuKGNvbnN0IHZvaWQgKmJjLCBpbnQg bGVuLAorCQkJICBjb25zdCBzdHJ1Y3QgdGNwZGlhZ19lbnRyeSAqZW50cnkpCiB7CiAJd2hpbGUg KGxlbiA+IDApIHsKIAkJaW50IHllcyA9IDE7Ci0JCXN0cnVjdCBpbmV0X29wdCAqaW5ldCA9IGlu ZXRfc2soc2spOwogCQljb25zdCBzdHJ1Y3QgdGNwZGlhZ19iY19vcCAqb3AgPSBiYzsKIAogCQlz d2l0Y2ggKG9wLT5jb2RlKSB7CkBAIC0zMzgsMTkgKzMwMywxOSBAQAogCQkJeWVzID0gMDsKIAkJ CWJyZWFrOwogCQljYXNlIFRDUERJQUdfQkNfU19HRToKLQkJCXllcyA9IGluZXQtPm51bSA+PSBv cFsxXS5ubzsKKwkJCXllcyA9IGVudHJ5LT5zcG9ydCA+PSBvcFsxXS5ubzsKIAkJCWJyZWFrOwog CQljYXNlIFRDUERJQUdfQkNfU19MRToKLQkJCXllcyA9IGluZXQtPm51bSA8PSBvcFsxXS5ubzsK KwkJCXllcyA9IGVudHJ5LT5kcG9ydCA8PSBvcFsxXS5ubzsKIAkJCWJyZWFrOwogCQljYXNlIFRD UERJQUdfQkNfRF9HRToKLQkJCXllcyA9IG50b2hzKGluZXQtPmRwb3J0KSA+PSBvcFsxXS5ubzsK KwkJCXllcyA9IGVudHJ5LT5kcG9ydCA+PSBvcFsxXS5ubzsKIAkJCWJyZWFrOwogCQljYXNlIFRD UERJQUdfQkNfRF9MRToKLQkJCXllcyA9IG50b2hzKGluZXQtPmRwb3J0KSA8PSBvcFsxXS5ubzsK KwkJCXllcyA9IGVudHJ5LT5kcG9ydCA8PSBvcFsxXS5ubzsKIAkJCWJyZWFrOwogCQljYXNlIFRD UERJQUdfQkNfQVVUTzoKLQkJCXllcyA9ICEoc2stPnNrX3VzZXJsb2NrcyAmIFNPQ0tfQklORFBP UlRfTE9DSyk7CisJCQl5ZXMgPSAhKGVudHJ5LT51c2VybG9ja3MgJiBTT0NLX0JJTkRQT1JUX0xP Q0spOwogCQkJYnJlYWs7CiAJCWNhc2UgVENQRElBR19CQ19TX0NPTkQ6CiAJCWNhc2UgVENQRElB R19CQ19EX0NPTkQ6CkBAIC0zNjAsNyArMzI1LDcgQEAKIAogCQkJaWYgKGNvbmQtPnBvcnQgIT0g LTEgJiYKIAkJCSAgICBjb25kLT5wb3J0ICE9IChvcC0+Y29kZSA9PSBUQ1BESUFHX0JDX1NfQ09O RCA/Ci0JCQkJCSAgICAgaW5ldC0+bnVtIDogbnRvaHMoaW5ldC0+ZHBvcnQpKSkgeworCQkJCQkg ICAgIGVudHJ5LT5zcG9ydCA6IGVudHJ5LT5kcG9ydCkpIHsKIAkJCQl5ZXMgPSAwOwogCQkJCWJy ZWFrOwogCQkJfQpAQCAtMzY4LDI2ICszMzMsMTQgQEAKIAkJCWlmIChjb25kLT5wcmVmaXhfbGVu ID09IDApCiAJCQkJYnJlYWs7CiAKLSNpZmRlZiBDT05GSUdfSVBWNgotCQkJaWYgKHNrLT5za19m YW1pbHkgPT0gQUZfSU5FVDYpIHsKLQkJCQlzdHJ1Y3QgaXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9z ayhzayk7Ci0KLQkJCQlpZiAob3AtPmNvZGUgPT0gVENQRElBR19CQ19TX0NPTkQpCi0JCQkJCWFk ZHIgPSAodTMyKikmbnAtPnJjdl9zYWRkcjsKLQkJCQllbHNlCi0JCQkJCWFkZHIgPSAodTMyKikm bnAtPmRhZGRyOwotCQkJfSBlbHNlCi0jZW5kaWYKLQkJCXsKLQkJCQlpZiAob3AtPmNvZGUgPT0g VENQRElBR19CQ19TX0NPTkQpCi0JCQkJCWFkZHIgPSAmaW5ldC0+cmN2X3NhZGRyOwotCQkJCWVs c2UKLQkJCQkJYWRkciA9ICZpbmV0LT5kYWRkcjsKLQkJCX0KKwkJCWlmIChvcC0+Y29kZSA9PSBU Q1BESUFHX0JDX1NfQ09ORCkKKwkJCQlhZGRyID0gZW50cnktPnNhZGRyOworCQkJZWxzZQorCQkJ CWFkZHIgPSBlbnRyeS0+ZGFkZHI7CiAKIAkJCWlmIChiaXRzdHJpbmdfbWF0Y2goYWRkciwgY29u ZC0+YWRkciwgY29uZC0+cHJlZml4X2xlbikpCiAJCQkJYnJlYWs7Ci0JCQlpZiAoc2stPnNrX2Zh bWlseSA9PSBBRl9JTkVUNiAmJgorCQkJaWYgKGVudHJ5LT5mYW1pbHkgPT0gQUZfSU5FVDYgJiYK IAkJCSAgICBjb25kLT5mYW1pbHkgPT0gQUZfSU5FVCkgewogCQkJCWlmIChhZGRyWzBdID09IDAg JiYgYWRkclsxXSA9PSAwICYmCiAJCQkJICAgIGFkZHJbMl0gPT0gaHRvbmwoMHhmZmZmKSAmJgpA QCAtNDY2LDE2ICs0MTksMTgyIEBACiAJcmV0dXJuIGxlbiA9PSAwID8gMCA6IC1FSU5WQUw7CiB9 CiAKK3N0YXRpYyBpbnQgdGNwZGlhZ19kdW1wX3NvY2soc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3Ry dWN0IHNvY2sgKnNrLAorCQkJICAgICBzdHJ1Y3QgbmV0bGlua19jYWxsYmFjayAqY2IpCit7CisJ c3RydWN0IHRjcGRpYWdyZXEgKnIgPSBOTE1TR19EQVRBKGNiLT5ubGgpOworCisJaWYgKGNiLT5u bGgtPm5sbXNnX2xlbiA+IDQgKyBOTE1TR19TUEFDRShzaXplb2YoKnIpKSkgeworCQlzdHJ1Y3Qg dGNwZGlhZ19lbnRyeSBlbnRyeTsKKwkJc3RydWN0IHJ0YXR0ciAqYmMgPSAoc3RydWN0IHJ0YXR0 ciAqKShyICsgMSk7CisJCXN0cnVjdCBpbmV0X29wdCAqaW5ldCA9IGluZXRfc2soc2spOworCisJ CWVudHJ5LmZhbWlseSA9IHNrLT5za19mYW1pbHk7CisjaWZkZWYgQ09ORklHX0lQX1RDUERJQUdf SVBWNgorCQlpZiAoZW50cnkuZmFtaWx5ID09IEFGX0lORVQ2KSB7CisJCQlzdHJ1Y3QgaXB2Nl9w aW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7CisKKwkJCWVudHJ5LnNhZGRyID0gbnAtPnJjdl9zYWRk ci5zNl9hZGRyMzI7CisJCQllbnRyeS5kYWRkciA9IG5wLT5kYWRkci5zNl9hZGRyMzI7CisJCX0g ZWxzZQorI2VuZGlmCisJCXsKKwkJCWVudHJ5LnNhZGRyID0gJmluZXQtPnJjdl9zYWRkcjsKKwkJ CWVudHJ5LmRhZGRyID0gJmluZXQtPmRhZGRyOworCQl9CisJCWVudHJ5LnNwb3J0ID0gaW5ldC0+ bnVtOworCQllbnRyeS5kcG9ydCA9IG50b2hzKGluZXQtPmRwb3J0KTsKKwkJZW50cnkudXNlcmxv Y2tzID0gc2stPnNrX3VzZXJsb2NrczsKKworCQlpZiAoIXRjcGRpYWdfYmNfcnVuKFJUQV9EQVRB KGJjKSwgUlRBX1BBWUxPQUQoYmMpLCAmZW50cnkpKQorCQkJcmV0dXJuIDA7CisJfQorCisJcmV0 dXJuIHRjcGRpYWdfZmlsbChza2IsIHNrLCByLT50Y3BkaWFnX2V4dCwgTkVUTElOS19DQihjYi0+ c2tiKS5waWQsCisJCQkgICAgY2ItPm5saC0+bmxtc2dfc2VxLCBOTE1fRl9NVUxUSSk7Cit9CisK K3N0YXRpYyBpbnQgdGNwZGlhZ19maWxsX3JlcShzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3Qg c29jayAqc2ssCisJCQkgICAgc3RydWN0IG9wZW5fcmVxdWVzdCAqcmVxLAorCQkJICAgIHUzMiBw aWQsIHUzMiBzZXEpCit7CisJc3RydWN0IGluZXRfb3B0ICppbmV0ID0gaW5ldF9zayhzayk7CisJ dW5zaWduZWQgY2hhciAqYiA9IHNrYi0+dGFpbDsKKwlzdHJ1Y3QgdGNwZGlhZ21zZyAqcjsKKwlz dHJ1Y3Qgbmxtc2doZHIgKm5saDsKKwlsb25nIHRtbzsKKworCW5saCA9IE5MTVNHX1BVVChza2Is IHBpZCwgc2VxLCBUQ1BESUFHX0dFVFNPQ0ssIHNpemVvZigqcikpOworCW5saC0+bmxtc2dfZmxh Z3MgPSBOTE1fRl9NVUxUSTsKKwlyID0gTkxNU0dfREFUQShubGgpOworCisJci0+dGNwZGlhZ19m YW1pbHkgPSBzay0+c2tfZmFtaWx5OworCXItPnRjcGRpYWdfc3RhdGUgPSBUQ1BfU1lOX1JFQ1Y7 CisJci0+dGNwZGlhZ190aW1lciA9IDE7CisJci0+dGNwZGlhZ19yZXRyYW5zID0gcmVxLT5yZXRy YW5zOworCisJci0+aWQudGNwZGlhZ19pZiA9IHNrLT5za19ib3VuZF9kZXZfaWY7CisJci0+aWQu dGNwZGlhZ19jb29raWVbMF0gPSAodTMyKSh1bnNpZ25lZCBsb25nKXJlcTsKKwlyLT5pZC50Y3Bk aWFnX2Nvb2tpZVsxXSA9ICh1MzIpKCgodW5zaWduZWQgbG9uZylyZXEgPj4gMzEpID4+IDEpOwor CisJdG1vID0gcmVxLT5leHBpcmVzIC0gamlmZmllczsKKwlpZiAodG1vIDwgMCkKKwkJdG1vID0g MDsKKworCXItPmlkLnRjcGRpYWdfc3BvcnQgPSBpbmV0LT5zcG9ydDsKKwlyLT5pZC50Y3BkaWFn X2Rwb3J0ID0gcmVxLT5ybXRfcG9ydDsKKwlyLT5pZC50Y3BkaWFnX3NyY1swXSA9IHJlcS0+YWYu djRfcmVxLmxvY19hZGRyOworCXItPmlkLnRjcGRpYWdfZHN0WzBdID0gcmVxLT5hZi52NF9yZXEu cm10X2FkZHI7CisJci0+dGNwZGlhZ19leHBpcmVzID0gamlmZmllc190b19tc2Vjcyh0bW8pLAor CXItPnRjcGRpYWdfcnF1ZXVlID0gMDsKKwlyLT50Y3BkaWFnX3dxdWV1ZSA9IDA7CisJci0+dGNw ZGlhZ191aWQgPSBzb2NrX2lfdWlkKHNrKTsKKwlyLT50Y3BkaWFnX2lub2RlID0gMDsKKyNpZmRl ZiBDT05GSUdfSVBfVENQRElBR19JUFY2CisJaWYgKHItPnRjcGRpYWdfZmFtaWx5ID09IEFGX0lO RVQ2KSB7CisJCWlwdjZfYWRkcl9jb3B5KChzdHJ1Y3QgaW42X2FkZHIgKilyLT5pZC50Y3BkaWFn X3NyYywKKwkJCSAgICAgICAmcmVxLT5hZi52Nl9yZXEubG9jX2FkZHIpOworCQlpcHY2X2FkZHJf Y29weSgoc3RydWN0IGluNl9hZGRyICopci0+aWQudGNwZGlhZ19kc3QsCisJCQkgICAgICAgJnJl cS0+YWYudjZfcmVxLnJtdF9hZGRyKTsKKwl9CisjZW5kaWYKKwlubGgtPm5sbXNnX2xlbiA9IHNr Yi0+dGFpbCAtIGI7CisKKwlyZXR1cm4gc2tiLT5sZW47CisKK25sbXNnX2ZhaWx1cmU6CisJc2ti X3RyaW0oc2tiLCBiIC0gc2tiLT5kYXRhKTsKKwlyZXR1cm4gLTE7Cit9CisKK3N0YXRpYyBpbnQg dGNwZGlhZ19kdW1wX3JlcXMoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IHNvY2sgKnNrLAor CQkJICAgICBzdHJ1Y3QgbmV0bGlua19jYWxsYmFjayAqY2IpCit7CisJc3RydWN0IHRjcGRpYWdf ZW50cnkgZW50cnk7CisJc3RydWN0IHRjcGRpYWdyZXEgKnIgPSBOTE1TR19EQVRBKGNiLT5ubGgp OworCXN0cnVjdCB0Y3Bfb3B0ICp0cCA9IHRjcF9zayhzayk7CisJc3RydWN0IHRjcF9saXN0ZW5f b3B0ICpsb3B0OworCXN0cnVjdCBydGF0dHIgKmJjID0gTlVMTDsKKwlzdHJ1Y3QgaW5ldF9vcHQg KmluZXQgPSBpbmV0X3NrKHNrKTsKKwlpbnQgaiwgc19qOworCWludCByZXFudW0sIHNfcmVxbnVt OworCWludCBlcnIgPSAwOworCisJc19qID0gY2ItPmFyZ3NbM107CisJc19yZXFudW0gPSBjYi0+ YXJnc1s0XTsKKworCWlmIChzX2ogPiAwKQorCQlzX2otLTsKKworCWVudHJ5LmZhbWlseSA9IHNr LT5za19mYW1pbHk7CisKKwlyZWFkX2xvY2tfYmgoJnRwLT5zeW5fd2FpdF9sb2NrKTsKKworCWxv cHQgPSB0cC0+bGlzdGVuX29wdDsKKwlpZiAoIWxvcHQgfHwgIWxvcHQtPnFsZW4pCisJCWdvdG8g b3V0OworCisJaWYgKGNiLT5ubGgtPm5sbXNnX2xlbiA+IDQgKyBOTE1TR19TUEFDRShzaXplb2Yo KnIpKSkgeworCQliYyA9IChzdHJ1Y3QgcnRhdHRyICopKHIgKyAxKTsKKwkJZW50cnkuc3BvcnQg PSBpbmV0LT5udW07CisJCWVudHJ5LnVzZXJsb2NrcyA9IHNrLT5za191c2VybG9ja3M7CisJfQor CisJZm9yIChqID0gc19qOyBqIDwgVENQX1NZTlFfSFNJWkU7IGorKykgeworCQlzdHJ1Y3Qgb3Bl bl9yZXF1ZXN0ICpyZXEsICpoZWFkID0gbG9wdC0+c3luX3RhYmxlW2pdOworCisJCXJlcW51bSA9 IDA7CisJCWZvciAocmVxID0gaGVhZDsgcmVxOyByZXFudW0rKywgcmVxID0gcmVxLT5kbF9uZXh0 KSB7CisJCQlpZiAocmVxbnVtIDwgc19yZXFudW0pCisJCQkJY29udGludWU7CisJCQlpZiAoci0+ aWQudGNwZGlhZ19kcG9ydCAhPSByZXEtPnJtdF9wb3J0ICYmCisJCQkgICAgci0+aWQudGNwZGlh Z19kcG9ydCkKKwkJCQljb250aW51ZTsKKworCQkJaWYgKGJjKSB7CisJCQkJZW50cnkuc2FkZHIg PQorI2lmZGVmIENPTkZJR19JUF9UQ1BESUFHX0lQVjYKKwkJCQkJKGVudHJ5LmZhbWlseSA9PSBB Rl9JTkVUNikgPworCQkJCQlyZXEtPmFmLnY2X3JlcS5sb2NfYWRkci5zNl9hZGRyMzIgOgorI2Vu ZGlmCisJCQkJCSZyZXEtPmFmLnY0X3JlcS5sb2NfYWRkcjsKKwkJCQllbnRyeS5kYWRkciA9IAor I2lmZGVmIENPTkZJR19JUF9UQ1BESUFHX0lQVjYKKwkJCQkJKGVudHJ5LmZhbWlseSA9PSBBRl9J TkVUNikgPworCQkJCQlyZXEtPmFmLnY2X3JlcS5ybXRfYWRkci5zNl9hZGRyMzIgOgorI2VuZGlm CisJCQkJCSZyZXEtPmFmLnY0X3JlcS5ybXRfYWRkcjsKKwkJCQllbnRyeS5kcG9ydCA9IG50b2hz KHJlcS0+cm10X3BvcnQpOworCisJCQkJaWYgKCF0Y3BkaWFnX2JjX3J1bihSVEFfREFUQShiYyks CisJCQkJCQkgICAgUlRBX1BBWUxPQUQoYmMpLCAmZW50cnkpKQorCQkJCQljb250aW51ZTsKKwkJ CX0KKworCQkJZXJyID0gdGNwZGlhZ19maWxsX3JlcShza2IsIHNrLCByZXEsCisJCQkJCSAgICAg ICBORVRMSU5LX0NCKGNiLT5za2IpLnBpZCwKKwkJCQkJICAgICAgIGNiLT5ubGgtPm5sbXNnX3Nl cSk7CisJCQlpZiAoZXJyIDwgMCkgeworCQkJCWNiLT5hcmdzWzNdID0gaiArIDE7CisJCQkJY2It PmFyZ3NbNF0gPSByZXFudW07CisJCQkJZ290byBvdXQ7CisJCQl9CisJCX0KKworCQlzX3JlcW51 bSA9IDA7CisJfQorCitvdXQ6CisJcmVhZF91bmxvY2tfYmgoJnRwLT5zeW5fd2FpdF9sb2NrKTsK KworCXJldHVybiBlcnI7Cit9CiAKIHN0YXRpYyBpbnQgdGNwZGlhZ19kdW1wKHN0cnVjdCBza19i dWZmICpza2IsIHN0cnVjdCBuZXRsaW5rX2NhbGxiYWNrICpjYikKIHsKIAlpbnQgaSwgbnVtOwog CWludCBzX2ksIHNfbnVtOwogCXN0cnVjdCB0Y3BkaWFncmVxICpyID0gTkxNU0dfREFUQShjYi0+ bmxoKTsKLQlzdHJ1Y3QgcnRhdHRyICpiYyA9IE5VTEw7Ci0KLQlpZiAoY2ItPm5saC0+bmxtc2df bGVuID4gNCtOTE1TR19TUEFDRShzaXplb2Yoc3RydWN0IHRjcGRpYWdyZXEpKSkKLQkJYmMgPSAo c3RydWN0IHJ0YXR0ciopKHIrMSk7CiAKIAlzX2kgPSBjYi0+YXJnc1sxXTsKIAlzX251bSA9IG51 bSA9IGNiLT5hcmdzWzJdOwpAQCAtNDg4LDMxICs2MDcsNDcgQEAKIAkJCXN0cnVjdCBzb2NrICpz azsKIAkJCXN0cnVjdCBobGlzdF9ub2RlICpub2RlOwogCi0JCQlpZiAoaSA+IHNfaSkKLQkJCQlz X251bSA9IDA7Ci0KIAkJCW51bSA9IDA7CiAJCQlza19mb3JfZWFjaChzaywgbm9kZSwgJnRjcF9s aXN0ZW5pbmdfaGFzaFtpXSkgewogCQkJCXN0cnVjdCBpbmV0X29wdCAqaW5ldCA9IGluZXRfc2so c2spOwotCQkJCWlmIChudW0gPCBzX251bSkKLQkJCQkJZ290byBuZXh0X2xpc3RlbjsKLQkJCQlp ZiAoIShyLT50Y3BkaWFnX3N0YXRlcyZUQ1BGX0xJU1RFTikgfHwKLQkJCQkgICAgci0+aWQudGNw ZGlhZ19kcG9ydCkKLQkJCQkJZ290byBuZXh0X2xpc3RlbjsKKworCQkJCWlmIChudW0gPCBzX251 bSkgeworCQkJCQludW0rKzsKKwkJCQkJY29udGludWU7CisJCQkJfQorCiAJCQkJaWYgKHItPmlk LnRjcGRpYWdfc3BvcnQgIT0gaW5ldC0+c3BvcnQgJiYKIAkJCQkgICAgci0+aWQudGNwZGlhZ19z cG9ydCkKIAkJCQkJZ290byBuZXh0X2xpc3RlbjsKLQkJCQlpZiAoYmMgJiYgIXRjcGRpYWdfYmNf cnVuKFJUQV9EQVRBKGJjKSwgUlRBX1BBWUxPQUQoYmMpLCBzaykpCisKKwkJCQlpZiAoIShyLT50 Y3BkaWFnX3N0YXRlcyZUQ1BGX0xJU1RFTikgfHwKKwkJCQkgICAgci0+aWQudGNwZGlhZ19kcG9y dCB8fAorCQkJCSAgICBjYi0+YXJnc1szXSA+IDApCisJCQkJCWdvdG8gc3luX3JlY3Y7CisKKwkJ CQlpZiAodGNwZGlhZ19kdW1wX3NvY2soc2tiLCBzaywgY2IpIDwgMCkgeworCQkJCQl0Y3BfbGlz dGVuX3VubG9jaygpOworCQkJCQlnb3RvIGRvbmU7CisJCQkJfQorCitzeW5fcmVjdjoKKwkJCQlp ZiAoIShyLT50Y3BkaWFnX3N0YXRlcyZUQ1BGX1NZTl9SRUNWKSkKIAkJCQkJZ290byBuZXh0X2xp c3RlbjsKLQkJCQlpZiAodGNwZGlhZ19maWxsKHNrYiwgc2ssIHItPnRjcGRpYWdfZXh0LAotCQkJ CQkJIE5FVExJTktfQ0IoY2ItPnNrYikucGlkLAotCQkJCQkJIGNiLT5ubGgtPm5sbXNnX3NlcSkg PD0gMCkgeworCisJCQkJaWYgKHRjcGRpYWdfZHVtcF9yZXFzKHNrYiwgc2ssIGNiKSA8IDApIHsK IAkJCQkJdGNwX2xpc3Rlbl91bmxvY2soKTsKIAkJCQkJZ290byBkb25lOwogCQkJCX0KKwogbmV4 dF9saXN0ZW46CisJCQkJY2ItPmFyZ3NbM10gPSAwOworCQkJCWNiLT5hcmdzWzRdID0gMDsKIAkJ CQkrK251bTsKIAkJCX0KKworCQkJc19udW0gPSAwOworCQkJY2ItPmFyZ3NbM10gPSAwOworCQkJ Y2ItPmFyZ3NbNF0gPSAwOwogCQl9CiAJCXRjcF9saXN0ZW5fdW5sb2NrKCk7CiBza2lwX2xpc3Rl bl9odDoKQEAgLTU0NiwxMSArNjgxLDcgQEAKIAkJCQlnb3RvIG5leHRfbm9ybWFsOwogCQkJaWYg KHItPmlkLnRjcGRpYWdfZHBvcnQgIT0gaW5ldC0+ZHBvcnQgJiYgci0+aWQudGNwZGlhZ19kcG9y dCkKIAkJCQlnb3RvIG5leHRfbm9ybWFsOwotCQkJaWYgKGJjICYmICF0Y3BkaWFnX2JjX3J1bihS VEFfREFUQShiYyksIFJUQV9QQVlMT0FEKGJjKSwgc2spKQotCQkJCWdvdG8gbmV4dF9ub3JtYWw7 Ci0JCQlpZiAodGNwZGlhZ19maWxsKHNrYiwgc2ssIHItPnRjcGRpYWdfZXh0LAotCQkJCQkgTkVU TElOS19DQihjYi0+c2tiKS5waWQsCi0JCQkJCSBjYi0+bmxoLT5ubG1zZ19zZXEpIDw9IDApIHsK KwkJCWlmICh0Y3BkaWFnX2R1bXBfc29jayhza2IsIHNrLCBjYikgPCAwKSB7CiAJCQkJcmVhZF91 bmxvY2tfYmgoJmhlYWQtPmxvY2spOwogCQkJCWdvdG8gZG9uZTsKIAkJCX0KQEAgLTU3MSwxMSAr NzAyLDcgQEAKIAkJCQlpZiAoci0+aWQudGNwZGlhZ19kcG9ydCAhPSBpbmV0LT5kcG9ydCAmJgog CQkJCSAgICByLT5pZC50Y3BkaWFnX2Rwb3J0KQogCQkJCQlnb3RvIG5leHRfZHlpbmc7Ci0JCQkJ aWYgKGJjICYmICF0Y3BkaWFnX2JjX3J1bihSVEFfREFUQShiYyksIFJUQV9QQVlMT0FEKGJjKSwg c2spKQotCQkJCQlnb3RvIG5leHRfZHlpbmc7Ci0JCQkJaWYgKHRjcGRpYWdfZmlsbChza2IsIHNr LCByLT50Y3BkaWFnX2V4dCwKLQkJCQkJCSBORVRMSU5LX0NCKGNiLT5za2IpLnBpZCwKLQkJCQkJ CSBjYi0+bmxoLT5ubG1zZ19zZXEpIDw9IDApIHsKKwkJCQlpZiAodGNwZGlhZ19kdW1wX3NvY2so c2tiLCBzaywgY2IpIDwgMCkgewogCQkJCQlyZWFkX3VubG9ja19iaCgmaGVhZC0+bG9jayk7CiAJ CQkJCWdvdG8gZG9uZTsKIAkJCQl9CkBAIC02NTcsOSArNzg0LDE5IEBACiAJfQogfQogCi12b2lk IF9faW5pdCB0Y3BkaWFnX2luaXQodm9pZCkKK3N0YXRpYyBpbnQgX19pbml0IHRjcGRpYWdfaW5p dCh2b2lkKQogewogCXRjcG5sID0gbmV0bGlua19rZXJuZWxfY3JlYXRlKE5FVExJTktfVENQRElB RywgdGNwZGlhZ19yY3YpOwogCWlmICh0Y3BubCA9PSBOVUxMKQotCQlwYW5pYygidGNwZGlhZ19p bml0OiBDYW5ub3QgY3JlYXRlIG5ldGxpbmsgc29ja2V0LiIpOworCQlyZXR1cm4gLUVOT01FTTsK KwlyZXR1cm4gMDsKIH0KKworc3RhdGljIHZvaWQgX19leGl0IHRjcGRpYWdfZXhpdCh2b2lkKQor eworCXNvY2tfcmVsZWFzZSh0Y3BubC0+c2tfc29ja2V0KTsKK30KKworbW9kdWxlX2luaXQodGNw ZGlhZ19pbml0KTsKK21vZHVsZV9leGl0KHRjcGRpYWdfZXhpdCk7CitNT0RVTEVfTElDRU5TRSgi R1BMIik7CmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcF9pbnB1dC5jIGIvbmV0L2lwdjQvdGNwX2lu cHV0LmMKLS0tIGEvbmV0L2lwdjQvdGNwX2lucHV0LmMJMjAwNC0xMi0yNCAxMzozNzowNCAtMDg6 MDAKKysrIGIvbmV0L2lwdjQvdGNwX2lucHV0LmMJMjAwNC0xMi0yNCAxMzozNzowNCAtMDg6MDAK QEAgLTIzNjksMjUgKzIzNjksMTkgQEAKIHsKIAlzdHJ1Y3QgdGNwX29wdCAqdHAgPSB0Y3Bfc2so c2spOwogCXN0cnVjdCB0Y3Bfc2tiX2NiICpzY2IgPSBUQ1BfU0tCX0NCKHNrYik7IAotCV9fdTMy IG1zcyA9IHRjcF9za2JfbXNzKHNrYik7Ci0JX191MzIgc25kX3VuYSA9IHRwLT5zbmRfdW5hOwot CV9fdTMyIG9yaWdfc2VxLCBzZXE7Ci0JX191MzIgcGFja2V0c19hY2tlZCA9IDA7CisJX191MzIg c2VxID0gdHAtPnNuZF91bmE7CisJX191MzIgcGFja2V0c19hY2tlZDsKIAlpbnQgYWNrZWQgPSAw OwogCiAJLyogSWYgd2UgZ2V0IGhlcmUsIHRoZSB3aG9sZSBUU08gcGFja2V0IGhhcyBub3QgYmVl bgogCSAqIGFja2VkLgogCSAqLwotCUJVR19PTighYWZ0ZXIoc2NiLT5lbmRfc2VxLCBzbmRfdW5h KSk7CisJQlVHX09OKCFhZnRlcihzY2ItPmVuZF9zZXEsIHNlcSkpOwogCi0Jc2VxID0gb3JpZ19z ZXEgPSBzY2ItPnNlcTsKLQl3aGlsZSAoIWFmdGVyKHNlcSArIG1zcywgc25kX3VuYSkpIHsKLQkJ cGFja2V0c19hY2tlZCsrOwotCQlzZXEgKz0gbXNzOwotCX0KLQotCWlmICh0Y3BfdHJpbV9oZWFk KHNrLCBza2IsIChzZXEgLSBvcmlnX3NlcSkpKQorCXBhY2tldHNfYWNrZWQgPSB0Y3Bfc2tiX3Bj b3VudChza2IpOworCWlmICh0Y3BfdHJpbV9oZWFkKHNrLCBza2IsIHNlcSAtIHNjYi0+c2VxKSkK IAkJcmV0dXJuIDA7CisJcGFja2V0c19hY2tlZCAtPSB0Y3Bfc2tiX3Bjb3VudChza2IpOwogCiAJ aWYgKHBhY2tldHNfYWNrZWQpIHsKIAkJX191OCBzYWNrZWQgPSBzY2ItPnNhY2tlZDsKQEAgLTMw MzQsOCArMzAyOCw4IEBACiAJCQkJCQkJdHAtPnNuZF93c2NhbGUgPSAqKF9fdTggKilwdHI7CiAJ CQkJCQkJaWYodHAtPnNuZF93c2NhbGUgPiAxNCkgewogCQkJCQkJCQlpZihuZXRfcmF0ZWxpbWl0 KCkpCi0JCQkJCQkJCQlwcmludGsoInRjcF9wYXJzZV9vcHRpb25zOiBJbGxlZ2FsIHdpbmRvdyAi Ci0JCQkJCQkJCQkgICAgICAgInNjYWxpbmcgdmFsdWUgJWQgPjE0IHJlY2VpdmVkLiIsCisJCQkJ CQkJCQlwcmludGsoS0VSTl9JTkZPICJ0Y3BfcGFyc2Vfb3B0aW9uczogSWxsZWdhbCB3aW5kb3cg IgorCQkJCQkJCQkJICAgICAgICJzY2FsaW5nIHZhbHVlICVkID4xNCByZWNlaXZlZC5cbiIsCiAJ CQkJCQkJCQkgICAgICAgdHAtPnNuZF93c2NhbGUpOwogCQkJCQkJCQl0cC0+c25kX3dzY2FsZSA9 IDE0OwogCQkJCQkJCX0KQEAgLTQ5NjMsNyArNDk1Nyw2IEBACiAKIEVYUE9SVF9TWU1CT0woc3lz Y3RsX3RjcF9lY24pOwogRVhQT1JUX1NZTUJPTChzeXNjdGxfdGNwX3Jlb3JkZXJpbmcpOwotRVhQ T1JUX1NZTUJPTCh0Y3BfY3duZF9hcHBsaWNhdGlvbl9saW1pdGVkKTsKIEVYUE9SVF9TWU1CT0wo dGNwX3BhcnNlX29wdGlvbnMpOwogRVhQT1JUX1NZTUJPTCh0Y3BfcmN2X2VzdGFibGlzaGVkKTsK IEVYUE9SVF9TWU1CT0wodGNwX3Jjdl9zdGF0ZV9wcm9jZXNzKTsKZGlmZiAtTnJ1IGEvbmV0L2lw djQvdGNwX2lwdjQuYyBiL25ldC9pcHY0L3RjcF9pcHY0LmMKLS0tIGEvbmV0L2lwdjQvdGNwX2lw djQuYwkyMDA0LTEyLTI0IDEzOjM2OjM0IC0wODowMAorKysgYi9uZXQvaXB2NC90Y3BfaXB2NC5j CTIwMDQtMTItMjQgMTM6MzY6MzQgLTA4OjAwCkBAIC00NDgsOCArNDQ4LDggQEAKIH0KIAogLyog T3B0aW1pemUgdGhlIGNvbW1vbiBsaXN0ZW5lciBjYXNlLiAqLwotaW5saW5lIHN0cnVjdCBzb2Nr ICp0Y3BfdjRfbG9va3VwX2xpc3RlbmVyKHUzMiBkYWRkciwgdW5zaWduZWQgc2hvcnQgaG51bSwK LQkJCQkJICAgaW50IGRpZikKK3N0YXRpYyBpbmxpbmUgc3RydWN0IHNvY2sgKnRjcF92NF9sb29r dXBfbGlzdGVuZXIodTMyIGRhZGRyLAorCQl1bnNpZ25lZCBzaG9ydCBobnVtLCBpbnQgZGlmKQog ewogCXN0cnVjdCBzb2NrICpzayA9IE5VTEw7CiAJc3RydWN0IGhsaXN0X2hlYWQgKmhlYWQ7CkBA IC01MzUsNiArNTM1LDggQEAKIAlyZXR1cm4gc2s7CiB9CiAKK0VYUE9SVF9TWU1CT0xfR1BMKHRj cF92NF9sb29rdXApOworCiBzdGF0aWMgaW5saW5lIF9fdTMyIHRjcF92NF9pbml0X3NlcXVlbmNl KHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHNrX2J1ZmYgKnNrYikKIHsKIAlyZXR1cm4gc2VjdXJl X3RjcF9zZXF1ZW5jZV9udW1iZXIoc2tiLT5uaC5pcGgtPmRhZGRyLApAQCAtMjU5Niw2ICsyNTk4 LDcgQEAKIAogc3RydWN0IHByb3RvIHRjcF9wcm90ID0gewogCS5uYW1lCQkJPSAiVENQIiwKKwku b3duZXIJCQk9IFRISVNfTU9EVUxFLAogCS5jbG9zZQkJCT0gdGNwX2Nsb3NlLAogCS5jb25uZWN0 CQk9IHRjcF92NF9jb25uZWN0LAogCS5kaXNjb25uZWN0CQk9IHRjcF9kaXNjb25uZWN0LApAQCAt MjY1Myw3ICsyNjU2LDYgQEAKIEVYUE9SVF9TWU1CT0wodGNwX3Y0X2Nvbm5fcmVxdWVzdCk7CiBF WFBPUlRfU1lNQk9MKHRjcF92NF9jb25uZWN0KTsKIEVYUE9SVF9TWU1CT0wodGNwX3Y0X2RvX3Jj dik7Ci1FWFBPUlRfU1lNQk9MKHRjcF92NF9sb29rdXBfbGlzdGVuZXIpOwogRVhQT1JUX1NZTUJP TCh0Y3BfdjRfcmVidWlsZF9oZWFkZXIpOwogRVhQT1JUX1NZTUJPTCh0Y3BfdjRfcmVtZW1iZXJf c3RhbXApOwogRVhQT1JUX1NZTUJPTCh0Y3BfdjRfc2VuZF9jaGVjayk7CkBAIC0yNjYzLDggKzI2 NjUsNyBAQAogRVhQT1JUX1NZTUJPTCh0Y3BfcHJvY19yZWdpc3Rlcik7CiBFWFBPUlRfU1lNQk9M KHRjcF9wcm9jX3VucmVnaXN0ZXIpOwogI2VuZGlmCi0jaWZkZWYgQ09ORklHX1NZU0NUTAogRVhQ T1JUX1NZTUJPTChzeXNjdGxfbG9jYWxfcG9ydF9yYW5nZSk7CiBFWFBPUlRfU1lNQk9MKHN5c2N0 bF9tYXhfc3luX2JhY2tsb2cpOwogRVhQT1JUX1NZTUJPTChzeXNjdGxfdGNwX2xvd19sYXRlbmN5 KTsKLSNlbmRpZgorCmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcF9taW5pc29ja3MuYyBiL25ldC9p cHY0L3RjcF9taW5pc29ja3MuYwotLS0gYS9uZXQvaXB2NC90Y3BfbWluaXNvY2tzLmMJMjAwNC0x Mi0yNCAxMzozNzowNCAtMDg6MDAKKysrIGIvbmV0L2lwdjQvdGNwX21pbmlzb2Nrcy5jCTIwMDQt MTItMjQgMTM6Mzc6MDQgLTA4OjAwCkBAIC03MDYsNyArNzA2LDcgQEAKIAkJc29ja19sb2NrX2lu aXQobmV3c2spOwogCQliaF9sb2NrX3NvY2sobmV3c2spOwogCi0JCW5ld3NrLT5za19kc3RfbG9j ayA9IFJXX0xPQ0tfVU5MT0NLRUQ7CisJCXJ3bG9ja19pbml0KCZuZXdzay0+c2tfZHN0X2xvY2sp OwogCQlhdG9taWNfc2V0KCZuZXdzay0+c2tfcm1lbV9hbGxvYywgMCk7CiAJCXNrYl9xdWV1ZV9o ZWFkX2luaXQoJm5ld3NrLT5za19yZWNlaXZlX3F1ZXVlKTsKIAkJYXRvbWljX3NldCgmbmV3c2st PnNrX3dtZW1fYWxsb2MsIDApOwpAQCAtNzE5LDcgKzcxOSw3IEBACiAJCW5ld3NrLT5za191c2Vy bG9ja3MgPSBzay0+c2tfdXNlcmxvY2tzICYgflNPQ0tfQklORFBPUlRfTE9DSzsKIAkJbmV3c2st PnNrX2JhY2tsb2cuaGVhZCA9IG5ld3NrLT5za19iYWNrbG9nLnRhaWwgPSBOVUxMOwogCQluZXdz ay0+c2tfc2VuZF9oZWFkID0gTlVMTDsKLQkJbmV3c2stPnNrX2NhbGxiYWNrX2xvY2sgPSBSV19M T0NLX1VOTE9DS0VEOworCQlyd2xvY2tfaW5pdCgmbmV3c2stPnNrX2NhbGxiYWNrX2xvY2spOwog CQlza2JfcXVldWVfaGVhZF9pbml0KCZuZXdzay0+c2tfZXJyb3JfcXVldWUpOwogCQluZXdzay0+ c2tfd3JpdGVfc3BhY2UgPSBza19zdHJlYW1fd3JpdGVfc3BhY2U7CiAKQEAgLTEwNzUsNyArMTA3 NSwzIEBACiBFWFBPUlRfU1lNQk9MKHRjcF9jcmVhdGVfb3BlbnJlcV9jaGlsZCk7CiBFWFBPUlRf U1lNQk9MKHRjcF90aW1ld2FpdF9zdGF0ZV9wcm9jZXNzKTsKIEVYUE9SVF9TWU1CT0wodGNwX3R3 X2Rlc2NoZWR1bGUpOwotCi0jaWZkZWYgQ09ORklHX1NZU0NUTAotRVhQT1JUX1NZTUJPTChzeXNj dGxfdGNwX3R3X3JlY3ljbGUpOwotI2VuZGlmCmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcF9vdXRw dXQuYyBiL25ldC9pcHY0L3RjcF9vdXRwdXQuYwotLS0gYS9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJ MjAwNC0xMi0yNCAxMzozNzowMSAtMDg6MDAKKysrIGIvbmV0L2lwdjQvdGNwX291dHB1dC5jCTIw MDQtMTItMjQgMTM6Mzc6MDEgLTA4OjAwCkBAIC00NTUsOSArNDU1LDEzIEBACiB7CiAJc3RydWN0 IHRjcF9vcHQgKnRwID0gdGNwX3NrKHNrKTsKIAlzdHJ1Y3Qgc2tfYnVmZiAqYnVmZjsKLQlpbnQg bnNpemUgPSBza2ItPmxlbiAtIGxlbjsKKwlpbnQgbnNpemU7CiAJdTE2IGZsYWdzOwogCisJbnNp emUgPSBza2JfaGVhZGxlbihza2IpIC0gbGVuOworCWlmIChuc2l6ZSA8IDApCisJCW5zaXplID0g MDsKKwogCWlmIChza2JfY2xvbmVkKHNrYikgJiYKIAkgICAgc2tiX2lzX25vbmxpbmVhcihza2Ip ICYmCiAJICAgIHBza2JfZXhwYW5kX2hlYWQoc2tiLCAwLCAwLCBHRlBfQVRPTUlDKSkKQEAgLTU2 Miw4ICs1NjYsNiBAQAogCiBpbnQgdGNwX3RyaW1faGVhZChzdHJ1Y3Qgc29jayAqc2ssIHN0cnVj dCBza19idWZmICpza2IsIHUzMiBsZW4pCiB7Ci0Jc3RydWN0IHRjcF9vcHQgKnRwID0gdGNwX3Nr KHNrKTsKLQogCWlmIChza2JfY2xvbmVkKHNrYikgJiYKIAkgICAgcHNrYl9leHBhbmRfaGVhZChz a2IsIDAsIDAsIEdGUF9BVE9NSUMpKQogCQlyZXR1cm4gLUVOT01FTTsKQEAgLTU4Niw3ICs1ODgs OCBAQAogCS8qIEFueSBjaGFuZ2Ugb2Ygc2tiLT5sZW4gcmVxdWlyZXMgcmVjYWxjdWxhdGlvbiBv ZiB0c28KIAkgKiBmYWN0b3IgYW5kIG1zcy4KIAkgKi8KLQl0Y3Bfc2V0X3NrYl90c29fc2Vncyhz a2IsIHRwLT5tc3NfY2FjaGVfc3RkKTsKKwlpZiAodGNwX3NrYl9wY291bnQoc2tiKSA+IDEpCisJ CXRjcF9zZXRfc2tiX3Rzb19zZWdzKHNrYiwgdGNwX3NrYl9tc3Moc2tiKSk7CiAKIAlyZXR1cm4g MDsKIH0KQEAgLTExMDIsNiArMTEwNSw4IEBACiAJCS8qIFVwZGF0ZSBnbG9iYWwgVENQIHN0YXRp c3RpY3MuICovCiAJCVRDUF9JTkNfU1RBVFMoVENQX01JQl9SRVRSQU5TU0VHUyk7CiAKKwkJdHAt PnRvdGFsX3JldHJhbnMrKzsKKwogI2lmIEZBU1RSRVRSQU5TX0RFQlVHID4gMAogCQlpZiAoVENQ X1NLQl9DQihza2IpLT5zYWNrZWQmVENQQ0JfU0FDS0VEX1JFVFJBTlMpIHsKIAkJCWlmIChuZXRf cmF0ZWxpbWl0KCkpCkBAIC0xNzE1LDEyICsxNzIwLDcgQEAKIAl9CiB9CiAKLUVYUE9SVF9TWU1C T0wodGNwX2FjY2VwdGFibGVfc2VxKTsKIEVYUE9SVF9TWU1CT0wodGNwX2Nvbm5lY3QpOwotRVhQ T1JUX1NZTUJPTCh0Y3BfY29ubmVjdF9pbml0KTsKIEVYUE9SVF9TWU1CT0wodGNwX21ha2Vfc3lu YWNrKTsKLUVYUE9SVF9TWU1CT0wodGNwX3NlbmRfc3luYWNrKTsKIEVYUE9SVF9TWU1CT0wodGNw X3NpbXBsZV9yZXRyYW5zbWl0KTsKIEVYUE9SVF9TWU1CT0wodGNwX3N5bmNfbXNzKTsKLUVYUE9S VF9TWU1CT0wodGNwX3dyaXRlX3dha2V1cCk7Ci1FWFBPUlRfU1lNQk9MKHRjcF93cml0ZV94bWl0 KTsKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwX3RpbWVyLmMgYi9uZXQvaXB2NC90Y3BfdGltZXIu YwotLS0gYS9uZXQvaXB2NC90Y3BfdGltZXIuYwkyMDA0LTEyLTI0IDEzOjM3OjE5IC0wODowMAor KysgYi9uZXQvaXB2NC90Y3BfdGltZXIuYwkyMDA0LTEyLTI0IDEzOjM3OjE5IC0wODowMApAQCAt MzYsNyArMzYsOSBAQAogc3RhdGljIHZvaWQgdGNwX2RlbGFja190aW1lcih1bnNpZ25lZCBsb25n KTsKIHN0YXRpYyB2b2lkIHRjcF9rZWVwYWxpdmVfdGltZXIgKHVuc2lnbmVkIGxvbmcgZGF0YSk7 CiAKLWNvbnN0IGNoYXIgdGltZXJfYnVnX21zZ1tdID0gS0VSTl9ERUJVRyAidGNwYnVnOiB1bmtu b3duIHRpbWVyIHZhbHVlXG4iOworI2lmZGVmIFRDUF9ERUJVRworY29uc3QgY2hhciB0Y3BfdGlt ZXJfYnVnX21zZ1tdID0gS0VSTl9ERUJVRyAidGNwYnVnOiB1bmtub3duIHRpbWVyIHZhbHVlXG4i OworI2VuZGlmCiAKIC8qCiAgKiBVc2luZyBkaWZmZXJlbnQgdGltZXJzIGZvciByZXRyYW5zbWl0 LCBkZWxheWVkIGFja3MgYW5kIHByb2JlcwpAQCAtNjUxLDMgKzY1Myw2IEBACiBFWFBPUlRfU1lN Qk9MKHRjcF9kZWxldGVfa2VlcGFsaXZlX3RpbWVyKTsKIEVYUE9SVF9TWU1CT0wodGNwX2luaXRf eG1pdF90aW1lcnMpOwogRVhQT1JUX1NZTUJPTCh0Y3BfcmVzZXRfa2VlcGFsaXZlX3RpbWVyKTsK KyNpZmRlZiBUQ1BfREVCVUcKK0VYUE9SVF9TWU1CT0wodGNwX3RpbWVyX2J1Z19tc2cpOworI2Vu ZGlmCmRpZmYgLU5ydSBhL25ldC9pcHY2L3RjcF9pcHY2LmMgYi9uZXQvaXB2Ni90Y3BfaXB2Ni5j Ci0tLSBhL25ldC9pcHY2L3RjcF9pcHY2LmMJMjAwNC0xMi0yNCAxMzozNjo1NiAtMDg6MDAKKysr IGIvbmV0L2lwdjYvdGNwX2lwdjYuYwkyMDA0LTEyLTI0IDEzOjM2OjU2IC0wODowMApAQCAtMjYy LDcgKzI2Miw3IEBACiAJCQkKIAkJCXNjb3JlID0gMTsKIAkJCWlmICghaXB2Nl9hZGRyX2FueSgm bnAtPnJjdl9zYWRkcikpIHsKLQkJCQlpZiAoaXB2Nl9hZGRyX2NtcCgmbnAtPnJjdl9zYWRkciwg ZGFkZHIpKQorCQkJCWlmICghaXB2Nl9hZGRyX2VxdWFsKCZucC0+cmN2X3NhZGRyLCBkYWRkcikp CiAJCQkJCWNvbnRpbnVlOwogCQkJCXNjb3JlKys7CiAJCQl9CkBAIC0zMjEsOCArMzIxLDggQEAK IAogCQlpZigqKChfX3UzMiAqKSYodHctPnR3X2Rwb3J0KSkJPT0gcG9ydHMJJiYKIAkJICAgc2st PnNrX2ZhbWlseQkJPT0gUEZfSU5FVDYpIHsKLQkJCWlmKCFpcHY2X2FkZHJfY21wKCZ0dy0+dHdf djZfZGFkZHIsIHNhZGRyKQkmJgotCQkJICAgIWlwdjZfYWRkcl9jbXAoJnR3LT50d192Nl9yY3Zf c2FkZHIsIGRhZGRyKQkmJgorCQkJaWYoaXB2Nl9hZGRyX2VxdWFsKCZ0dy0+dHdfdjZfZGFkZHIs IHNhZGRyKQkmJgorCQkJICAgaXB2Nl9hZGRyX2VxdWFsKCZ0dy0+dHdfdjZfcmN2X3NhZGRyLCBk YWRkcikJJiYKIAkJCSAgICghc2stPnNrX2JvdW5kX2Rldl9pZiB8fCBzay0+c2tfYm91bmRfZGV2 X2lmID09IGRpZikpCiAJCQkJZ290byBoaXQ7CiAJCX0KQEAgLTM2NCw2ICszNjQsOCBAQAogCXJl dHVybiBzazsKIH0KIAorRVhQT1JUX1NZTUJPTF9HUEwodGNwX3Y2X2xvb2t1cCk7CisKIAogLyoK ICAqIE9wZW4gcmVxdWVzdCBoYXNoIHRhYmxlcy4KQEAgLTQwNCw4ICs0MDYsOCBAQAogCSAgICAg cHJldiA9ICZyZXEtPmRsX25leHQpIHsKIAkJaWYgKHJlcS0+cm10X3BvcnQgPT0gcnBvcnQgJiYK IAkJICAgIHJlcS0+Y2xhc3MtPmZhbWlseSA9PSBBRl9JTkVUNiAmJgotCQkgICAgIWlwdjZfYWRk cl9jbXAoJnJlcS0+YWYudjZfcmVxLnJtdF9hZGRyLCByYWRkcikgJiYKLQkJICAgICFpcHY2X2Fk ZHJfY21wKCZyZXEtPmFmLnY2X3JlcS5sb2NfYWRkciwgbGFkZHIpICYmCisJCSAgICBpcHY2X2Fk ZHJfZXF1YWwoJnJlcS0+YWYudjZfcmVxLnJtdF9hZGRyLCByYWRkcikgJiYKKwkJICAgIGlwdjZf YWRkcl9lcXVhbCgmcmVxLT5hZi52Nl9yZXEubG9jX2FkZHIsIGxhZGRyKSAmJgogCQkgICAgKCFy ZXEtPmFmLnY2X3JlcS5paWYgfHwgcmVxLT5hZi52Nl9yZXEuaWlmID09IGlpZikpIHsKIAkJCUJV R19UUkFQKHJlcS0+c2sgPT0gTlVMTCk7CiAJCQkqcHJldnAgPSBwcmV2OwpAQCAtNDYxLDggKzQ2 Myw4IEBACiAKIAkJaWYoKigoX191MzIgKikmKHR3LT50d19kcG9ydCkpCT09IHBvcnRzCSYmCiAJ CSAgIHNrMi0+c2tfZmFtaWx5CQk9PSBQRl9JTkVUNgkmJgotCQkgICAhaXB2Nl9hZGRyX2NtcCgm dHctPnR3X3Y2X2RhZGRyLCBzYWRkcikJJiYKLQkJICAgIWlwdjZfYWRkcl9jbXAoJnR3LT50d192 Nl9yY3Zfc2FkZHIsIGRhZGRyKQkmJgorCQkgICBpcHY2X2FkZHJfZXF1YWwoJnR3LT50d192Nl9k YWRkciwgc2FkZHIpCSYmCisJCSAgIGlwdjZfYWRkcl9lcXVhbCgmdHctPnR3X3Y2X3Jjdl9zYWRk ciwgZGFkZHIpCSYmCiAJCSAgIHNrMi0+c2tfYm91bmRfZGV2X2lmID09IHNrLT5za19ib3VuZF9k ZXZfaWYpIHsKIAkJCXN0cnVjdCB0Y3Bfb3B0ICp0cCA9IHRjcF9zayhzayk7CiAKQEAgLTYwOCw3 ICs2MTAsNyBAQAogCX0KIAogCWlmICh0cC0+dHNfcmVjZW50X3N0YW1wICYmCi0JICAgIGlwdjZf YWRkcl9jbXAoJm5wLT5kYWRkciwgJnVzaW4tPnNpbjZfYWRkcikpIHsKKwkgICAgIWlwdjZfYWRk cl9lcXVhbCgmbnAtPmRhZGRyLCAmdXNpbi0+c2luNl9hZGRyKSkgewogCQl0cC0+dHNfcmVjZW50 ID0gMDsKIAkJdHAtPnRzX3JlY2VudF9zdGFtcCA9IDA7CiAJCXRwLT53cml0ZV9zZXEgPSAwOwpA QCAtMTgwMiw2ICsxODA0LDcgQEAKIAlzdHJ1Y3QgaXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhz ayk7CiAJc3RydWN0IGZsb3dpIGZsOwogCXN0cnVjdCBkc3RfZW50cnkgKmRzdDsKKwlzdHJ1Y3Qg aW42X2FkZHIgKmZpbmFsX3AgPSBOVUxMLCBmaW5hbDsKIAogCW1lbXNldCgmZmwsIDAsIHNpemVv ZihmbCkpOwogCWZsLnByb3RvID0gSVBQUk9UT19UQ1A7CkBAIC0xODE1LDcgKzE4MTgsOSBAQAog CiAJaWYgKG5wLT5vcHQgJiYgbnAtPm9wdC0+c3JjcnQpIHsKIAkJc3RydWN0IHJ0MF9oZHIgKnJ0 MCA9IChzdHJ1Y3QgcnQwX2hkciAqKSBucC0+b3B0LT5zcmNydDsKKwkJaXB2Nl9hZGRyX2NvcHko JmZpbmFsLCAmZmwuZmw2X2RzdCk7CiAJCWlwdjZfYWRkcl9jb3B5KCZmbC5mbDZfZHN0LCBydDAt PmFkZHIpOworCQlmaW5hbF9wID0gJmZpbmFsOwogCX0KIAogCWRzdCA9IF9fc2tfZHN0X2NoZWNr KHNrLCBucC0+ZHN0X2Nvb2tpZSk7CkBAIC0xODI4LDYgKzE4MzMsOSBAQAogCQkJcmV0dXJuIGVy cjsKIAkJfQogCisJCWlmIChmaW5hbF9wKQorCQkJaXB2Nl9hZGRyX2NvcHkoJmZsLmZsNl9kc3Qs IGZpbmFsX3ApOworCiAJCWlmICgoZXJyID0geGZybV9sb29rdXAoJmRzdCwgJmZsLCBzaywgMCkp IDwgMCkgewogCQkJc2stPnNrX3JvdXRlX2NhcHMgPSAwOwogCQkJZHN0X3JlbGVhc2UoZHN0KTsK QEAgLTIxMjQsNiArMjEzMiw3IEBACiAKIHN0cnVjdCBwcm90byB0Y3B2Nl9wcm90ID0gewogCS5u YW1lCQkJPSAiVENQdjYiLAorCS5vd25lcgkJCT0gVEhJU19NT0RVTEUsCiAJLmNsb3NlCQkJPSB0 Y3BfY2xvc2UsCiAJLmNvbm5lY3QJCT0gdGNwX3Y2X2Nvbm5lY3QsCiAJLmRpc2Nvbm5lY3QJCT0g dGNwX2Rpc2Nvbm5lY3QsCg== --Multipart=_Wed__16_Feb_2005_09_50_04_-0800_Zbi.SACP4ddtnNZC-- From kaber@trash.net Wed Feb 16 10:54:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 10:54:33 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GIsNb6017731 for ; Wed, 16 Feb 2005 10:54:24 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1UJV-0008Rh-BW; Wed, 16 Feb 2005 19:54:17 +0100 Message-ID: <421396D9.2030405@trash.net> Date: Wed, 16 Feb 2005 19:54:17 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [PATCH 2.4 NETLINK]: Unhash sockets correctly Content-Type: multipart/mixed; boundary="------------050500020804090602010302" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2002 Lines: 63 This is a multi-part message in MIME format. --------------050500020804090602010302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, this patch fixes a nasty bug introduced by the pid-hash backport. Sockets are only unhashed if they are contained in the first hash bucket. This leads to leaking sockets and, over time, to bind conflicts which confuse iproute and result in sporadic failure. Regards Patrick --------------050500020804090602010302 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/16 19:32:38+01:00 kaber@coreworks.de # [NETLINK]: Unhash sockets correctly # # netlink_remove() only unhashes sockets contained in the # first hash bucket. This leads to leaking sockets and, # over time, to bind conflicts which confuse iproute. # # Signed-off-by: Patrick McHardy # # net/netlink/af_netlink.c # 2005/02/16 19:32:36+01:00 kaber@coreworks.de +2 -1 # [NETLINK]: Unhash sockets correctly # # netlink_remove() only unhashes sockets contained in the # first hash bucket. This leads to leaking sockets and, # over time, to bind conflicts which confuse iproute. # # Signed-off-by: Patrick McHardy # diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c 2005-02-16 19:32:51 +01:00 +++ b/net/netlink/af_netlink.c 2005-02-16 19:32:51 +01:00 @@ -327,10 +327,11 @@ struct sock **skp; struct netlink_table *table = &nl_table[sk->protocol]; struct nl_pid_hash *hash = &table->hash; + u32 pid = nlk_sk(sk)->pid; netlink_table_grab(); hash->entries--; - for (skp = hash->table; *skp; skp = &((*skp)->next)) { + for (skp = nl_pid_hashfn(hash, pid); *skp; skp = &((*skp)->next)) { if (*skp == sk) { *skp = sk->next; __sock_put(sk); --------------050500020804090602010302-- From jmoyer@redhat.com Wed Feb 16 11:26:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 11:26:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GJQX4G019826 for ; Wed, 16 Feb 2005 11:26:34 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1GJQWjm012789; Wed, 16 Feb 2005 14:26:32 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1GJQVO23610; Wed, 16 Feb 2005 14:26:32 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1GJQVZg028962; Wed, 16 Feb 2005 14:26:31 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j1GJQbEV021311; Wed, 16 Feb 2005 14:26:37 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j1GJQbVA021308; Wed, 16 Feb 2005 14:26:37 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.40557.591071.224381@segfault.boston.redhat.com> Date: Wed, 16 Feb 2005 14:26:37 -0500 To: Matt Mackall Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI In-Reply-To: <20050216050722.GC3358@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 3931 Lines: 90 ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: mpm> On Tue, Feb 15, 2005 at 05:49:50PM -0500, Jeff Moyer wrote: >> ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: >> >> Sorry, Matt, I'm just now getting to this. >> mpm> On Wed, Feb 09, 2005 at 04:46:58PM -0800, David S. Miller wrote: >> >> On Wed, 9 Feb 2005 10:32:19 -0800 Matt Mackall wrote: >> >> >> >> > On closer inspection, there's a couple other related failure cases > >> >> with the new ->poll logic in netpoll. I'm afraid it looks like > >> >> CONFIG_NETPOLL will need to guard ->poll() with a per-device spinlock > >> >> on netpoll-enabled devices. >> >> > >> >> > This will mean putting a pointer to struct netpoll in struct > >> >> net_device (which I should have done in the first place) and will take > >> >> a few patches to sort out. >> >> >> >> Will this ->poll() guarding lock be acquired only in the netpoll code or >> >> system-wide? If the latter, this introduced an incredible performance >> >> regression for devices using the LLTX locking scheme (ie. the most >> >> important high-performance gigabit drivers in the tree use this). >> mpm> The lock will only be taken in net_rx_action iff netpoll is enabled mpm> for the given device. Lock contention should be basically nil. >> mpm> Here's my current patch (on top of -mm), which I'm struggling to find mpm> an appropriate test box for (my dual box with NAPI got pressed into mpm> service as a web server a couple weeks ago). I've attached the other mpm> two patches it relies on as well. >> mpm> -------------- >> mpm> Introduce a per-client poll lock and flag. The lock assures we never mpm> have more than one caller in dev->poll(). The flag provides recursion mpm> avoidance on UP where the lock disappears. >> >> ,---- >> | /* >> | - * Check whether delayed processing was scheduled for our current CPU, >> | - * and then manually invoke NAPI polling to pump data off the card. >> | + * Check whether delayed processing was scheduled for our NIC. If so, >> | + * we attempt to grab the poll lock and use ->poll() to pump the card. >> | + * If this fails, either we've recursed in ->poll() or it's already >> | + * running on another CPU. >> | + * >> | + * Note: we don't mask interrupts with this lock because we're using >> | + * trylock here and interrupts are already disabled in the softirq >> | + * case. Further, we test the poll_flag to avoid recursion on UP >> | + * systems where the lock doesn't exist. >> | * >> | * In cases where there is bi-directional communications, reading only >> | * one message at a time can lead to packets being dropped by the >> | @@ -74,13 +80,9 @@ >> | static void poll_napi(struct netpoll *np) >> | { >> | int budget = 16; >> | - unsigned long flags; >> | - struct softnet_data *queue; >> | >> | - spin_lock_irqsave(&netpoll_poll_lock, flags); >> | - queue = &__get_cpu_var(softnet_data); >> | if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && >> | - !list_empty(&queue->poll_list)) { >> | + !np->poll_flag && spin_trylock(&np->poll_lock)) { >> | np->rx_flags |= NETPOLL_RX_DROP; >> | atomic_inc(&trapped); >> | >> | @@ -88,8 +90,8 @@ >> | >> | atomic_dec(&trapped); >> | np->rx_flags &= ~NETPOLL_RX_DROP; >> | + spin_unlock(&np->poll_lock); >> | } >> | - spin_unlock_irqrestore(&netpoll_poll_lock, flags); >> | } >> >> Okay, I've only taken a quick glance at this, but I don't quite understand >> why it's safe to take out the check for the per-cpu queue. Realize that an >> interrupt may have been serviced on another processor, and a NAPI poll may >> have been scheduled there. mpm> Because dev->np->poll_lock now serializes all access to ->poll (when mpm> netpoll is enabled on said device). Ahh, yes. This does look like the right approach. I'll see if I can reproduce and test this here. -Jeff From ebrower@usa.net Wed Feb 16 11:38:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 11:38:35 -0800 (PST) Received: from stepchild.resilience.com (167.100.172.209.cust.nextweb.net [209.172.100.167] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GJcUAn020752 for ; Wed, 16 Feb 2005 11:38:30 -0800 Received: from [10.2.0.100] ([10.2.0.100]) by stepchild.resilience.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Feb 2005 11:38:24 -0800 Message-ID: <4213A130.8070909@usa.net> Date: Wed, 16 Feb 2005 11:38:24 -0800 From: Eric Brower User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux@syskonnect.de Subject: [PATCH] sk98lin hardware rx csum offload logic Content-Type: multipart/mixed; boundary="------------020406010901000006040902" X-OriginalArrivalTime: 16 Feb 2005 19:38:24.0872 (UTC) FILETIME=[14864680:01C5145F] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebrower@usa.net Precedence: bulk X-list: netdev Content-Length: 1637 Lines: 46 This is a multi-part message in MIME format. --------------020406010901000006040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The sk98lin driver drops received packets that have an invalid IP/UDP/TCP checksum-- it should be passing these packets up the stack by marking the skb's ip_summed to CHECKSUM_NONE rather than simply dropping them (ref. http://efault.net/npat/docs_and_postings/net_device-features/net_device-features.txt and other network driver implementations) Attached is a patch against the latest BK 2.6 kernel. This issue also applies to 2.4 and the latest version of the driver (8.13.1.3) on the SysKonnect site, though in that case a similar fix needs to be made to the sky2.c Yukon2 support. I'm not on the netdev list, so if there is any further discussion please include me directly. Thanks, E --------------020406010901000006040902 Content-Type: text/plain; name="sk98lin_hwrxcsum.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sk98lin_hwrxcsum.patch" ===== drivers/net/sk98lin/skge.c 1.54 vs edited ===== --- 1.54/drivers/net/sk98lin/skge.c 2004-11-03 14:31:05 -08:00 +++ edited/drivers/net/sk98lin/skge.c 2005-02-16 09:14:02 -08:00 @@ -2254,8 +2254,8 @@ /* HW Checksum error */ SK_DBG_MSG(NULL, SK_DBGMOD_DRV, SK_DBGCAT_DRV_RX_PROGRESS, - ("skge: CRC error. Frame dropped!\n")); - goto rx_failed; + ("skge: CRC error.\n")); + pMsg->ip_summed = CHECKSUM_NONE; } else { pMsg->ip_summed = CHECKSUM_NONE; --------------020406010901000006040902-- From davem@davemloft.net Wed Feb 16 11:55:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 11:55:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GJtqCm021830 for ; Wed, 16 Feb 2005 11:55:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1VEG-0004lx-00; Wed, 16 Feb 2005 11:52:56 -0800 Date: Wed, 16 Feb 2005 11:52:55 -0800 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4 NETLINK]: Unhash sockets correctly Message-Id: <20050216115255.107b6641.davem@davemloft.net> In-Reply-To: <421396D9.2030405@trash.net> References: <421396D9.2030405@trash.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 410 Lines: 9 On Wed, 16 Feb 2005 19:54:17 +0100 Patrick McHardy wrote: > this patch fixes a nasty bug introduced by the pid-hash backport. > Sockets are only unhashed if they are contained in the first hash > bucket. This leads to leaking sockets and, over time, to bind > conflicts which confuse iproute and result in sporadic failure. Good catch Patrick. Applied, and I'll push upstream momentarily. From hubert.tonneau@fullpliant.org Wed Feb 16 12:28:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 12:28:21 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1GKS5rJ026774 for ; Wed, 16 Feb 2005 12:28:06 -0800 From: Hubert Tonneau To: "David S. Miller" , Alexey Kuznetsov Cc: shemminger@osdl.org, romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Wed, 16 Feb 2005 20:00:29 GMT Message-ID: <052EQ8T12@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 8496 Lines: 263 David S. Miller wrote: > > Hubert, do you have netfilter enabled in the 2.6.10 kernel you are running? > > I'm asking because the TCP changes in 2.6.10 are pretty benign > (attached for the curious who want to review along), whereas > netfilter had major updates particularly in the TCP connection > tracking code. There is no netfilter on this server. > I also reviewed 2.6.10-ac11 for anything interesting wrt. TCP and the > only thing in there is the tcp_retrans_try_collapse() missing check > to avoid collapsing TSO segments. I'm using 2.6.10-ac11 for security reasons. I could use 2.6.10-as1 as well. As far as I know, they all behave exactly the same from the TCP point of view. The difference is definetly between stock 2.6.9 and stock 2.6.10 If it helps, you can send me a patch reverting TCP changes between 2.6.10 and 2.6.9, and I'll give it a spin, just to be sure that the problem is truely related to TCP code, not other changes side effects. Anyway, here is the set of settings I'm using to build the kernel, and no module is loaded while the test is running: CONFIG_2GB: y CONFIG_ACPI: y CONFIG_ACPI_AC: m CONFIG_ACPI_BATTERY: m CONFIG_ACPI_BUTTON: m CONFIG_ACPI_FAN: m CONFIG_ACPI_PROCESSOR: y CONFIG_ACPI_SLEEP: y CONFIG_ACPI_THERMAL: y CONFIG_ACPI_VIDEO: m CONFIG_APM_RTC_IS_GMT: y CONFIG_ATALK: m CONFIG_AUTODETECT_RAID: y CONFIG_AUTOFS_FS: m CONFIG_BINFMT_ELF: y CONFIG_BINFMT_MISC: y CONFIG_BLK_DEV_CMD640: y CONFIG_BLK_DEV_FD: m CONFIG_BLK_DEV_GENERIC: y CONFIG_BLK_DEV_IDE: y CONFIG_BLK_DEV_IDECD: m CONFIG_BLK_DEV_IDEDISK: y CONFIG_BLK_DEV_IDEDMA: y CONFIG_BLK_DEV_IDEDMA_PCI: y CONFIG_BLK_DEV_IDEPCI: y CONFIG_BLK_DEV_IDESCSI: m CONFIG_BLK_DEV_LOOP: m CONFIG_BLK_DEV_MD: y CONFIG_BLK_DEV_NBD: m CONFIG_BLK_DEV_PIIX: y CONFIG_BLK_DEV_RAM: m CONFIG_BLK_DEV_RZ1000: y CONFIG_BLK_DEV_SD: y CONFIG_BLK_DEV_SR: m CONFIG_BLK_DEV_TRIRON: y CONFIG_BSD_PROCESS_ACCT: y CONFIG_CHR_DEV_SG: m CONFIG_CHR_DEV_ST: m CONFIG_CODA_FS: m CONFIG_E1000: y CONFIG_EXPERIMENTAL: y CONFIG_EXT2_FS: y CONFIG_EXT3_FS: y CONFIG_EXT3_FS_XATTR: y CONFIG_FAT_FS: m CONFIG_FILTER: y CONFIG_FUSION: y CONFIG_FUSION_CTL: m CONFIG_FUSION_ISENSE: m CONFIG_FUSION_LAN: m CONFIG_HFSPLUS_FS: m CONFIG_HFS_FS: m CONFIG_HIGHMEM: y CONFIG_HIGHMEM4G: y CONFIG_HPET_TIMER: y CONFIG_HPFS_FS: m CONFIG_IDE: y CONFIG_IDEDMA_AUTO: y CONFIG_IDEDMA_ONLYDISK: y CONFIG_IDEDMA_PCI_AUTO: y CONFIG_IDEPCI_SHARE_IRQ: y CONFIG_IDE_GENERIC: y CONFIG_INET: y CONFIG_INPUT: y CONFIG_INPUT_KEYBDEV: m CONFIG_INPUT_KEYBOARD: y CONFIG_INPUT_MOUSE: y CONFIG_INPUT_MOUSEDEV: m CONFIG_IP_ALIAS: y CONFIG_IP_ROUTE_VERBOSE: y CONFIG_IRQBALANCE: y CONFIG_ISO9660_FS: m CONFIG_KCORE_ELF: y CONFIG_KEYBOARD_ATKBD: y CONFIG_LEGACY_PTYS: y CONFIG_LOCKD: m CONFIG_M386: n CONFIG_M486: n CONFIG_M586: n CONFIG_M686: n CONFIG_MAC_PARTITION: y CONFIG_MD: y CONFIG_MD_BOOT: y CONFIG_MD_LINEAR: y CONFIG_MD_LVM: n CONFIG_MD_MIRRORING: y CONFIG_MD_RAID0: y CONFIG_MD_RAID1: y CONFIG_MD_RAID5: y CONFIG_MD_STRIPED: y CONFIG_MD_TRANSLUCENT: n CONFIG_MODULES: y CONFIG_MODULE_UNLOAD: y CONFIG_MOUSE: m CONFIG_MOUSE_PS2: y CONFIG_MPENTIUM4: y CONFIG_MSDOS_FS: m CONFIG_MTRR: y CONFIG_NET: y CONFIG_NETDEVICES: y CONFIG_NET_ETHERNET: y CONFIG_NFSD: m CONFIG_NFS_FS: m CONFIG_NLS: y CONFIG_NLS_CODEPAGE_437: m CONFIG_NLS_CODEPAGE_850: m CONFIG_NLS_ISO8859_1: m CONFIG_NLS_UTF8: m CONFIG_NTFS_FS: m CONFIG_OOM_KILLER: y CONFIG_PACKET: y CONFIG_PARPORT: m CONFIG_PARPORT_PC: m CONFIG_PCI: y CONFIG_PCI_BIOS: y CONFIG_PCI_GOANY: y CONFIG_PCI_OLD_PROC: y CONFIG_PCI_QUIRKS: y CONFIG_PIIX_TUNING: y CONFIG_PM: y CONFIG_PPP: m CONFIG_PPPOE: m CONFIG_PPP_ASYNC: m CONFIG_PPP_BSDCOMP: m CONFIG_PPP_DEFLATE: m CONFIG_PPP_FILTER: y CONFIG_PPP_SYNC_TTY: m CONFIG_PREEMPT: y CONFIG_PRINTER: m CONFIG_PRINTER_READBACK: y CONFIG_PROC_FS: y CONFIG_PSMOUSE: y CONFIG_QNX4FS_FS: m CONFIG_REGPARM: y CONFIG_RTC: y CONFIG_SCSI: y CONFIG_SCSI_PROC_FS: y CONFIG_SERIAL: m CONFIG_SERIAL_8250: m CONFIG_SHAPER: m CONFIG_SLIP: m CONFIG_SMB_FS: m CONFIG_SMP: y CONFIG_SOUND: m CONFIG_SUNRPC: m CONFIG_SYSCTL: y CONFIG_SYSVIPC: y CONFIG_UFS_FS: m CONFIG_UMSDOS_FS: m CONFIG_UNIX: y CONFIG_USB: m CONFIG_USB_ACM: m CONFIG_USB_AUDIO: m CONFIG_USB_CDCETHER: m CONFIG_USB_DEVICEFS: y CONFIG_USB_EHCI_HCD: m CONFIG_USB_HID: m CONFIG_USB_HIDINPUT: y CONFIG_USB_KBD: m CONFIG_USB_MOUSE: m CONFIG_USB_OHCI: m CONFIG_USB_OHCI_HCD: m CONFIG_USB_PRINTER: m CONFIG_USB_SERIAL: m CONFIG_USB_STORAGE: m CONFIG_USB_UHCI: m CONFIG_USB_UHCI_ALT: m CONFIG_USB_UHCI_HCD: m CONFIG_VFAT_FS: m CONFIG_VGA_CONSOLE: y CONFIG_VT: y CONFIG_VT_CONSOLE: y CONFIG_X86_MCE: y CONFIG_X86_UP_APIC: y CONFIG_X86_UP_IOAPIC: y Since we are at it, here are the hardware components of the box: 8086 Intel Corporation 254C E7501 0 Host Controller 8086 Intel Corporation 2543 E7500/E7501 0 HI_B Virtual PCI-to-PCI Bridge 8086 Intel Corporation 2545 E7500/E7501 0 HI_C Virtual PCI-to-PCI Bridge 8086 Intel Corporation 2547 E7500/E7501 0 HI_D Virtual PCI-to-PCI Bridge 8086 Intel Corporation 2482 82801CA/CAM 10 USB Controller 8086 Intel Corporation 244E 82801BA/CA/DB, 6300ESB 0 Hub Interface to PCI Bridge 8086 Intel Corporation 2480 82801CA 0 LPC Interface Bridge 8086 Intel Corporation 248B 82801CA 0 UltraATA/100 IDE Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1461 14611014 0 I/OxAPIC Interrupt Controller 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1460 82870P2 0 Hub Interface-to-PCI Bridge 8086 Intel Corporation 1026 82545GM 18 Gigabit Ethernet Controller 8086 Intel Corporation 100D 82544GC 1C Gigabit Ethernet Controller (LOM) 8086 Intel Corporation 0309 80303 0 I/O Processor PCI-to-PCI Bridge Unit 1000 LSI Logic 0030 LSI53C1020/1030 78 PCI-X to Ultra320 SCSI Controller 1000 LSI Logic 0030 LSI53C1020/1030 79 PCI-X to Ultra320 SCSI Controller 1002 ATI Technologies 4752 Rage XL PCI 0 And the interrupts (while running 2.6.9): CPU0 CPU1 0: 159132374 132686719 IO-APIC-edge timer 1: 9 0 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 14: 1 0 IO-APIC-edge ide0 24: 22225220 0 IO-APIC-level eth0 28: 4 134406507 IO-APIC-level eth1 120: 532730 578109 IO-APIC-level ioc0 121: 1931739 1327672 IO-APIC-level ioc1 NMI: 0 0 LOC: 291863458 291863528 ERR: 0 MIS: 0 /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed eth0:2512143307 20914618 0 0 0 0 0 0 1951489031 52933097 0 0 0 0 0 0 eth1:943883086 75451745 0 0 0 0 0 0 201914508 171409895 0 0 0 0 0 0 lo:2247204588 748445 0 0 0 0 0 0 2247204588 748445 0 0 0 0 0 0 /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 207C29D5 00000000 0001 0 0 0 F0FFFFFF 0 0 0 eth1 00606B0A 00000000 0001 0 0 0 00FFFFFF 0 0 0 eth0 00000000 217C29D5 0003 0 0 0 00000000 0 0 0 From davem@davemloft.net Wed Feb 16 13:22:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 13:22:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GLMkdv029738 for ; Wed, 16 Feb 2005 13:22:46 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1WUH-00058t-00; Wed, 16 Feb 2005 13:13:33 -0800 Date: Wed, 16 Feb 2005 13:13:33 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: marcelo.tosatti@cyclades.com, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH 2.4] SIOCSIFNAME wildcard support (re-resend) Message-Id: <20050216131333.502234ad.davem@davemloft.net> In-Reply-To: <20050209002747.GA9792@bougret.hpl.hp.com> References: <20050209002747.GA9792@bougret.hpl.hp.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 240 Lines: 7 On Tue, 8 Feb 2005 16:27:47 -0800 Jean Tourrilhes wrote: > Just to make sure everybody seen it twice... Applied, thanks for being so patient as I was processing my huge networking patch backlog after moving last weekend. From jt@hpl.hp.com Wed Feb 16 13:24:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 13:24:22 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GLOI30030111 for ; Wed, 16 Feb 2005 13:24:19 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 7A1F01C032E5; Wed, 16 Feb 2005 13:24:18 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA19983; Wed, 16 Feb 2005 13:27:03 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1D1Weg-0004FI-00; Wed, 16 Feb 2005 13:24:18 -0800 Date: Wed, 16 Feb 2005 13:24:18 -0800 To: "David S. Miller" Cc: marcelo.tosatti@cyclades.com, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH 2.4] SIOCSIFNAME wildcard support (re-resend) Message-ID: <20050216212418.GA16315@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20050209002747.GA9792@bougret.hpl.hp.com> <20050216131333.502234ad.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050216131333.502234ad.davem@davemloft.net> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 385 Lines: 13 On Wed, Feb 16, 2005 at 01:13:33PM -0800, David S. Miller wrote: > On Tue, 8 Feb 2005 16:27:47 -0800 > Jean Tourrilhes wrote: > > > Just to make sure everybody seen it twice... > > Applied, thanks for being so patient as I was processing > my huge networking patch backlog after moving last weekend. Don't worry, people complain about me being so slow ;-) Jean From jmoyer@redhat.com Wed Feb 16 14:07:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 14:07:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GM7IHZ032403 for ; Wed, 16 Feb 2005 14:07:21 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1GM7HcJ025576; Wed, 16 Feb 2005 17:07:17 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1GM7BO05482; Wed, 16 Feb 2005 17:07:12 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j1GM7BZg006788; Wed, 16 Feb 2005 17:07:11 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j1GM7F2e024725; Wed, 16 Feb 2005 17:07:16 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j1GM7ARV024716; Wed, 16 Feb 2005 17:07:11 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.50181.990040.174776@segfault.boston.redhat.com> Date: Wed, 16 Feb 2005 17:07:01 -0500 To: Matt Mackall Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI In-Reply-To: <20050216050722.GC3358@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 1255 Lines: 32 ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: mpm> On Tue, Feb 15, 2005 at 05:49:50PM -0500, Jeff Moyer wrote: >> ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall adds: >> [snip] >> >> Okay, I've only taken a quick glance at this, but I don't quite understand >> why it's safe to take out the check for the per-cpu queue. Realize that an >> interrupt may have been serviced on another processor, and a NAPI poll may >> have been scheduled there. mpm> Because dev->np->poll_lock now serializes all access to ->poll (when mpm> netpoll is enabled on said device). >> Also, could you use the -p flag to diff when you generate your next patch? >> It makes it *much* easier to review. mpm> Hmm, somehow my QUILT_DIFF_OPTS got lost, thanks. mpm> I've just now recovered my SMP+NAPI box, so I can take a stab at mpm> actually testing this shortly. I put together a patch against our kernel tree which implements essentially the same logic as your patch, and it works great: I was able to reproduce the bug without the patch, and the patched kernel is running just fine. Let me know when you have another version of your patch, and I will happily test it in my environment. Thanks, Jeff From tgraf@suug.ch Wed Feb 16 14:30:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 14:30:27 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GMULpe001282 for ; Wed, 16 Feb 2005 14:30:22 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 0E45BF; Wed, 16 Feb 2005 23:29:56 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id D8DC51C0EA; Wed, 16 Feb 2005 23:30:38 +0100 (CET) Date: Wed, 16 Feb 2005 23:30:38 +0100 From: Thomas Graf To: Pablo Neira Cc: Harald Welte , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [RFC] string matching based packet classification/filtering Message-ID: <20050216223038.GQ31837@postel.suug.ch> References: <20050215203211.GL31837@postel.suug.ch> <42126C9B.5060406@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42126C9B.5060406@eurodev.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 956 Lines: 35 > Actually I wanted to contact Harald after this friday, once I'm done > with my exams. I'd like to merge my work with his libqsearch hackings > that were about to be finished. Thinking about it, we can use the architecture to implement a regular expression match. The pattern would consist of an array of tokens in the form of: struct regexp_token { __u8 type; __u8 recur; __u8 value; __u8 unused; }; where type would be - specific character (must match `value') - wildcard - digit - xdigit - alpha ... and recur - 1 - 0..1 - 0..n - 1..0 The matching algorithm would parse the array as a finite automation eating up byte by byte in the text. I think it would be efficient enough, easy to implement, not too error prone and powerful enough for most needs but we can discuss this in more details once libqsearch is ready. It would be one step closer to the increasing need for application level based filtering and classification. From davem@davemloft.net Wed Feb 16 15:05:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 15:05:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GN5bjA005772 for ; Wed, 16 Feb 2005 15:05:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1YBp-0005az-00; Wed, 16 Feb 2005 15:02:37 -0800 Date: Wed, 16 Feb 2005 15:02:36 -0800 From: "David S. Miller" To: Matt Mackall Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-Id: <20050216150236.61ca5faf.davem@davemloft.net> In-Reply-To: <20050216050722.GC3358@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 697 Lines: 19 On Tue, 15 Feb 2005 21:07:22 -0800 Matt Mackall wrote: > Because dev->np->poll_lock now serializes all access to ->poll (when > netpoll is enabled on said device). I think there is still a problem. Sure, we won't recurse into ->poll(), but instead we'll loop forever in netpoll_send_skb() in this case when netif_queue_stopped() is true. We can't get into the ->poll() routine, so the TX queue can't make forward progress, yet we keep looping to the "repeat" label over and over again. So we've replaced a crash via ->poll() re-entry with a deadlock in netpoll_send_skb() :-) I also think that taking a global spinlock for every ->poll() call is a huge price to pay on SMP. From oxymoron@waste.org Wed Feb 16 15:44:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 15:44:22 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GNiGtH007450 for ; Wed, 16 Feb 2005 15:44:17 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GNi6H1025815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2005 17:44:06 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j1GNi6Y8025812; Wed, 16 Feb 2005 17:44:06 -0600 Date: Wed, 16 Feb 2005 15:44:06 -0800 From: Matt Mackall To: "David S. Miller" Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050216234406.GA3120@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> <20050216150236.61ca5faf.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050216150236.61ca5faf.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1739 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: 1421 Lines: 41 On Wed, Feb 16, 2005 at 03:02:36PM -0800, David S. Miller wrote: > On Tue, 15 Feb 2005 21:07:22 -0800 > Matt Mackall wrote: > > > Because dev->np->poll_lock now serializes all access to ->poll (when > > netpoll is enabled on said device). > > I think there is still a problem. > > Sure, we won't recurse into ->poll(), but instead we'll loop forever > in netpoll_send_skb() in this case when netif_queue_stopped() is true. > We can't get into the ->poll() routine, so the TX queue can't make > forward progress, yet we keep looping to the "repeat" label over > and over again. I'm not distinguishing between recursion and race with another CPU yet. Hrmm. > So we've replaced a crash via ->poll() re-entry with a deadlock > in netpoll_send_skb() :-) > > I also think that taking a global spinlock for every ->poll() > call is a huge price to pay on SMP. Ok. We've got a few cases: 1) recursion on cpu1 2) netpoll on cpu1 starts after softirq ->poll on cpu2 3) netpoll on cpu1 starts before softirq ->poll on cpu2 We could do lock-free recursion detection with: dev->np->poll_owner = smp_processor_id(). This can replace the suggested np->poll_flag. This also helps with case 2 where I'm currently doing trylock in netpoll. But this doesn't help with case 3, and a solution that isn't the equivalent of a spinlock doesn't jump out at me. -- Mathematics is the supreme nostalgia of our time. From davem@davemloft.net Wed Feb 16 15:57:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 15:57:09 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GNv5xI008428 for ; Wed, 16 Feb 2005 15:57:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1Yzf-0005o9-00; Wed, 16 Feb 2005 15:54:07 -0800 Date: Wed, 16 Feb 2005 15:54:07 -0800 From: "David S. Miller" To: Matt Mackall Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-Id: <20050216155407.3dbcd9d6.davem@davemloft.net> In-Reply-To: <20050216234406.GA3120@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> <20050216150236.61ca5faf.davem@davemloft.net> <20050216234406.GA3120@waste.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 576 Lines: 17 On Wed, 16 Feb 2005 15:44:06 -0800 Matt Mackall wrote: > Ok. We've got a few cases: > > 1) recursion on cpu1 If you hit this case, and therefore can't re-enter into ->poll(), you must drop the packet or so something else if netif_queue_stopped() since netpoll has no means by which to cause the TX queue to make forward progress. Do you at least agree with this? Perhaps you can create a "pending netpoll() packet" queue so that you don't have to drop the SKB in this case. Make the queue get processed via softint processing. I think this will work. From oxymoron@waste.org Wed Feb 16 16:16:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:16:08 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0G3Sk009958 for ; Wed, 16 Feb 2005 16:16:04 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1H0Fv0M028660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2005 18:15:57 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j1H0FuaN028657; Wed, 16 Feb 2005 18:15:56 -0600 Date: Wed, 16 Feb 2005 16:15:56 -0800 From: Matt Mackall To: "David S. Miller" Cc: jmoyer@redhat.com, netdev@oss.sgi.com Subject: Re: serious netpoll bug w/NAPI Message-ID: <20050217001556.GB3120@waste.org> References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org> <20050216150236.61ca5faf.davem@davemloft.net> <20050216234406.GA3120@waste.org> <20050216155407.3dbcd9d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050216155407.3dbcd9d6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1741 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: 1147 Lines: 34 On Wed, Feb 16, 2005 at 03:54:07PM -0800, David S. Miller wrote: > On Wed, 16 Feb 2005 15:44:06 -0800 > Matt Mackall wrote: > > > Ok. We've got a few cases: > > > > 1) recursion on cpu1 > > If you hit this case, and therefore can't re-enter into ->poll(), > you must drop the packet or so something else if netif_queue_stopped() > since netpoll has no means by which to cause the TX queue to make > forward progress. > > Do you at least agree with this? Yes. > Perhaps you can create a "pending netpoll() packet" queue so that > you don't have to drop the SKB in this case. Make the queue get > processed via softint processing. I think this will work. This part needs more thought. For kgdb-over-ethernet and netdump, the box is stopped here - if we can't poll, we're sunk. But then, neither of those can reasonably be expected to work from inside the thing they're debugging. Panicking is probably appropriate here. For netconsole, delayed processing may be acceptable, but then there are out of order delivery issues and quite a bit of additional complexity.. -- Mathematics is the supreme nostalgia of our time. From jdmason@us.ibm.com Wed Feb 16 16:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:27:49 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0RaQl014257 for ; Wed, 16 Feb 2005 16:27:43 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1H0RULg008368 for ; Wed, 16 Feb 2005 19:27:30 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1H0RUMx113490 for ; Wed, 16 Feb 2005 17:27:30 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RTZi032533 for ; Wed, 16 Feb 2005 17:27:29 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RTVR032521; Wed, 16 Feb 2005 17:27:29 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: [PATCH 1/3] r8169: tx checksuming default enablement Date: Wed, 16 Feb 2005 18:23:40 -0600 User-Agent: KMail/1.7.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: <200502161823.40109.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 563 Lines: 17 Trivial enablement of transmit checksumming by default. Originally sent on 10/28/04. Applies cleanly to linux-2.6.11-rc2-mm2 version of the driver. Signed-off-by: Jon Mason --- drivers/net/r8169.c.orig 2005-01-11 17:05:58.000000000 -0600 +++ drivers/net/r8169.c 2005-02-16 17:16:19.000000000 -0600 @@ -1341,6 +1341,8 @@ rtl8169_init_one(struct pci_dev *pdev, c dev->poll_controller = rtl8169_netpoll; #endif + dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG; + tp->intr_mask = 0xffff; tp->pci_dev = pdev; tp->mmio_addr = ioaddr; From jdmason@us.ibm.com Wed Feb 16 16:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:27:49 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0RcxQ014258 for ; Wed, 16 Feb 2005 16:27:43 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1H0RXua350270 for ; Wed, 16 Feb 2005 19:27:33 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1H0RW0Z260650 for ; Wed, 16 Feb 2005 17:27:32 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RW5D032618 for ; Wed, 16 Feb 2005 17:27:32 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RW0a032600; Wed, 16 Feb 2005 17:27:32 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: [PATCH 2/3] r8169: code clean-up Date: Wed, 16 Feb 2005 18:23:43 -0600 User-Agent: KMail/1.7.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: <200502161823.43562.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3086 Lines: 90 This patch removes netif_poll_disable if NAPI is not enabled (otherwise adapter will hang while changing MTUs). This patch also fixes a possible skb alignment overrun, and fixes the rx skb allocation error logging. It also removes an unnecessary define, adds a link down notification, and cleans up some comments. It is all pretty trivial, but let me know if this is too much for one patch. Tested on amd64 (and very lightly tested on x86). Applies cleanly to linux-2.6.11-rc2-mm2 version of the driver. Signed-off-by: Jon Mason --- drivers/net/r8169.c.orig 2005-02-16 17:16:19.000000000 -0600 +++ drivers/net/r8169.c 2005-02-16 17:17:40.000000000 -0600 @@ -84,10 +84,12 @@ VERSION 1.6LK <2004/04/14> #define rtl8169_rx_skb netif_receive_skb #define rtl8169_rx_hwaccel_skb vlan_hwaccel_rx #define rtl8169_rx_quota(count, quota) min(count, quota) +#define netif_poll_disable(dev) netif_poll_disable(dev) #else #define rtl8169_rx_skb netif_rx #define rtl8169_rx_hwaccel_skb vlan_hwaccel_receive_skb #define rtl8169_rx_quota(count, quota) count +#define netif_poll_disable(dev) #endif /* media options */ @@ -102,11 +104,9 @@ static int max_interrupt_work = 20; The RTL chips use a 64 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 32; -/* MAC address length*/ +/* MAC address length */ #define MAC_ADDR_LEN 6 -#define TX_FIFO_THRESH 256 /* In bytes */ - #define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ @@ -521,8 +521,10 @@ static void rtl8169_check_link_status(st if (tp->link_ok(ioaddr)) { netif_carrier_on(dev); printk(KERN_INFO PFX "%s: link up\n", dev->name); - } else + } else { netif_carrier_off(dev); + printk(KERN_INFO PFX "%s: link down\n", dev->name); + } spin_unlock_irqrestore(&tp->lock, flags); } @@ -1549,10 +1551,10 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); - // For gigabit rtl8169, MTU + header + CRC + VLAN + /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); - // Set Rx Config register + /* Set Rx Config register */ i = rtl8169_rx_config | (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); RTL_W32(RxConfig, i); @@ -1659,11 +1661,11 @@ static int rtl8169_alloc_rx_skb(struct p dma_addr_t mapping; int ret = 0; - skb = dev_alloc_skb(rx_buf_sz); + skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); if (!skb) goto err_out; - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); *sk_buff = skb; mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, @@ -2189,7 +2191,7 @@ rtl8169_rx_interrupt(struct net_device * tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta < 0) { + if (delta < 1 && count) { printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); delta = 0; } From jdmason@us.ibm.com Wed Feb 16 16:27:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:27:50 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0Rh9H014261 for ; Wed, 16 Feb 2005 16:27:43 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1H0Rcua086584 for ; Wed, 16 Feb 2005 19:27:38 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1H0Rb0Z267656 for ; Wed, 16 Feb 2005 17:27:37 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RbaT025156 for ; Wed, 16 Feb 2005 17:27:37 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1H0RbAb025146; Wed, 16 Feb 2005 17:27:37 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: [PATCH 3/3] r8169: Jumbo Frames maximum size increase Date: Wed, 16 Feb 2005 18:23:48 -0600 User-Agent: KMail/1.7.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: <200502161823.48769.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8184 Lines: 251 This patch increases the maximum MTU from 7200 to 9500. It will actually work much higher than that, but will start to drop packets after a while. The amount of changes necessary for this small increase is because of the unusual behavior of the adapter (which is undocumented in the adapter spec). For rx_buf_sz > 8191, the adapter will partition the frames into multiple descriptors. This in itself is not that difficult to handle, however the point on which it partitions them varies dependent on the rx_buf_sz. After a bit of trial-and-error, I discovered the formula to be (tp->rx_buf_sz - 8192) & 0xfff8. I have tested it upto MTU 16000 and it works for all MTUs. That being said, there is an obvious performance hit associated with copying all of the parts of the skb into a unified skb. Therefore, I would recommend against MTUs > 8169 (the point at which the descriptor partitioning begins). Tested on amd64 (and very lightly tested on x86). Applies cleanly to linux-2.6.11-rc2-mm2 version of the driver. Signed-off-by: Jon Mason --- drivers/net/r8169.c.orig 2005-02-16 17:21:07.000000000 -0600 +++ drivers/net/r8169.c 2005-02-16 17:23:46.000000000 -0600 @@ -111,8 +111,9 @@ static int multicast_filter_limit = 32; #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ +#define LargeSendETT 0x35 #define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */ -#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */ +#define SafeMtu 0x251C /* ... actually life sucks beyond ~9500 */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define R8169_REGS_SIZE 256 @@ -404,6 +405,8 @@ struct rtl8169_private { unsigned int (*phy_reset_pending)(void __iomem *); unsigned int (*link_ok)(void __iomem *); struct work_struct task; + struct sk_buff *new_skb; + u32 desc_part; }; MODULE_AUTHOR("Realtek"); @@ -1462,6 +1465,24 @@ static void rtl8169_set_rxbufsize(struct unsigned int mtu = dev->mtu; tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE; + + /* + * For rx_buf_sz > 8191, the adapter will carve-up the frames into + * multiple descriptors, based on the formula + * (tp->rx_buf_sz - 8192) & 0xfff8. For MTU 8225, the packets will be + * destributed across 258 rx descriptors (which will stomp on all the + * descriptors in a 64 entry ring). We are better off overstating + * rx_buf_sz to 9240, so that it will be a maximum of 9 descriptors. + * + * Also, Nasty problem where if the rx_buf_sz is between 8192 and 8224 + * the adapter will go crazy and the system will crash. To workaround + * this issue, the driver is adding additional space to the rx_buf_sz. + */ + if ((tp->rx_buf_sz > 8191) && (tp->rx_buf_sz < 9240)) + tp->rx_buf_sz = 9240; + + tp->desc_part = (tp->rx_buf_sz - 8192) & 0xfff8; + } static int rtl8169_open(struct net_device *dev) @@ -1549,8 +1570,12 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(Cfg9346, Cfg9346_Unlock); RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); - RTL_W8(EarlyTxThres, EarlyTxThld); + if (dev->mtu < 7400) + RTL_W8(EarlyTxThres, EarlyTxThld); + else + RTL_W8(EarlyTxThres, LargeSendETT); + /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); @@ -1627,7 +1652,8 @@ out: static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { desc->addr = 0x0badbadbadbadbadull; - desc->opts1 &= ~cpu_to_le32(DescOwn | RsvdMask); + desc->opts1 &= cpu_to_le32(RingEnd); + desc->opts2 = 0; } static void rtl8169_free_rx_skb(struct rtl8169_private *tp, @@ -1644,7 +1670,9 @@ static void rtl8169_free_rx_skb(struct r static inline void rtl8169_return_to_asic(struct RxDesc *desc, int rx_buf_sz) { + desc->opts1 &= cpu_to_le32(RingEnd); desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + desc->opts2 = 0; } static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping, @@ -1652,6 +1680,7 @@ static inline void rtl8169_give_to_asic( { desc->addr = cpu_to_le64(mapping); desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + desc->opts2 = 0; } static int rtl8169_alloc_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff, @@ -2098,24 +2127,52 @@ static inline void rtl8169_rx_csum(struc skb->ip_summed = CHECKSUM_NONE; } -static inline int rtl8169_try_rx_copy(struct sk_buff **sk_buff, int pkt_size, - struct RxDesc *desc, int rx_buf_sz) +static inline int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, + struct RxDesc *desc, struct rtl8169_private *tp) { - int ret = -1; - - if (pkt_size < rx_copybreak) { - struct sk_buff *skb; + u32 status = le32_to_cpu(desc->opts1); + + if ((pkt_size > rx_copybreak) && + ((status & FirstFrag) && (status & LastFrag))) + return -1; - skb = dev_alloc_skb(pkt_size + 2); + if (status & FirstFrag) { + struct sk_buff *skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (skb) { - skb_reserve(skb, 2); - eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); - *sk_buff = skb; - rtl8169_return_to_asic(desc, rx_buf_sz); - ret = 0; + skb_reserve(skb, NET_IP_ALIGN); + if (pkt_size > rx_copybreak) { + memcpy(skb->data, sk_buff[0]->tail, + tp->desc_part); + skb_put(skb, tp->desc_part); + } else { + memcpy(skb->data, sk_buff[0]->tail, pkt_size); + skb_put(skb, pkt_size); + } + } else + printk(KERN_INFO "no rx skb allocated\n"); + + tp->new_skb = skb; + } + + if (!(status & FirstFrag) && !(status & LastFrag) && tp->new_skb) { + memcpy(tp->new_skb->tail, sk_buff[0]->tail, tp->desc_part); + skb_put(tp->new_skb, tp->desc_part); + } + + if (status & LastFrag) { + if (pkt_size > rx_copybreak && tp->new_skb) { + memcpy(tp->new_skb->tail, sk_buff[0]->tail, + pkt_size - tp->new_skb->len); + + skb_put(tp->new_skb, pkt_size - tp->new_skb->len); } + + *sk_buff = tp->new_skb; } - return ret; + + rtl8169_return_to_asic(desc, tp->rx_buf_sz); + + return 0; } static int @@ -2142,8 +2199,15 @@ rtl8169_rx_interrupt(struct net_device * if (status & DescOwn) break; - if (status & RxRES) { - printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); + + /* + * RxRWT is acceptable if Jumbo Frames are enabled. + * Unfortunately, there is no way of disabling this error in + * that case. + */ + if (status & RxRES && !(status & RxRWT)) { + printk(KERN_INFO "%s: Rx ERROR %x\n", dev->name, + status); tp->stats.rx_errors++; if (status & (RxRWT | RxRUNT)) tp->stats.rx_length_errors++; @@ -2152,37 +2216,38 @@ rtl8169_rx_interrupt(struct net_device * } else { struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; - int pkt_size = (status & 0x00001FFF) - 4; + int pkt_size = (status & 0x00003FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; - rtl8169_rx_csum(skb, desc); - pci_dma_sync_single_for_cpu(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); - - if (rtl8169_try_rx_copy(&skb, pkt_size, desc, - tp->rx_buf_sz)) { + + rtl8169_rx_csum(skb, desc); + + if (rtl8169_rx_copy(&skb, pkt_size, desc, tp)) { pci_action = pci_unmap_single; tp->Rx_skbuff[entry] = NULL; + skb_put(skb, pkt_size); } pci_action(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); - skb->dev = dev; - skb_put(skb, pkt_size); - skb->protocol = eth_type_trans(skb, dev); - - if (rtl8169_rx_vlan_skb(tp, desc, skb) < 0) - rtl8169_rx_skb(skb); - - dev->last_rx = jiffies; - tp->stats.rx_bytes += pkt_size; - tp->stats.rx_packets++; + if (skb && (status & LastFrag)) { + skb->dev = dev; + skb->protocol = eth_type_trans(skb, dev); + + if (rtl8169_rx_vlan_skb(tp, desc, skb) < 0) + rtl8169_rx_skb(skb); + + dev->last_rx = jiffies; + tp->stats.rx_bytes += pkt_size; + tp->stats.rx_packets++; + } } - + cur_rx++; rx_left--; } From shivakumar.chetan@gmail.com Wed Feb 16 16:32:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:32:40 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0WZ9k015978 for ; Wed, 16 Feb 2005 16:32:36 -0800 Received: by wproxy.gmail.com with SMTP id 68so231253wra for ; Wed, 16 Feb 2005 16:32:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nfvlNy9Vce/IgGnMR4aLDJtLXUnUZlcx3bh4v83o9JDyRd+9Hclt8TQxoh2uJ2lC274fkGzlMou7ov9tonUFothxh0mtDbApaBA2VDk/SpnnyUmHUHPj1knu1/Uc/43fpl/+51MDHYOEQ685aF/JvAmL3QEGLho5d2dBqza6BPc= Received: by 10.54.14.22 with SMTP id 22mr47983wrn; Wed, 16 Feb 2005 16:32:30 -0800 (PST) Received: by 10.54.39.8 with HTTP; Wed, 16 Feb 2005 16:32:29 -0800 (PST) Message-ID: <17fe83cb05021616323c3dab@mail.gmail.com> Date: Thu, 17 Feb 2005 06:02:29 +0530 From: Chetan Kumar Reply-To: Chetan Kumar To: netdev@oss.sgi.com Subject: Some query on ingress policing In-Reply-To: <17fe83cb0502160349a4190d1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <17fe83cb0502160349a4190d1@mail.gmail.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shivakumar.chetan@gmail.com Precedence: bulk X-list: netdev Content-Length: 364 Lines: 8 Hi List, It is really appreciable, if one of you can clarify me on this issue. I was going thro the packet journey thro the network stack in Linux. Now if I want enable ingress policing, it looks like packet classification and policing should happen in netif_rx (i.e in the interrupt context) before packet is queued on to the input queue am I missing something. From random@72616e646f6d20323030342d30342d31360a.nosense.org Wed Feb 16 16:55:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 16:55:15 -0800 (PST) Received: from ubu.nosense.org (252.cust6.sa.dsl.ozemail.com.au [210.84.229.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H0tAs2017466 for ; Wed, 16 Feb 2005 16:55:10 -0800 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id C5A2062AAE for ; Thu, 17 Feb 2005 11:25:02 +1030 (CST) Date: Thu, 17 Feb 2005 11:25:02 +1030 From: Mark Smith To: netdev@oss.sgi.com Subject: [2.6.10] Known bug ? TCP Ack "storm" Message-Id: <20050217112502.06861a40.random@72616e646f6d20323030342d30342d31360a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 4401 Lines: 61 Hi, On a couple of occasions (yesterday, just now, and a few weeks ago), I've had what I'll call a TCP ack "storm". I'm not sure about the other occasions, however, today, it occured while I was accessing the Cisco.com web site. It persists for quite a while, and seems to take a few minutes to disappear, although it eventually stopping might have been because I closed my browser down. Here is are 30 lines of output from tethereal. I have a capture file with around 180 examples, there were a lot more than that problably in the 1000s : -- 1 0.000000 198.133.219.25 -> 210.84.229.252 TCP www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 2 0.000167 210.84.229.252 -> 198.133.219.25 TCP [TCP ACKed lost segment] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 3 0.211857 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#1] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 4 0.211996 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#1] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 5 0.424007 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#2] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 6 0.424151 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#2] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 7 0.635641 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#3] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 8 0.635766 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#3] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 9 0.848265 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#4] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 10 0.848396 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#4] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 11 1.062668 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#5] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 12 1.062800 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#5] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 13 1.280399 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#6] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 14 1.280528 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#6] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 15 1.490076 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#7] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 16 1.490208 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#7] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 17 1.702436 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#8] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 18 1.702567 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#8] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 19 1.914104 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#9] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 20 1.914231 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#9] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 21 2.128192 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#10] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 22 2.128321 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#10] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 23 2.349868 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#11] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 24 2.350008 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#11] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 25 2.563787 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#12] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 26 2.563915 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#12] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 27 2.776169 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#13] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 28 2.776293 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#13] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 29 2.987558 198.133.219.25 -> 210.84.229.252 TCP [TCP Dup ACK 1#14] www > 52065 [ACK] Seq=0 Ack=0 Win=65340 Len=0 30 2.987708 210.84.229.252 -> 198.133.219.25 TCP [TCP Dup ACK 2#14] 52065 > www [ACK] Seq=0 Ack=1267 Win=20048 Len=0 -- I can provide the packet trace file if required. Download it from the following URL. I had to fool Geocities to allow me to upload it, so it isn't a PDF, it's just a bzip2'ed tcpdump packet trace file. http://au.geocities.com/markzzzsmith/tcpackstorm.pdf Thanks, Mark. -- "This signature intentionally left blank." From pablo@eurodev.net Wed Feb 16 17:01:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 17:01:06 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H111lW018135 for ; Wed, 16 Feb 2005 17:01:02 -0800 Received: from eurodev.net ([85.136.98.240]) by smtp09.retemail.es (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050217010049.MSTQ982.smtp09.retemail.es@eurodev.net>; Thu, 17 Feb 2005 02:00:49 +0100 Message-ID: <4213ECC9.30502@eurodev.net> Date: Thu, 17 Feb 2005 02:00:57 +0100 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, Netfilter Development Mailinglist , Harald Welte Subject: Re: [RFC] string matching based packet classification/filtering References: <20050215203211.GL31837@postel.suug.ch> <42126C9B.5060406@eurodev.net> <20050216223038.GQ31837@postel.suug.ch> In-Reply-To: <20050216223038.GQ31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1228 Lines: 50 Thomas Graf wrote: >>Actually I wanted to contact Harald after this friday, once I'm done >>with my exams. I'd like to merge my work with his libqsearch hackings >>that were about to be finished. >> >> > >Thinking about it, we can use the architecture to implement a regular >expression match. The pattern would consist of an array of tokens >in the form of: > >struct regexp_token >{ > __u8 type; > __u8 recur; > __u8 value; > __u8 unused; >}; > > Yes, this is a good idea. This could be useful to match things like interrogation marks or asterisks that are usually used as wildcard. >where type would be > - specific character (must match `value') > - wildcard > - digit > - xdigit > - alpha ... > >and recur > - 1 > - 0..1 > - 0..n > - 1..0 > >The matching algorithm would parse the array as a finite automation >eating up byte by byte in the text. > Looks good but Boyer-Moore algorithm doesn't need this at all. BM doesn't support wildcards like '*' because of the shiftings that it uses to look for matches. This issue together with memory consumption are two limitations that we have to live with if we want to use BM. Anyway I think it's worth it because we can perform search in O(n/m). -- Pablo From kaber@trash.net Wed Feb 16 22:22:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Feb 2005 22:22:39 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H6MVWu004334 for ; Wed, 16 Feb 2005 22:22:32 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1f3P-0003rG-SQ; Thu, 17 Feb 2005 07:22:23 +0100 Message-ID: <4214381F.5020507@trash.net> Date: Thu, 17 Feb 2005 07:22:23 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev , Herbert Xu Subject: [XFRM]: Always reroute in tunnel mode Content-Type: multipart/mixed; boundary="------------010806070907080302070104" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3493 Lines: 114 This is a multi-part message in MIME format. --------------010806070907080302070104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see Changeset comment for a description, patch is based on your 2.6.12 tree. Regards Patrick --------------010806070907080302070104 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/17 07:10:03+01:00 kaber@coreworks.de # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_policy.c # 2005/02/17 07:09:55+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_policy.c # 2005/02/17 07:09:55+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2005-02-17 07:16:40 +01:00 +++ b/net/ipv4/xfrm4_policy.c 2005-02-17 07:16:40 +01:00 @@ -59,6 +59,7 @@ int err; int header_len = 0; int trailer_len = 0; + int tunnel = 0; dst = dst_prev = NULL; @@ -81,12 +82,13 @@ if (xfrm[i]->props.mode) { remote = xfrm[i]->id.daddr.a4; local = xfrm[i]->props.saddr.a4; + tunnel = 1; } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; } - if (remote != fl->fl4_dst) { + if (tunnel) { struct flowi fl_tunnel = { .nl_u = { .ip4_u = { .daddr = remote, .saddr = local } diff -Nru a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c --- a/net/ipv6/xfrm6_policy.c 2005-02-17 07:16:40 +01:00 +++ b/net/ipv6/xfrm6_policy.c 2005-02-17 07:16:40 +01:00 @@ -76,6 +76,7 @@ int err = 0; int header_len = 0; int trailer_len = 0; + int tunnel = 0; dst = dst_prev = NULL; @@ -98,12 +99,13 @@ if (xfrm[i]->props.mode) { remote = (struct in6_addr*)&xfrm[i]->id.daddr; local = (struct in6_addr*)&xfrm[i]->props.saddr; + tunnel = 1; } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; } - if (!ipv6_addr_equal(remote, &fl->fl6_dst)) { + if (tunnel) { struct flowi fl_tunnel; memset(&fl_tunnel, 0, sizeof(fl_tunnel)); --------------010806070907080302070104-- From herbert@13thfloor.at Thu Feb 17 01:32:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 01:32:39 -0800 (PST) Received: from mail.13thfloor.at (MAIL.13thfloor.at [212.16.62.51]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H9WWHo016329 for ; Thu, 17 Feb 2005 01:32:33 -0800 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 3934E17024A; Thu, 17 Feb 2005 10:32:30 +0100 (CET) Date: Thu, 17 Feb 2005 10:32:30 +0100 From: Herbert Poetzl To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [Patch] passcred cleanup in struct socket Message-ID: <20050217093230.GA15066@mail.13thfloor.at> Mail-Followup-To: Andrew Morton , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: netdev Content-Length: 3768 Lines: 117 struct socket uses a 'bool' (unsigned char) to 'flag' the pass-credential option for sockets (which can be easily replaced by a flag) best, Herbert diff -NurpP --minimal linux-2.6.11-rc4/include/linux/net.h linux-2.6.11-rc4-sock/include/linux/net.h --- linux-2.6.11-rc4/include/linux/net.h 2005-02-13 17:17:06 +0100 +++ linux-2.6.11-rc4-sock/include/linux/net.h 2005-02-17 09:47:44 +0100 @@ -61,6 +61,7 @@ typedef enum { #define SOCK_ASYNC_NOSPACE 0 #define SOCK_ASYNC_WAITDATA 1 #define SOCK_NOSPACE 2 +#define SOCK_PASSCRED 3 #ifndef ARCH_HAS_SOCKET_TYPES /** sock_type - Socket types @@ -111,7 +112,6 @@ struct socket { struct sock *sk; wait_queue_head_t wait; short type; - unsigned char passcred; }; struct vm_area_struct; diff -NurpP --minimal linux-2.6.11-rc4/include/net/scm.h linux-2.6.11-rc4-sock/include/net/scm.h --- linux-2.6.11-rc4/include/net/scm.h 2004-08-14 12:55:32 +0200 +++ linux-2.6.11-rc4-sock/include/net/scm.h 2005-02-17 09:49:42 +0100 @@ -51,13 +51,13 @@ static __inline__ void scm_recv(struct s { if (!msg->msg_control) { - if (sock->passcred || scm->fp) + if (test_bit(SOCK_PASSCRED, &sock->flags) || scm->fp) msg->msg_flags |= MSG_CTRUNC; scm_destroy(scm); return; } - if (sock->passcred) + if (test_bit(SOCK_PASSCRED, &sock->flags)) put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm->creds), &scm->creds); if (!scm->fp) diff -NurpP --minimal linux-2.6.11-rc4/net/core/sock.c linux-2.6.11-rc4-sock/net/core/sock.c --- linux-2.6.11-rc4/net/core/sock.c 2005-02-13 17:17:18 +0100 +++ linux-2.6.11-rc4-sock/net/core/sock.c 2005-02-17 09:49:42 +0100 @@ -333,7 +333,10 @@ int sock_setsockopt(struct socket *sock, break; case SO_PASSCRED: - sock->passcred = valbool; + if (valbool) + set_bit(SOCK_PASSCRED, &sock->flags); + else + clear_bit(SOCK_PASSCRED, &sock->flags); break; case SO_TIMESTAMP: @@ -557,7 +560,7 @@ int sock_getsockopt(struct socket *sock, break; case SO_PASSCRED: - v.val = sock->passcred; + v.val = test_bit(SOCK_PASSCRED, &sock->flags) ? 1 : 0; break; case SO_PEERCRED: diff -NurpP --minimal linux-2.6.11-rc4/net/socket.c linux-2.6.11-rc4-sock/net/socket.c --- linux-2.6.11-rc4/net/socket.c 2005-02-13 17:17:19 +0100 +++ linux-2.6.11-rc4-sock/net/socket.c 2005-02-17 09:34:41 +0100 @@ -287,7 +287,7 @@ static struct inode *sock_alloc_inode(st ei->socket.ops = NULL; ei->socket.sk = NULL; ei->socket.file = NULL; - ei->socket.passcred = 0; + ei->socket.flags = 0; return &ei->vfs_inode; } diff -NurpP --minimal linux-2.6.11-rc4/net/unix/af_unix.c linux-2.6.11-rc4-sock/net/unix/af_unix.c --- linux-2.6.11-rc4/net/unix/af_unix.c 2005-02-13 17:17:19 +0100 +++ linux-2.6.11-rc4-sock/net/unix/af_unix.c 2005-02-17 09:49:42 +0100 @@ -861,8 +861,8 @@ static int unix_dgram_connect(struct soc goto out; alen = err; - if (sock->passcred && !unix_sk(sk)->addr && - (err = unix_autobind(sock)) != 0) + if (test_bit(SOCK_PASSCRED, &sock->flags) && + !unix_sk(sk)->addr && (err = unix_autobind(sock)) != 0) goto out; other=unix_find_other(sunaddr, alen, sock->type, hash, &err); @@ -952,7 +952,8 @@ static int unix_stream_connect(struct so goto out; addr_len = err; - if (sock->passcred && !u->addr && (err = unix_autobind(sock)) != 0) + if (test_bit(SOCK_PASSCRED, &sock->flags) + && !u->addr && (err = unix_autobind(sock)) != 0) goto out; timeo = sock_sndtimeo(sk, flags & O_NONBLOCK); @@ -1286,7 +1287,8 @@ static int unix_dgram_sendmsg(struct kio goto out; } - if (sock->passcred && !u->addr && (err = unix_autobind(sock)) != 0) + if (test_bit(SOCK_PASSCRED, &sock->flags) + && !u->addr && (err = unix_autobind(sock)) != 0) goto out; err = -EMSGSIZE; From junk@toutatis.be Thu Feb 17 02:19:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 02:19:44 -0800 (PST) Received: from toutatis.be (212.68.249.80.brutele.be [212.68.249.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1HAJcBt018961 for ; Thu, 17 Feb 2005 02:19:39 -0800 Received: (qmail 29277 invoked from network); 17 Feb 2005 10:19:29 -0000 Received: from localhost (HELO toutatis.be) (127.0.0.1) by 0 with SMTP; 17 Feb 2005 10:19:29 -0000 From: "junk" To: netdev@oss.sgi.com Subject: skb_clone Date: Thu, 17 Feb 2005 11:19:29 +0100 Message-Id: <20050217101331.M38167@toutatis.be> X-Mailer: Open WebMail 2.32 20040525 X-OriginatingIP: 195.207.101.27 (junk) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: junk@toutatis.be Precedence: bulk X-list: netdev Content-Length: 181 Lines: 8 Hello, i made a clone of a skb i catched with a netfilter hook. Now i want to send that cloned skb on the wire.. what should i do? I tried with dev_queue_xmit without success.. From herbert@gondor.apana.org.au Thu Feb 17 03:37:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 03:38:00 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HBbout024757 for ; Thu, 17 Feb 2005 03:37:51 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1jyE-0005wR-00; Thu, 17 Feb 2005 22:37:22 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1jxm-0002hH-00; Thu, 17 Feb 2005 22:36:54 +1100 Date: Thu, 17 Feb 2005 22:36:54 +1100 To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode Message-ID: <20050217113654.GA10346@gondor.apana.org.au> References: <4214381F.5020507@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214381F.5020507@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1162 Lines: 30 On Thu, Feb 17, 2005 at 07:22:23AM +0100, Patrick McHardy wrote: > > # Tunnel mode packets are rerouted if the tunnel destination > # address is different from the original destination address, > # otherwise the old route is used. This is inconsistent, the > # old route might have been selected for a given output device > # or using routing by tos/fwmark. Always choose a new route > # in tunnel mode. I understand the inconsistency and agree that it should be fixed. However, I think the way you did it has created a new inconsistency. Tunnel mode SAs are not always used to carry subnets. It can also be used for host-to-host configurations where the aim is to protect the IP header. Therefore it would be inconsistent to look up a new route for host-to-host tunnel mode SAs. Perhaps we can simply expand the check to include local as well, i.e., if (local != fl->fl4_src || remote != fl->fl4_dst) { What do you think? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Thu Feb 17 05:30:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 05:31:03 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HDUti9006443 for ; Thu, 17 Feb 2005 05:30:56 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 16849F; Thu, 17 Feb 2005 14:30:31 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 623AB1C0EA; Thu, 17 Feb 2005 14:31:14 +0100 (CET) Date: Thu, 17 Feb 2005 14:31:14 +0100 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, Netfilter Development Mailinglist , Harald Welte Subject: Re: [RFC] string matching based packet classification/filtering Message-ID: <20050217133114.GU31837@postel.suug.ch> References: <20050215203211.GL31837@postel.suug.ch> <42126C9B.5060406@eurodev.net> <20050216223038.GQ31837@postel.suug.ch> <4213ECC9.30502@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4213ECC9.30502@eurodev.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 814 Lines: 15 > >The matching algorithm would parse the array as a finite automation > >eating up byte by byte in the text. > > > > Looks good but Boyer-Moore algorithm doesn't need this at all. BM > doesn't support wildcards like '*' because of the shiftings that it uses > to look for matches. This issue together with memory consumption are two > limitations that we have to live with if we want to use BM. Anyway I > think it's worth it because we can perform search in O(n/m). This would be _additional_ to BM/KMP/naive/finite automata/you name it. The benefit of libqsearch is hide various algorithms behind a single interface, isn't it? It's argueable whether it would make sense to try and rule out bad shifts while parsing a chain of non-wildcard regular expression tokens but I guess that would be over the top. From junk@toutatis.be Thu Feb 17 05:53:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 05:53:27 -0800 (PST) Received: from toutatis.be (212.68.249.80.brutele.be [212.68.249.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1HDrJqC003390 for ; Thu, 17 Feb 2005 05:53:20 -0800 Received: (qmail 25347 invoked from network); 17 Feb 2005 13:53:11 -0000 Received: from localhost (HELO toutatis.be) (127.0.0.1) by 0 with SMTP; 17 Feb 2005 13:53:11 -0000 From: "junk" To: netdev@oss.sgi.com Subject: Re: skb_clone Date: Thu, 17 Feb 2005 14:53:11 +0100 Message-Id: <20050217134407.M46105@toutatis.be> In-Reply-To: <20050217101331.M38167@toutatis.be> References: <20050217101331.M38167@toutatis.be> X-Mailer: Open WebMail 2.32 20040525 X-OriginatingIP: 195.207.101.27 (junk) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: junk@toutatis.be Precedence: bulk X-list: netdev Content-Length: 872 Lines: 27 >Hello, > >i made a clone of a skb i catched with a netfilter hook. > >Now i want to send that cloned skb on the wire.. what should i do? I tried >with dev_queue_xmit without success.. I've been able to transmit my packet.. no more kernel oops but it seems i'm having an alignment problem. Tcpdump tells me "ethertype unknown" on each packet that has been altered by my module. That packet originally comes from "ping", I do not generate it myself, so i guess the ethernet header, IP header, data are correct. It just seems I missed a point before dev_queue_xmit() my skb. I'm having the same problem if I skb_copy() instead of skb_clone() the original skb. Here is a summary of my code: hook_interrupt -> cloning skb to new_skb -> changing new_skb->dev to another interface -> dev_queue_xmit(new_skb); -> return NF_STOLEN for the original skb What am I missing? From jeroens@office.netland.nl Thu Feb 17 06:42:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 06:42:40 -0800 (PST) Received: from services-04.netland.nl (mx1.netland.nl [217.170.32.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HEgXbu020327 for ; Thu, 17 Feb 2005 06:42:34 -0800 Received: from n010095.nbs.netland.nl (fw.office.netland.nl [217.170.32.40]) by services-04.netland.nl (Postfix) with ESMTP id 38B5F5401C for ; Thu, 17 Feb 2005 15:42:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by n010095.nbs.netland.nl (Postfix) with ESMTP id EB354A507 for ; Thu, 17 Feb 2005 15:42:27 +0100 (CET) Received: from n010095.nbs.netland.nl ([127.0.0.1]) by localhost (n010095.nbs.netland.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24802-03 for ; Thu, 17 Feb 2005 15:42:26 +0100 (CET) Received: from [192.168.170.121] (ts2.office.netland.nl [192.168.170.121]) by n010095.nbs.netland.nl (Postfix) with ESMTP id B5722A500; Thu, 17 Feb 2005 15:42:25 +0100 (CET) Subject: Re: 2.6.10 dst cache overflow From: "J. Simonetti" To: Robert Olsson Cc: David Coulson , netdev@oss.sgi.com In-Reply-To: <16915.22671.276946.919243@robur.slu.se> References: <1108550412.3799.81.camel@ts2.office.netland.nl> <42134E22.4030808@davidcoulson.net> <16915.22671.276946.919243@robur.slu.se> Content-Type: text/plain Organization: Netland Internet Services Message-Id: <1108651346.497.10.camel@ts2.office.netland.nl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 17 Feb 2005 15:42:26 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at n010095.nbs.netland.nl X-Virus-Status: Clean X-archive-position: 1754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroens@office.netland.nl Precedence: bulk X-list: netdev Content-Length: 929 Lines: 31 On Wed, 2005-02-16 at 15:28, Robert Olsson wrote: > Hello! > > Very recently here on netdev "Memory leak in 2.6.11-rc1" was discussed > this resulted in: > > > ===== net/ipv4/ip_output.c 1.74 vs edited ===== > > --- 1.74/net/ipv4/ip_output.c 2005-01-25 01:40:10 +01:00 > > +++ edited/net/ipv4/ip_output.c 2005-01-30 18:54:43 +01:00 > > @@ -389,6 +389,7 @@ > > to->priority = from->priority; > > to->protocol = from->protocol; > > to->security = from->security; > > + dst_release(to->dst); > > to->dst = dst_clone(from->dst); > > to->dev = from->dev; > > and a similar patch for ipv6. Should be a start. After reading the thread and doing some research of my own it looks like that is what I'm suffering from. I will try the patch to see if it helps. Thank you for the help. Jeroen Simonetti -- Netland Internet Services http://www.netland.nl Increased knowledge will help you now. Have mate's phone bugged. From shivakumar.chetan@gmail.com Thu Feb 17 09:00:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 09:00:38 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HH0YEG031434 for ; Thu, 17 Feb 2005 09:00:34 -0800 Received: by wproxy.gmail.com with SMTP id 68so358016wra for ; Thu, 17 Feb 2005 09:00:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CUAvvFxbgE0bJblQ+YecAtpjYOg6Xry0360CUXuW2GGkSwKo4Cx/AWXekW4ePjC2ejRotZiqkWPIETKbKh4Y5n8vq8DLN4JHoDFYJ8WCWePBYX78k0Q5i3ZjtrMoPw/TAVZ2J+qt47nKLOSDsfBRJFsLJkSs1KlGGvKdLkXictI= Received: by 10.54.11.73 with SMTP id 73mr121018wrk; Thu, 17 Feb 2005 09:00:28 -0800 (PST) Received: by 10.54.39.8 with HTTP; Thu, 17 Feb 2005 09:00:28 -0800 (PST) Message-ID: <17fe83cb05021709002875e4ad@mail.gmail.com> Date: Thu, 17 Feb 2005 22:30:28 +0530 From: Chetan Kumar Reply-To: Chetan Kumar To: netdev@oss.sgi.com Subject: Ingress policing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shivakumar.chetan@gmail.com Precedence: bulk X-list: netdev Content-Length: 385 Lines: 9 Hi List, It is really appreciable, if one of you can clarify me on this issue. - Hide quoted text - I was going thro the packet journey thro the network stack in Linux. Now if I want enable ingress policing, it looks like packet classification and policing should happen in netif_rx (i.e in the interrupt context) before packet is queued on to the input queue am I missing something. From ganesh.venkatesan@intel.com Thu Feb 17 09:02:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 09:02:20 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HH2DdS031831 for ; Thu, 17 Feb 2005 09:02:14 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1HH22MA008921; Thu, 17 Feb 2005 17:02:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1HH1nm3007602; Thu, 17 Feb 2005 17:02:02 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021709020127771 ; Thu, 17 Feb 2005 09:02:01 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 09:02:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: e1000: driver reboot/kexec bug. Date: Thu, 17 Feb 2005 09:02:00 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E044A1285@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000: driver reboot/kexec bug. Thread-Index: AcUUIvieTxfWny6TR0mU31cX/DLBcQAI/uDAADLG+NA= From: "Venkatesan, Ganesh" To: Cc: , "Chilakala, Mallikarjuna" , X-OriginalArrivalTime: 17 Feb 2005 17:02:01.0688 (UTC) FILETIME=[661FC580:01C51512] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1HH2DdS031831 X-archive-position: 1756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2357 Lines: 70 Hi Eric: Could you send us 'lspci -vvv' output for 3:4.0? Could you also help us with some more information on the platform you are using? Thanks, Ganesh. >-----Original Message----- >From: eric@ebiederm.dsl.xmission.com >[mailto:eric@ebiederm.dsl.xmission.com] On Behalf Of Eric W. Biederman >Sent: Wednesday, February 16, 2005 4:26 AM >To: Chilakala, Mallikarjuna >Cc: jgarzik@pobox.com; netdev >Subject: e1000: driver reboot/kexec bug. > > >When I kexec a new kernel on hardware that includes >some revs of the e1000 (see below for lscpi -n) the >e1000 driver is not able to reinitialize the NIC. I >have seen this in both 2.4.29 and 2.6.10. > >Tracking it down it appears to be some side effect to powering down >the nic. If I remove the pci_set_power_state call in e1000_suspend >or I simply apply the attached patch so I get that affect when >rebooting everything works. pci_enable_device brings the device >up to full power before the driver initialization code does anything >else so I don't have a clue what is really going on but it is. > > >Boot messages on failure: >> Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k1 >> Copyright (c) 1999-2004 Intel Corporation. >> PCI: Enabling device 03:04.0 (0000 -> 0003) >> e1000: 03:04.0: e1000_probe: The EEPROM Checksum Is Not Valid >> PCI: Enabling device 03:04.1 (0000 -> 0003) >> e1000: 03:04.1: e1000_probe: The EEPROM Checksum Is Not Valid > >lspci -n of the problem onboard e1000 NIC. >> 03:04.0 Class 0200: 8086:1079 (rev 03) >> 03:04.1 Class 0200: 8086:1079 (rev 03) > > >Patch which avoids the problem. >diff -uNrX linux-exclude-files linux-2.4.29-kexec-apic-virtwire-on- >shutdownx86_64/drivers/net/e1000/e1000_main.c linux-2.4.29- >kexec7.build.x86_64/drivers/net/e1000/e1000_main.c >--- linux-2.4.29-kexec-apic-virtwire-on- >shutdownx86_64/drivers/net/e1000/e1000_main.c Tue Feb 15 14:17:09 2005 >+++ linux-2.4.29-kexec7.build.x86_64/drivers/net/e1000/e1000_main.c Wed >Feb 16 04:58:18 2005 >@@ -2777,7 +2777,7 @@ > case SYS_POWER_OFF: > while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { > if(pci_dev_driver(pdev) == &e1000_driver) >- e1000_suspend(pdev, 3); >+ e1000_suspend(pdev, (event == SYS_DOWN)?0:3); > } > } > return NOTIFY_DONE; > > >Any help to track down why this is happening so we can apply >a clean fix would be appreciated. > >Eric From ganesh.venkatesan@intel.com Thu Feb 17 09:04:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 09:04:31 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HH4Q3q032574 for ; Thu, 17 Feb 2005 09:04:26 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1HH4Fs4009295; Thu, 17 Feb 2005 17:04:15 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1HH39mi009046; Thu, 17 Feb 2005 17:04:15 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021709041428281 ; Thu, 17 Feb 2005 09:04:14 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 09:04:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: e1000: driver reboot/kexec bug. Date: Thu, 17 Feb 2005 09:04:12 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E044A12A0@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000: driver reboot/kexec bug. Thread-Index: AcUUIvieTxfWny6TR0mU31cX/DLBcQAI/uDAADLG+NAAABfXYA== From: "Venkatesan, Ganesh" To: "Venkatesan, Ganesh" , Cc: , "Chilakala, Mallikarjuna" , X-OriginalArrivalTime: 17 Feb 2005 17:04:14.0790 (UTC) FILETIME=[B5758660:01C51512] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1HH4Q3q032574 X-archive-position: 1757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2789 Lines: 84 Eric: Please send me 'ethtool -e eth?' for the interface corresponding to one of the 8086:1079 devices. Ganesh. >-----Original Message----- >From: Venkatesan, Ganesh >Sent: Thursday, February 17, 2005 9:02 AM >To: 'eric@ebiederm.dsl.xmission.com' >Cc: jgarzik@pobox.com; Chilakala, Mallikarjuna; netdev@oss.sgi.com >Subject: RE: e1000: driver reboot/kexec bug. > >Hi Eric: > >Could you send us 'lspci -vvv' output for 3:4.0? Could you also help us >with some more information on the platform you are using? > >Thanks, >Ganesh. > >>-----Original Message----- >>From: eric@ebiederm.dsl.xmission.com >>[mailto:eric@ebiederm.dsl.xmission.com] On Behalf Of Eric W. Biederman >>Sent: Wednesday, February 16, 2005 4:26 AM >>To: Chilakala, Mallikarjuna >>Cc: jgarzik@pobox.com; netdev >>Subject: e1000: driver reboot/kexec bug. >> >> >>When I kexec a new kernel on hardware that includes >>some revs of the e1000 (see below for lscpi -n) the >>e1000 driver is not able to reinitialize the NIC. I >>have seen this in both 2.4.29 and 2.6.10. >> >>Tracking it down it appears to be some side effect to powering down >>the nic. If I remove the pci_set_power_state call in e1000_suspend >>or I simply apply the attached patch so I get that affect when >>rebooting everything works. pci_enable_device brings the device >>up to full power before the driver initialization code does anything >>else so I don't have a clue what is really going on but it is. >> >> >>Boot messages on failure: >>> Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k1 >>> Copyright (c) 1999-2004 Intel Corporation. >>> PCI: Enabling device 03:04.0 (0000 -> 0003) >>> e1000: 03:04.0: e1000_probe: The EEPROM Checksum Is Not Valid >>> PCI: Enabling device 03:04.1 (0000 -> 0003) >>> e1000: 03:04.1: e1000_probe: The EEPROM Checksum Is Not Valid >> >>lspci -n of the problem onboard e1000 NIC. >>> 03:04.0 Class 0200: 8086:1079 (rev 03) >>> 03:04.1 Class 0200: 8086:1079 (rev 03) >> >> >>Patch which avoids the problem. >>diff -uNrX linux-exclude-files linux-2.4.29-kexec-apic-virtwire-on- >>shutdownx86_64/drivers/net/e1000/e1000_main.c linux-2.4.29- >>kexec7.build.x86_64/drivers/net/e1000/e1000_main.c >>--- linux-2.4.29-kexec-apic-virtwire-on- >>shutdownx86_64/drivers/net/e1000/e1000_main.c Tue Feb 15 14:17:09 2005 >>+++ linux-2.4.29-kexec7.build.x86_64/drivers/net/e1000/e1000_main.c Wed >>Feb 16 04:58:18 2005 >>@@ -2777,7 +2777,7 @@ >> case SYS_POWER_OFF: >> while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { >> if(pci_dev_driver(pdev) == &e1000_driver) >>- e1000_suspend(pdev, 3); >>+ e1000_suspend(pdev, (event == SYS_DOWN)?0:3); >> } >> } >> return NOTIFY_DONE; >> >> >>Any help to track down why this is happening so we can apply >>a clean fix would be appreciated. >> >>Eric From ebiederm@xmission.com Thu Feb 17 10:00:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 10:00:08 -0800 (PST) Received: from ebiederm.dsl.xmission.com (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HI02vx003558 for ; Thu, 17 Feb 2005 10:00:03 -0800 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1HHvo9N018400; Thu, 17 Feb 2005 10:57:50 -0700 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) id j1HHvlvL018397; Thu, 17 Feb 2005 10:57:47 -0700 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: "Venkatesan, Ganesh" Cc: , "Chilakala, Mallikarjuna" , Subject: Re: e1000: driver reboot/kexec bug. References: <468F3FDA28AA87429AD807992E22D07E044A1285@orsmsx408> From: ebiederm@xmission.com (Eric W. Biederman) Date: 17 Feb 2005 10:57:47 -0700 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E044A1285@orsmsx408> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Content-Length: 3297 Lines: 75 "Venkatesan, Ganesh" writes: > Hi Eric: > > Could you send us 'lspci -vvv' output for 3:4.0? Could you also help us > with some more information on the platform you are using? > Please send me 'ethtool -e eth?' for the interface corresponding to one > of the 8086:1079 devices. The motherboard is an Intel Jarell motherboard with the Lindenhurst aka E7520 chipset. I have seen the same symptoms on a recent Supermicro system as well. Do you know enough about kexec to attempt to reproduce this problem that way? Anyway hopefully this is enough to get you started. Eric 03:04.0 Ethernet controller: Intel Corp.: Unknown device 1079 (rev 03) Subsystem: Intel Corp.: Unknown device 1079 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- ; Thu, 17 Feb 2005 10:16:34 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1qBv-00060r-LY; Thu, 17 Feb 2005 19:15:55 +0100 Message-ID: <4214DF5B.3010608@trash.net> Date: Thu, 17 Feb 2005 19:15:55 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> In-Reply-To: <20050217113654.GA10346@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------020808020108000603000808" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 5165 Lines: 136 This is a multi-part message in MIME format. --------------020808020108000603000808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: >I understand the inconsistency and agree that it should be fixed. >However, I think the way you did it has created a new inconsistency. > >Tunnel mode SAs are not always used to carry subnets. It can also >be used for host-to-host configurations where the aim is to protect >the IP header. Therefore it would be inconsistent to look up a >new route for host-to-host tunnel mode SAs. > >Perhaps we can simply expand the check to include local as well, >i.e., > > if (local != fl->fl4_src || remote != fl->fl4_dst) { > >What do you think? > > I don't think this solves the inconsistency. By reuseing routes in tunnel mode we allow routing by different criteria when the inner packet is headed for the remote gateway. Your suggestion limits this a bit further, but we can still have a situation where all packets going through a tunnel take one path, except when the inner packet is heading for the remote gateway itself. I think it is logically correct to reroute all packets in tunnel mode, if we want to allow full policy routing for tunnel mode packets we should hand tos and fwmark to xfrm_dst_lookup(). I don't think we should do this currently because of a different problem. __xfrm4_find_bundle() uses a different key than routing for looking up cached bundles. When the original route was reused it is used even if fwmark/tos don't match. Fixing this is easy, but it causes alot more cached bundles to exist. My last patch limits this situation to transport mode because we always choose a new route in tunnel mode based only on src/dst. Please see the attached patch for a possible fix (ugly and compile tested only). If we want to do this for tunnel mode we probably need a hash for the cached bundles first, which has its own set of problems. Regards Patrick --------------020808020108000603000808 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== include/net/xfrm.h 1.76 vs edited ===== --- 1.76/include/net/xfrm.h 2005-02-15 22:46:16 +01:00 +++ edited/include/net/xfrm.h 2005-02-17 18:57:39 +01:00 @@ -857,7 +857,7 @@ extern void xfrm_policy_flush(void); extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern int xfrm_flush_bundles(void); -extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family); +extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family, int *is_tunnel); extern wait_queue_head_t km_waitq; extern int km_new_mapping(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); ===== net/ipv4/xfrm4_policy.c 1.15 vs edited ===== --- 1.15/net/ipv4/xfrm4_policy.c 2005-02-17 07:09:55 +01:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-02-17 19:04:45 +01:00 @@ -26,6 +26,7 @@ __xfrm4_find_bundle(struct flowi *fl, struct xfrm_policy *policy) { struct dst_entry *dst; + int is_tunnel = 0; read_lock_bh(&policy->lock); for (dst = policy->bundles; dst; dst = dst->next) { @@ -33,7 +34,13 @@ if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && - xfrm_bundle_ok(xdst, fl, AF_INET)) { + xfrm_bundle_ok(xdst, fl, AF_INET, &is_tunnel) && + (!is_tunnel || (!(xdst->u.rt.fl.fl4_tos ^ fl->fl4_tos) & + (IPTOS_RT_MASK|RTO_ONLINK) && +#ifdef CONFIG_IP_ROUTE_FWMARK + xdst->u.rt.fl.fl4_fwmark == fl->fl4_fwmark +#endif + ))) { dst_clone(dst); break; } ===== net/ipv6/xfrm6_policy.c 1.26 vs edited ===== --- 1.26/net/ipv6/xfrm6_policy.c 2005-02-17 07:09:55 +01:00 +++ edited/net/ipv6/xfrm6_policy.c 2005-02-17 18:59:31 +01:00 @@ -50,7 +50,7 @@ xdst->u.rt6.rt6i_src.plen); if (ipv6_addr_equal(&xdst->u.rt6.rt6i_dst.addr, &fl_dst_prefix) && ipv6_addr_equal(&xdst->u.rt6.rt6i_src.addr, &fl_src_prefix) && - xfrm_bundle_ok(xdst, fl, AF_INET6)) { + xfrm_bundle_ok(xdst, fl, AF_INET6, NULL)) { dst_clone(dst); break; } ===== net/xfrm/xfrm_policy.c 1.66 vs edited ===== --- 1.66/net/xfrm/xfrm_policy.c 2005-02-16 00:16:04 +01:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-17 18:59:03 +01:00 @@ -1021,7 +1021,7 @@ static int stale_bundle(struct dst_entry *dst) { - return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC); + return !xfrm_bundle_ok((struct xfrm_dst *)dst, NULL, AF_UNSPEC, NULL); } static void xfrm_dst_destroy(struct dst_entry *dst) @@ -1101,7 +1101,7 @@ * still valid. */ -int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family) +int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family, int *is_tunnel) { struct dst_entry *dst = &xdst->u.dst; @@ -1114,6 +1114,8 @@ return 0; if (dst->xfrm->km.state != XFRM_STATE_VALID) return 0; + if (is_tunnel && dst->xfrm->props.mode) + *is_tunnel = 1; dst = dst->child; } while (dst->xfrm); --------------020808020108000603000808-- From kaber@trash.net Thu Feb 17 10:26:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 10:26:21 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HIQHeX005804 for ; Thu, 17 Feb 2005 10:26:18 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1qLN-000626-JE; Thu, 17 Feb 2005 19:25:41 +0100 Message-ID: <4214E1A5.9020601@trash.net> Date: Thu, 17 Feb 2005 19:25:41 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> In-Reply-To: <4214DF5B.3010608@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1693 Lines: 44 Patrick McHardy wrote: >===== include/net/xfrm.h 1.76 vs edited ===== >--- 1.76/include/net/xfrm.h 2005-02-15 22:46:16 +01:00 >+++ edited/include/net/xfrm.h 2005-02-17 18:57:39 +01:00 >@@ -857,7 +857,7 @@ > extern void xfrm_policy_flush(void); > extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); > extern int xfrm_flush_bundles(void); >-extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family); >+extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family, int *is_tunnel); > > extern wait_queue_head_t km_waitq; > extern int km_new_mapping(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); >===== net/ipv4/xfrm4_policy.c 1.15 vs edited ===== >--- 1.15/net/ipv4/xfrm4_policy.c 2005-02-17 07:09:55 +01:00 >+++ edited/net/ipv4/xfrm4_policy.c 2005-02-17 19:04:45 +01:00 >@@ -26,6 +26,7 @@ > __xfrm4_find_bundle(struct flowi *fl, struct xfrm_policy *policy) > { > struct dst_entry *dst; >+ int is_tunnel = 0; > > read_lock_bh(&policy->lock); > for (dst = policy->bundles; dst; dst = dst->next) { >@@ -33,7 +34,13 @@ > if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ > xdst->u.rt.fl.fl4_dst == fl->fl4_dst && > xdst->u.rt.fl.fl4_src == fl->fl4_src && >- xfrm_bundle_ok(xdst, fl, AF_INET)) { >+ xfrm_bundle_ok(xdst, fl, AF_INET, &is_tunnel) && >+ (!is_tunnel || (!(xdst->u.rt.fl.fl4_tos ^ fl->fl4_tos) & > The '!' is wrong of course. >+ (IPTOS_RT_MASK|RTO_ONLINK) && >+#ifdef CONFIG_IP_ROUTE_FWMARK >+ xdst->u.rt.fl.fl4_fwmark == fl->fl4_fwmark >+#endif >+ ))) { > dst_clone(dst); > break; > > From ganesh.venkatesan@intel.com Thu Feb 17 10:33:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 10:33:44 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HIXckA006599 for ; Thu, 17 Feb 2005 10:33:41 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1HIXXMA029134; Thu, 17 Feb 2005 18:33:33 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1HIWIme024431; Thu, 17 Feb 2005 18:33:33 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021710333311780 ; Thu, 17 Feb 2005 10:33:33 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 10:33:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: e1000: driver reboot/kexec bug. Date: Thu, 17 Feb 2005 10:33:30 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E044A15C5@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000: driver reboot/kexec bug. Thread-Index: AcUVGn9qnDUDbswzSh6d40Lqf5mrSQABHFcw From: "Venkatesan, Ganesh" To: "Eric W. Biederman" Cc: , "Chilakala, Mallikarjuna" , X-OriginalArrivalTime: 17 Feb 2005 18:33:33.0286 (UTC) FILETIME=[2F5F2060:01C5151F] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1HIXckA006599 X-archive-position: 1761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 192 Lines: 9 >Do you know enough about kexec to attempt to reproduce this problem >that way? Not much. All I have is an old paper by Andy Pfiffer. Could you point me to more resources on this? Ganesh. From ebiederm@xmission.com Thu Feb 17 11:55:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 11:55:31 -0800 (PST) Received: from ebiederm.dsl.xmission.com (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HJtQeF011109 for ; Thu, 17 Feb 2005 11:55:26 -0800 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1HJr69N019205; Thu, 17 Feb 2005 12:53:06 -0700 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) id j1HJr5UQ019202; Thu, 17 Feb 2005 12:53:05 -0700 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: "Venkatesan, Ganesh" Cc: , "Chilakala, Mallikarjuna" , , Subject: Re: e1000: driver reboot/kexec bug. References: <468F3FDA28AA87429AD807992E22D07E044A15C5@orsmsx408> From: ebiederm@xmission.com (Eric W. Biederman) Date: 17 Feb 2005 12:53:05 -0700 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E044A15C5@orsmsx408> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Content-Length: 939 Lines: 35 "Venkatesan, Ganesh" writes: > >Do you know enough about kexec to attempt to reproduce this problem > >that way? > > Not much. All I have is an old paper by Andy Pfiffer. Could you point me > to more resources on this? Short explanation: The user space lives at: http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz Other bits and pieces can be found at: http://www.xmission.com/~ebiederm/files/kexec/ The latest patches are in the -mm tree. Usually it is as simple as: /sbin/kexec -l /path/to/bzImage --append='your command line options' Then drop to single user mode and do: /sbin/kexec -e My patches have not made into the initscripts yet so doing a clean system shutdown has not been fully automated yet. i386 and x86-64 architectures should both work. Not it is a matter of slowing digging into the hardware support code and getting out the bugs that are revealed. Eric From herbert@gondor.apana.org.au Thu Feb 17 12:38:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 12:39:04 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HKctMG018205 for ; Thu, 17 Feb 2005 12:38:56 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1sPx-00025Y-00; Fri, 18 Feb 2005 07:38:33 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1sPV-000144-00; Fri, 18 Feb 2005 07:38:05 +1100 Date: Fri, 18 Feb 2005 07:38:05 +1100 To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode Message-ID: <20050217203805.GA4047@gondor.apana.org.au> References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214DF5B.3010608@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1113 Lines: 25 On Thu, Feb 17, 2005 at 07:15:55PM +0100, Patrick McHardy wrote: > > >Perhaps we can simply expand the check to include local as well, > >i.e., > > > > if (local != fl->fl4_src || remote != fl->fl4_dst) { > > > >What do you think? > > I don't think this solves the inconsistency. By reuseing routes in tunnel > mode we allow routing by different criteria when the inner packet is headed > for the remote gateway. Your suggestion limits this a bit further, but we > can still have a situation where all packets going through a tunnel take > one path, except when the inner packet is heading for the remote gateway > itself. That's right. However, you should also look at it this way. We start with a policy with a transport mode SA. In order to protect the IP header we change it to use a tunnel mode SA with a host-to-host selector. With your patch this will change the route that the packet uses. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Thu Feb 17 13:23:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 13:23:44 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HLNdU0021492 for ; Thu, 17 Feb 2005 13:23:40 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1t70-0006Iv-UL; Thu, 17 Feb 2005 22:23:02 +0100 Message-ID: <42150B36.5080609@trash.net> Date: Thu, 17 Feb 2005 22:23:02 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> In-Reply-To: <20050217203805.GA4047@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1323 Lines: 32 Herbert Xu wrote: >On Thu, Feb 17, 2005 at 07:15:55PM +0100, Patrick McHardy wrote: > > >>I don't think this solves the inconsistency. By reuseing routes in tunnel >>mode we allow routing by different criteria when the inner packet is headed >>for the remote gateway. Your suggestion limits this a bit further, but we >>can still have a situation where all packets going through a tunnel take >>one path, except when the inner packet is heading for the remote gateway >>itself. >> >> > >That's right. However, you should also look at it this way. We start >with a policy with a transport mode SA. In order to protect the IP >header we change it to use a tunnel mode SA with a host-to-host selector. >With your patch this will change the route that the packet uses. > I don't consider this inconsistent, in fact it is consistent to what happens with other tunnels. We could get the behaviour you want (my patch + old behaviour for host-to-host tunnels) by looking at the policy selector, but I would prefer to always reroute. The change doesn't affect existing setups, as I said in my previous mail, it doesn't work properly since __xfrm4_find_bundle() ignores tos/fwmark and uses the route for src/dst that made the cache (first one used) for all tos/fwmark values, even if other routes exist. Regards Patrick From akpm@osdl.org Thu Feb 17 13:44:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 13:45:03 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HLiuvv023139 for ; Thu, 17 Feb 2005 13:44:56 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1HLioqi004024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 17 Feb 2005 13:44:50 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1HLinUP031735 for ; Thu, 17 Feb 2005 13:44:49 -0800 Date: Thu, 17 Feb 2005 13:44:40 -0800 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot Message-Id: <20050217134440.44f591e2.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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1765 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: 3316 Lines: 76 Begin forwarded message: Date: Thu, 17 Feb 2005 10:39:03 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot http://bugme.osdl.org/show_bug.cgi?id=4223 Summary: sis900 kernel oop at boot Kernel Version: 2.6.10 Status: NEW Severity: low Owner: acme@conectiva.com.br Submitter: mangus@deprecated.it Distribution: Slackware 10.1 Hardware Environment: Software Environment: Problem Description: kernel oop at boot time , it happens once for now. Steps to reproduce: don't know.. here is the trace Feb 15 18:26:20 saturno kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000e Feb 15 18:26:20 saturno kernel: printing eip: Feb 15 18:26:20 saturno kernel: e1113417 Feb 15 18:26:20 saturno kernel: *pde = 00000000 Feb 15 18:26:20 saturno kernel: Oops: 0000 [#1] Feb 15 18:26:20 saturno kernel: PREEMPT Feb 15 18:26:20 saturno kernel: Modules linked in: sis900 nvidia 8250_pci 8250 serial_core psmouse Feb 15 18:26:20 saturno kernel: CPU: 0 Feb 15 18:26:20 saturno kernel: EIP: 0060:[] Tainted: P VLI Feb 15 18:26:20 saturno kernel: EFLAGS: 00010296 (2.6.10-M7) Feb 15 18:26:20 saturno kernel: EIP is at sis900_check_mode+0x17/0xa0 [sis900] Feb 15 18:26:20 saturno kernel: eax: 00000000 ebx: dfd38000 ecx: 10501010 edx: 0000ec18 Feb 15 18:26:20 saturno kernel: esi: 00000000 edi: 0000ec00 ebp: dfd38220 esp: deaede88 Feb 15 18:26:20 saturno kernel: ds: 007b es: 007b ss: 0068 Feb 15 18:26:20 saturno kernel: Process ifconfig (pid: 1145, threadinfo=deaec000 task=c16fe020) Feb 15 18:26:20 saturno kernel: Stack: 00000000 00000000 00000000 00000001 dfd38000 0000ec00 e1112cc9 dfd38000 Feb 15 18:26:20 saturno kernel: 00000000 00000001 dfd38000 dfd38000 9100007b dfd38000 00000000 00001043 Feb 15 18:26:20 saturno kernel: 00000000 c027c435 dfd38000 dabe1540 c0280314 dfd38000 00001002 c027d9d3 Feb 15 18:26:20 saturno kernel: Call Trace: Feb 15 18:26:20 saturno kernel: [] sis900_open+0xe9/0x130 [sis900] Feb 15 18:26:20 saturno kernel: [] dev_open+0x85/0xa0 Feb 15 18:26:20 saturno kernel: [] dev_mc_upload+0x24/0x50 Feb 15 18:26:20 saturno kernel: [] dev_change_flags+0x53/0x130 Feb 15 18:26:20 saturno kernel: [] dev_load+0x25/0x70 Feb 15 18:26:20 saturno kernel: [] devinet_ioctl+0x257/0x5d0 Feb 15 18:26:20 saturno kernel: [] inet_ioctl+0x66/0xb0 Feb 15 18:26:20 saturno kernel: [] sock_ioctl+0xc9/0x240 Feb 15 18:26:20 saturno kernel: [] sys_ioctl+0xca/0x230 Feb 15 18:26:20 saturno kernel: [] syscall_call+0x7/0xb Feb 15 18:26:20 saturno kernel: Code: df e9 2d ff ff ff 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 83 ec 18 89 74 24 10 8b 74 24 20 89 5c 24 0c 8b 5c 24 1c 89 7c 24 14 <80> 7e 0e 02 8b 7b 68 8b 4b 18 74 3d 8d 51 04 ed 83 c8 10 ef 89 Feb 15 18:26:20 saturno kernel: <6>eth0: Using transceiver found at address 1 as default Feb 15 18:27:25 saturno portmap[2561]: cannot bind udp: Address already in use ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From herbert@gondor.apana.org.au Thu Feb 17 14:11:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 14:11:33 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HMBOuf025458 for ; Thu, 17 Feb 2005 14:11:25 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D1trP-0002dD-00; Fri, 18 Feb 2005 09:10:59 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D1tqx-0001C1-00; Fri, 18 Feb 2005 09:10:31 +1100 Date: Fri, 18 Feb 2005 09:10:31 +1100 To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode Message-ID: <20050217221031.GA4554@gondor.apana.org.au> References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> <42150B36.5080609@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42150B36.5080609@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1235 Lines: 26 On Thu, Feb 17, 2005 at 10:23:02PM +0100, Patrick McHardy wrote: > > I don't consider this inconsistent, in fact it is consistent to what > happens with other tunnels. We could get the behaviour you want (my Well we'll have to disagree on that. IMHO the flow with the internal addresses equal to the external addresses over a tunnel mode SA should be treated the same as that over a transport mode SA. > patch + old behaviour for host-to-host tunnels) by looking at the > policy selector, but I would prefer to always reroute. The change > doesn't affect existing setups, as I said in my previous mail, it > doesn't work properly since __xfrm4_find_bundle() ignores tos/fwmark > and uses the route for src/dst that made the cache (first one used) > for all tos/fwmark values, even if other routes exist. Are you sure that it doesn't change existing behaviour? Suppose that I had a socket bound to a specific device, doesn't the current code use that device as long as we're sending to the remote IPsec gateway? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dale@farnsworth.org Thu Feb 17 14:42:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 14:42:50 -0800 (PST) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1HMgfJk027924 for ; Thu, 17 Feb 2005 14:42:41 -0800 Received: (qmail 17387 invoked by uid 1000); 17 Feb 2005 22:42:39 -0000 From: "Dale Farnsworth" Date: Thu, 17 Feb 2005 15:42:39 -0700 To: netdev@oss.sgi.com, Jeff Garzik Cc: Ralf Baechle , Manish Lachwani , Brian Waite , "Steven J. Hill" , Benjamin Herrenschmidt Subject: [PATCH] mv643xx enet update + ethtool support Message-ID: <20050217224239.GA16609@xyzzy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 27319 Lines: 813 Here is an update to mv643xx ethernet support. There are several small bugfixes. The two larger issues are the beginning of ethtool support and the fact that I've disabled hardware tcp/udp checksum generation. It now looks like there's a hardware bug with the checksums, but I'm still characterizing it. ChangeSets before 1.2065 are already in -netdev. I've included a cumulative patch of the new changesets below. Thanks, -Dale Farnsworth Please do a bk pull bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet This will update the following files: drivers/net/Kconfig | 5 drivers/net/mv643xx_eth.c | 2689 ++++++++++++++++++++++++++-------------------- drivers/net/mv643xx_eth.h | 641 ++++------ include/linux/mv643xx.h | 448 +++++-- 4 files changed, 2119 insertions(+), 1664 deletions(-) through these ChangeSets: (05/02/17 1.2075) Add ethtool support to the mv643xx ethernet driver. Initially, we add statistics and link status reporting. Signed-off-by: Dale Farnsworth (05/02/17 1.2074) Enable the mv643xx ethernet support on platforms using the MV64360 chip. Signed-off-by: Dale Farnsworth (05/02/17 1.2073) Disable tcp/udp checksum offload to hardware. It generally works, but the hardware appears to generate the wrong checksum if the hw checksum generation wasn't used in the previous packet sent. I'm increasingly confident this is a hardware error. We'll disable hw tcp/udp checksum generation until we have a fix or workaround. Signed-off-by: Dale Farnsworth (05/02/17 1.2072) We already set ETH_TX_ENABLE_INTERRUPT whenever we set ETH_TX_LAST_DESC. Signed-off-by: Dale Farnsworth (05/02/17 1.2071) Update tx_bytes statistic when using hw tcp/udp checksum generation. Signed-off-by: Dale Farnsworth (05/02/17 1.2070) Call netif_carrier_off when closing the driver. Signed-off-by: Dale Farnsworth (05/02/17 1.2069) Trivial. Remove repeated comment. Signed-off-by: Dale Farnsworth (05/02/17 1.2068) Clear transmit l4i_chk even when the hardware ignores it. Not absolutely necessary, but makes debugging easier. Signed-off-by: Dale Farnsworth (05/02/17 1.2067) Increment tx_ring_skbs before calling eth_port_send, since otherwise the irq handler may check and decrement it before we increment it. Signed-off-by: Dale Farnsworth (05/02/17 1.2066) Fix handling of unaligned tiny fragments not handled by hardware Check all fragments instead of just the last. Signed-off-by: Dale Farnsworth (05/02/17 1.2065) Fix a few places I missed in the previous rename patch. Rename: mv64x60 => mv643xx Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.17) Big rename. Change MV64340 => MV643XX and mv64340 => mv643xx Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.16) Rename MV_READ => mv_read and MV_WRITE => mv_write Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.15) Additional whitespace cleanups, mostly changing spaces to tabs in comments (05/01/27 1.1966.60.14) Run mv643xx_eth.[ch] through scripts/Lindent Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.13) Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.12) This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case (05/01/27 1.1966.60.11) Add support for PHYs/boards that don't support autonegotiation. Signed-off-by: Brian Waite Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.10) With this patch, the driver now calls netif_carrier_off/netif_carrier_on on a link down/up condition. Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.9) This patch cleans up the handling of receive skb sizing. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.8) This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.7) This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. Signed-off-by: Steven J. Hill Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.6) This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: size of RX and TX descriptor rings port_config value port_config_extend value port_sdma_config value port_serial_control value PHY address Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.5) This patch adds device driver model support to the mv643xx_eth driver. This is a change to the driver's programming interface. Platform code must now pass in the address of the MV643xx ethernet registers and IRQ. If firmware doesn't set the MAC address, platform code must also pass in the MAC address. Also, note that local MV_READ/MV_WRITE macros are used rather than using global macros. Keeping the macro names minimizes the patch size. The names will be changed to mv_read/mv_write in a later cosmetic cleanup patch. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.4) This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.3) This patch fixes the code that enables hardware checksum generation. The previous code has so many problems that it appears to never have worked 2.6. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.2) This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. It also adds a spinlock to protect access to the MV64340_ETH_SMI_REG, which is shared across ports. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.1) This patch removes code that is redundant or useless. The biggest area is in pre-initializing the RX and TX descriptor rings, which only obfuscates the driver since the ring data is overwritten without being used. Signed-off-by: Dale Farnsworth --- linux-2.5-enet/drivers/net/mv643xx_eth.c +++ linux-2.5-enet/drivers/net/mv643xx_eth.c @@ -38,6 +38,7 @@ #include #include +#include #include #include #include @@ -82,8 +83,12 @@ #endif static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); static int ethernet_phy_detect(unsigned int eth_port_num); +void mv643xx_set_ethtool_ops(struct net_device *netdev); -static void __iomem *mv64x60_eth_shared_base; +static char mv643xx_driver_name[] = "mv643xx_eth"; +static char mv643xx_driver_version[] = "1.0"; + +static void __iomem *mv643xx_eth_shared_base; /* used to protect MV643XX_ETH_SMI_REG, which is shared across ports */ static spinlock_t mv643xx_eth_phy_lock = SPIN_LOCK_UNLOCKED; @@ -92,7 +97,7 @@ { void *__iomem reg_base; - reg_base = mv64x60_eth_shared_base - MV643XX_ETH_SHARED_REGS; + reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS; return readl(reg_base + offset); } @@ -101,7 +106,7 @@ { void * __iomem reg_base; - reg_base = mv64x60_eth_shared_base - MV643XX_ETH_SHARED_REGS; + reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS; writel(data, reg_base + offset); } @@ -995,6 +1000,7 @@ struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; + netif_carrier_off(dev); netif_stop_queue(dev); mv643xx_eth_free_tx_rings(dev); @@ -1159,10 +1165,11 @@ #ifdef MV643XX_CHECKSUM_OFFLOAD_TX if (!skb_shinfo(skb)->nr_frags) { linear: - if (skb->ip_summed != CHECKSUM_HW) + if (skb->ip_summed != CHECKSUM_HW) { pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC; - else { + pkt_info.l4i_chk = 0; + } else { u32 ipheader = skb->nh.iph->ihl << 11; pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | @@ -1187,21 +1194,34 @@ pkt_info.buf_ptr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE); pkt_info.return_info = skb; + mp->tx_ring_skbs++; status = eth_port_send(mp, &pkt_info); if ((status == ETH_ERROR) || (status == ETH_QUEUE_FULL)) printk(KERN_ERR "%s: Error on transmitting packet\n", dev->name); - mp->tx_ring_skbs++; + stats->tx_bytes += pkt_info.byte_cnt; } else { unsigned int frag; u32 ipheader; - skb_frag_t *last_frag; - frag = skb_shinfo(skb)->nr_frags - 1; - last_frag = &skb_shinfo(skb)->frags[frag]; - if (last_frag->size <= 8 && last_frag->page_offset & 0x7) { - skb_linearize(skb, GFP_ATOMIC); - goto linear; + /* Since hardware can't handle unaligned fragments smaller + * than 9 bytes, if we find any, we linearize the skb + * and start again. When I've seen it, it's always been + * the first frag (probably near the end of the page), + * but we check all frags to be safe. + */ + for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { + skb_frag_t *fragp; + + fragp = &skb_shinfo(skb)->frags[frag]; + if (fragp->size <= 8 && fragp->page_offset & 0x7) { + skb_linearize(skb, GFP_ATOMIC); + printk(KERN_DEBUG "%s: unaligned tiny fragment" + "%d of %d, fixed\n", + dev->name, frag, + skb_shinfo(skb)->nr_frags); + goto linear; + } } /* first frag which is skb header */ @@ -1209,11 +1229,11 @@ pkt_info.buf_ptr = dma_map_single(NULL, skb->data, skb_headlen(skb), DMA_TO_DEVICE); + pkt_info.l4i_chk = 0; pkt_info.return_info = 0; pkt_info.cmd_sts = ETH_TX_FIRST_DESC; if (skb->ip_summed == CHECKSUM_HW) { - /* CPU already calculated pseudo header checksum. */ ipheader = skb->nh.iph->ihl << 11; pkt_info.cmd_sts |= ETH_GEN_TCP_UDP_CHECKSUM | ETH_GEN_IP_V_4_CHECKSUM | ipheader; @@ -1243,6 +1263,7 @@ if (status == ETH_QUEUE_LAST_RESOURCE) printk("Tx resource error \n"); } + stats->tx_bytes += pkt_info.byte_cnt; /* Check for the remaining frags */ for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { @@ -1259,6 +1280,7 @@ } else { pkt_info.return_info = 0; } + pkt_info.l4i_chk = 0; pkt_info.byte_cnt = this_frag->size; pkt_info.buf_ptr = dma_map_page(NULL, this_frag->page, @@ -1280,20 +1302,23 @@ if (status == ETH_QUEUE_FULL) printk("Queue is full \n"); } + stats->tx_bytes += pkt_info.byte_cnt; } } #else pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC; + pkt_info.l4i_chk = 0; pkt_info.byte_cnt = skb->len; pkt_info.buf_ptr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE); pkt_info.return_info = skb; + mp->tx_ring_skbs++; status = eth_port_send(mp, &pkt_info); if ((status == ETH_ERROR) || (status == ETH_QUEUE_FULL)) printk(KERN_ERR "%s: Error on transmitting packet\n", dev->name); - mp->tx_ring_skbs++; + stats->tx_bytes += pkt_info.byte_cnt; #endif /* Check if TX queue can handle another skb. If not, then @@ -1308,7 +1333,6 @@ netif_stop_queue(dev); /* Update statistics and start of transmittion time */ - stats->tx_bytes += skb->len; stats->tx_packets++; dev->trans_start = jiffies; @@ -1388,6 +1412,7 @@ dev->tx_queue_len = mp->tx_ring_size; dev->base_addr = 0; dev->change_mtu = mv643xx_eth_change_mtu; + mv643xx_set_ethtool_ops(dev); #ifdef MV643XX_CHECKSUM_OFFLOAD_TX #ifdef MAX_SKB_FRAGS @@ -1519,9 +1544,9 @@ if (res == NULL) return -ENODEV; - mv64x60_eth_shared_base = ioremap(res->start, + mv643xx_eth_shared_base = ioremap(res->start, MV643XX_ETH_SHARED_REGS_SIZE); - if (mv64x60_eth_shared_base == NULL) + if (mv643xx_eth_shared_base == NULL) return -ENOMEM; return 0; @@ -1530,8 +1555,8 @@ static int mv643xx_eth_shared_remove(struct device *ddev) { - iounmap(mv64x60_eth_shared_base); - mv64x60_eth_shared_base = NULL; + iounmap(mv643xx_eth_shared_base); + mv643xx_eth_shared_base = NULL; return 0; } @@ -2056,6 +2081,36 @@ mv_read(MV643XX_ETH_MIB_COUNTERS_BASE(eth_port_num) + i); } +static inline u32 read_mib(struct mv643xx_private *mp, int offset) +{ + return mv_read(MV643XX_ETH_MIB_COUNTERS_BASE(mp->port_num) + offset); +} + +static void eth_update_mib_counters(struct mv643xx_private *mp) +{ + struct mv643xx_mib_counters *p = &mp->mib_counters; + int offset; + + p->good_octets_received += + read_mib(mp, ETH_MIB_GOOD_OCTETS_RECEIVED_LOW); + p->good_octets_received += + (u64)read_mib(mp, ETH_MIB_GOOD_OCTETS_RECEIVED_HIGH) << 32; + + for (offset = ETH_MIB_BAD_OCTETS_RECEIVED; + offset <= ETH_MIB_FRAMES_1024_TO_MAX_OCTETS; + offset += 4) + *(u32 *)((char *)p + offset) = read_mib(mp, offset); + + p->good_octets_sent += read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_LOW); + p->good_octets_sent += + (u64)read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_HIGH) << 32; + + for (offset = ETH_MIB_GOOD_FRAMES_SENT; + offset <= ETH_MIB_LATE_COLLISION; + offset += 4) + *(u32 *)((char *)p + offset) = read_mib(mp, offset); +} + /* * ethernet_phy_detect - Detect whether a phy is present * @@ -2262,19 +2317,27 @@ mv_write(MV643XX_ETH_PORT_CONFIG_REG(eth_port_num), eth_config_reg); } -static int eth_port_link_is_up(unsigned int eth_port_num) +static int eth_port_autoneg_supported(unsigned int eth_port_num) { unsigned int phy_reg_data0; - unsigned int phy_reg_data1; eth_port_read_smi_reg(eth_port_num, 0, &phy_reg_data0); + + return phy_reg_data0 & 0x1000; +} + +static int eth_port_link_is_up(unsigned int eth_port_num) +{ + unsigned int phy_reg_data1; + eth_port_read_smi_reg(eth_port_num, 1, &phy_reg_data1); - if (phy_reg_data0 & 0x1000) { /* auto-neg supported? */ + if (eth_port_autoneg_supported(eth_port_num)) { if (phy_reg_data1 & 0x20) /* auto-neg complete */ return 1; - } else if (phy_reg_data1 & 0x4) /* link up */ + } else if (phy_reg_data1 & 0x4) /* link up */ return 1; + return 0; } @@ -2476,9 +2539,6 @@ command = p_pkt_info->cmd_sts | ETH_ZERO_PADDING | ETH_GEN_CRC | ETH_BUFFER_OWNED_BY_DMA; - if (command & ETH_TX_LAST_DESC) - command |= ETH_TX_ENABLE_INTERRUPT; - if (command & ETH_TX_FIRST_DESC) { tx_first_desc = tx_desc_curr; mp->tx_first_desc_q = tx_first_desc; @@ -2754,0 +2815,227 @@ + +/************* Begin ethtool support *************************/ + +struct mv643xx_stats { + char stat_string[ETH_GSTRING_LEN]; + int sizeof_stat; + int stat_offset; +}; + +#define MV643XX_STAT(m) sizeof(((struct mv643xx_private *)0)->m), \ + offsetof(struct mv643xx_private, m) + +static const struct mv643xx_stats mv643xx_gstrings_stats[] = { + { "rx_packets", MV643XX_STAT(stats.rx_packets) }, + { "tx_packets", MV643XX_STAT(stats.tx_packets) }, + { "rx_bytes", MV643XX_STAT(stats.rx_bytes) }, + { "tx_bytes", MV643XX_STAT(stats.tx_bytes) }, + { "rx_errors", MV643XX_STAT(stats.rx_errors) }, + { "tx_errors", MV643XX_STAT(stats.tx_errors) }, + { "rx_dropped", MV643XX_STAT(stats.rx_dropped) }, + { "tx_dropped", MV643XX_STAT(stats.tx_dropped) }, + { "good_octets_received", MV643XX_STAT(mib_counters.good_octets_received) }, + { "bad_octets_received", MV643XX_STAT(mib_counters.bad_octets_received) }, + { "internal_mac_transmit_err", MV643XX_STAT(mib_counters.internal_mac_transmit_err) }, + { "good_frames_received", MV643XX_STAT(mib_counters.good_frames_received) }, + { "bad_frames_received", MV643XX_STAT(mib_counters.bad_frames_received) }, + { "broadcast_frames_received", MV643XX_STAT(mib_counters.broadcast_frames_received) }, + { "multicast_frames_received", MV643XX_STAT(mib_counters.multicast_frames_received) }, + { "frames_64_octets", MV643XX_STAT(mib_counters.frames_64_octets) }, + { "frames_65_to_127_octets", MV643XX_STAT(mib_counters.frames_65_to_127_octets) }, + { "frames_128_to_255_octets", MV643XX_STAT(mib_counters.frames_128_to_255_octets) }, + { "frames_256_to_511_octets", MV643XX_STAT(mib_counters.frames_256_to_511_octets) }, + { "frames_512_to_1023_octets", MV643XX_STAT(mib_counters.frames_512_to_1023_octets) }, + { "frames_1024_to_max_octets", MV643XX_STAT(mib_counters.frames_1024_to_max_octets) }, + { "good_octets_sent", MV643XX_STAT(mib_counters.good_octets_sent) }, + { "good_frames_sent", MV643XX_STAT(mib_counters.good_frames_sent) }, + { "excessive_collision", MV643XX_STAT(mib_counters.excessive_collision) }, + { "multicast_frames_sent", MV643XX_STAT(mib_counters.multicast_frames_sent) }, + { "broadcast_frames_sent", MV643XX_STAT(mib_counters.broadcast_frames_sent) }, + { "unrec_mac_control_received", MV643XX_STAT(mib_counters.unrec_mac_control_received) }, + { "fc_sent", MV643XX_STAT(mib_counters.fc_sent) }, + { "good_fc_received", MV643XX_STAT(mib_counters.good_fc_received) }, + { "bad_fc_received", MV643XX_STAT(mib_counters.bad_fc_received) }, + { "undersize_received", MV643XX_STAT(mib_counters.undersize_received) }, + { "fragments_received", MV643XX_STAT(mib_counters.fragments_received) }, + { "oversize_received", MV643XX_STAT(mib_counters.oversize_received) }, + { "jabber_received", MV643XX_STAT(mib_counters.jabber_received) }, + { "mac_receive_error", MV643XX_STAT(mib_counters.mac_receive_error) }, + { "bad_crc_event", MV643XX_STAT(mib_counters.bad_crc_event) }, + { "collision", MV643XX_STAT(mib_counters.collision) }, + { "late_collision", MV643XX_STAT(mib_counters.late_collision) }, +}; + +#define MV643XX_STATS_LEN \ + sizeof(mv643xx_gstrings_stats) / sizeof(struct mv643xx_stats) + +static int +mv643xx_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) +{ + struct mv643xx_private *mp = netdev->priv; + int port_num = mp->port_num; + int autoneg = eth_port_autoneg_supported(port_num); + int mode_10_bit; + int auto_duplex; + int half_duplex = 0; + int full_duplex = 0; + int auto_speed; + int speed_10 = 0; + int speed_100 = 0; + int speed_1000 = 0; + + u32 pcs = mv_read(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num)); + u32 psr = mv_read(MV643XX_ETH_PORT_STATUS_REG(port_num)); + + mode_10_bit = psr & MV643XX_ETH_PORT_STATUS_MODE_10_BIT; + + if (mode_10_bit) { + ecmd->supported = SUPPORTED_10baseT_Half; + } else { + ecmd->supported = (SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Full | + (autoneg ? SUPPORTED_Autoneg : 0) | + SUPPORTED_TP); + + auto_duplex = !(pcs & MV643XX_ETH_DISABLE_AUTO_NEG_FOR_DUPLX); + auto_speed = !(pcs & MV643XX_ETH_DISABLE_AUTO_NEG_SPEED_GMII); + + ecmd->advertising = ADVERTISED_TP; + + if (autoneg) { + ecmd->advertising |= ADVERTISED_Autoneg; + + if (auto_duplex) { + half_duplex = 1; + full_duplex = 1; + } else { + if (pcs & MV643XX_ETH_SET_FULL_DUPLEX_MODE) + full_duplex = 1; + else + half_duplex = 1; + } + + if (auto_speed) { + speed_10 = 1; + speed_100 = 1; + speed_1000 = 1; + } else { + if (pcs & MV643XX_ETH_SET_GMII_SPEED_TO_1000) + speed_1000 = 1; + else if (pcs & MV643XX_ETH_SET_MII_SPEED_TO_100) + speed_100 = 1; + else + speed_10 = 1; + } + + if (speed_10 & half_duplex) + ecmd->advertising |= ADVERTISED_10baseT_Half; + if (speed_10 & full_duplex) + ecmd->advertising |= ADVERTISED_10baseT_Full; + if (speed_100 & half_duplex) + ecmd->advertising |= ADVERTISED_100baseT_Half; + if (speed_100 & full_duplex) + ecmd->advertising |= ADVERTISED_100baseT_Full; + if (speed_1000) + ecmd->advertising |= ADVERTISED_1000baseT_Full; + } + } + + ecmd->port = PORT_TP; + ecmd->phy_address = ethernet_phy_get(port_num); + + ecmd->transceiver = XCVR_EXTERNAL; + + if (netif_carrier_ok(netdev)) { + if (mode_10_bit) + ecmd->speed = SPEED_10; + else { + if (psr & MV643XX_ETH_PORT_STATUS_GMII_1000) + ecmd->speed = SPEED_1000; + else if (psr & MV643XX_ETH_PORT_STATUS_MII_100) + ecmd->speed = SPEED_100; + else + ecmd->speed = SPEED_10; + } + + if (psr & MV643XX_ETH_PORT_STATUS_FULL_DUPLEX) + ecmd->duplex = DUPLEX_FULL; + else + ecmd->duplex = DUPLEX_HALF; + } else { + ecmd->speed = -1; + ecmd->duplex = -1; + } + + ecmd->autoneg = autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE; + return 0; +} + +static void +mv643xx_get_drvinfo(struct net_device *netdev, + struct ethtool_drvinfo *drvinfo) +{ + strncpy(drvinfo->driver, mv643xx_driver_name, 32); + strncpy(drvinfo->version, mv643xx_driver_version, 32); + strncpy(drvinfo->fw_version, "N/A", 32); + strncpy(drvinfo->bus_info, "mv643xx", 32); + drvinfo->n_stats = MV643XX_STATS_LEN; +} + +static int +mv643xx_get_stats_count(struct net_device *netdev) +{ + return MV643XX_STATS_LEN; +} + +static void +mv643xx_get_ethtool_stats(struct net_device *netdev, + struct ethtool_stats *stats, uint64_t *data) +{ + struct mv643xx_private *mp = netdev->priv; + int i; + + eth_update_mib_counters(mp); + + for(i = 0; i < MV643XX_STATS_LEN; i++) { + char *p = (char *)mp+mv643xx_gstrings_stats[i].stat_offset; + data[i] = (mv643xx_gstrings_stats[i].sizeof_stat == + sizeof(uint64_t)) ? *(uint64_t *)p : *(uint32_t *)p; + } +} + +static void +mv643xx_get_strings(struct net_device *netdev, uint32_t stringset, uint8_t *data) +{ + int i; + + switch(stringset) { + case ETH_SS_STATS: + for (i=0; i < MV643XX_STATS_LEN; i++) { + memcpy(data + i * ETH_GSTRING_LEN, + mv643xx_gstrings_stats[i].stat_string, + ETH_GSTRING_LEN); + } + break; + } +} + +struct ethtool_ops mv643xx_ethtool_ops = { + .get_settings = mv643xx_get_settings, + .get_drvinfo = mv643xx_get_drvinfo, + .get_link = ethtool_op_get_link, + .get_sg = ethtool_op_get_sg, + .set_sg = ethtool_op_set_sg, + .get_strings = mv643xx_get_strings, + .get_stats_count = mv643xx_get_stats_count, + .get_ethtool_stats = mv643xx_get_ethtool_stats, +}; + +void mv643xx_set_ethtool_ops(struct net_device *netdev) +{ + SET_ETHTOOL_OPS(netdev, &mv643xx_ethtool_ops); +} + +/************* End ethtool support *************************/ --- linux-2.5-enet/drivers/net/mv643xx_eth.h +++ linux-2.5-enet/drivers/net/mv643xx_eth.h @@ -46,8 +46,10 @@ * The first part is the high level driver of the gigE ethernet ports. */ -/* Checksum offload for Tx works */ -#define MV643XX_CHECKSUM_OFFLOAD_TX +/* Checksum offload for Tx works for most packets, but + * fails if previous packet sent did not use hw csum + */ +#undef MV643XX_CHECKSUM_OFFLOAD_TX #define MV643XX_NAPI #define MV643XX_TX_FAST_REFILL #undef MV643XX_RX_QUEUE_FILL_ON_TASK /* Does not work, yet */ @@ -286,6 +288,39 @@ /* Ethernet port specific infomation */ +struct mv643xx_mib_counters { + u64 good_octets_received; + u32 bad_octets_received; + u32 internal_mac_transmit_err; + u32 good_frames_received; + u32 bad_frames_received; + u32 broadcast_frames_received; + u32 multicast_frames_received; + u32 frames_64_octets; + u32 frames_65_to_127_octets; + u32 frames_128_to_255_octets; + u32 frames_256_to_511_octets; + u32 frames_512_to_1023_octets; + u32 frames_1024_to_max_octets; + u64 good_octets_sent; + u32 good_frames_sent; + u32 excessive_collision; + u32 multicast_frames_sent; + u32 broadcast_frames_sent; + u32 unrec_mac_control_received; + u32 fc_sent; + u32 good_fc_received; + u32 bad_fc_received; + u32 undersize_received; + u32 fragments_received; + u32 oversize_received; + u32 jabber_received; + u32 mac_receive_error; + u32 bad_crc_event; + u32 collision; + u32 late_collision; +}; + struct mv643xx_private { int port_num; /* User Ethernet port number */ u8 port_mac_addr[6]; /* User defined port MAC address.*/ @@ -336,6 +371,7 @@ * Former struct mv643xx_eth_priv members start here */ struct net_device_stats stats; + struct mv643xx_mib_counters mib_counters; spinlock_t lock; /* Size of Tx Ring per queue */ unsigned int tx_ring_size; --- linux-2.5-enet.orig/drivers/net/Kconfig +++ linux-2.5-enet/drivers/net/Kconfig @@ -2094,10 +2094,11 @@ config MV643XX_ETH tristate "MV-643XX Ethernet support" - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 help This driver supports the gigabit Ethernet on the Marvell MV643XX - chipset which is used in the Momenco Ocelot C and Jaguar ATX. + chipset which is used in the Momenco Ocelot C and Jaguar ATX and + Pegasos II, amongst other PPC and MIPS boards. config MV643XX_ETH_0 bool "MV-643XX Port 0" --- linux-2.5-enet.orig/include/linux/mv643xx.h +++ linux-2.5-enet/include/linux/mv643xx.h @@ -1257,6 +1257,20 @@ MV643XX_ETH_SET_FULL_DUPLEX_MODE | \ MV643XX_ETH_ENABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX +/* These macros describe Ethernet Serial Status reg (PSR) bits */ +#define MV643XX_ETH_PORT_STATUS_MODE_10_BIT (1<<0) +#define MV643XX_ETH_PORT_STATUS_LINK_UP (1<<1) +#define MV643XX_ETH_PORT_STATUS_FULL_DUPLEX (1<<2) +#define MV643XX_ETH_PORT_STATUS_FLOW_CONTROL (1<<3) +#define MV643XX_ETH_PORT_STATUS_GMII_1000 (1<<4) +#define MV643XX_ETH_PORT_STATUS_MII_100 (1<<5) +/* PSR bit 6 is undocumented */ +#define MV643XX_ETH_PORT_STATUS_TX_IN_PROGRESS (1<<7) +#define MV643XX_ETH_PORT_STATUS_AUTONEG_BYPASSED (1<<8) +#define MV643XX_ETH_PORT_STATUS_PARTITION (1<<9) +#define MV643XX_ETH_PORT_STATUS_TX_FIFO_EMPTY (1<<10) +/* PSR bits 11-31 are reserved */ + #define MV643XX_ETH_PORT_DEFAULT_TRANSMIT_QUEUE_SIZE 800 #define MV643XX_ETH_PORT_DEFAULT_RECEIVE_QUEUE_SIZE 400 From kaber@trash.net Thu Feb 17 15:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:03:09 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HN33Qi029529 for ; Thu, 17 Feb 2005 15:03:04 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1ufD-0006QX-Pw; Fri, 18 Feb 2005 00:02:27 +0100 Message-ID: <42152283.4030800@trash.net> Date: Fri, 18 Feb 2005 00:02:27 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Always reroute in tunnel mode References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> <42150B36.5080609@trash.net> <20050217221031.GA4554@gondor.apana.org.au> In-Reply-To: <20050217221031.GA4554@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 39 Herbert Xu wrote: >On Thu, Feb 17, 2005 at 10:23:02PM +0100, Patrick McHardy wrote: > > >>I don't consider this inconsistent, in fact it is consistent to what >>happens with other tunnels. We could get the behaviour you want (my >> >> > >Well we'll have to disagree on that. IMHO the flow with the internal >addresses equal to the external addresses over a tunnel mode SA should >be treated the same as that over a transport mode SA. > > Maybe Dave can help resolve this with a third opinion. >>patch + old behaviour for host-to-host tunnels) by looking at the >>policy selector, but I would prefer to always reroute. The change >>doesn't affect existing setups, as I said in my previous mail, it >>doesn't work properly since __xfrm4_find_bundle() ignores tos/fwmark >>and uses the route for src/dst that made the cache (first one used) >>for all tos/fwmark values, even if other routes exist. >> >> > >Are you sure that it doesn't change existing behaviour? Suppose that >I had a socket bound to a specific device, doesn't the current code >use that device as long as we're sending to the remote IPsec gateway? > > You're right, if no other route using same src/dst/oif made the cache first it will be used. Regards Patrick From asimshankar@gmail.com Thu Feb 17 15:06:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:06:26 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HN6KJq030206 for ; Thu, 17 Feb 2005 15:06:23 -0800 Received: by wproxy.gmail.com with SMTP id 68so397717wri for ; Thu, 17 Feb 2005 15:06:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eoIUn2awcsn1BGPIEqskVTBPAV03ykEysc3096lKBFMS5lUzlfbzNXrvnkZxnVTqGraFqln7cua+4pBvHQY/TqRwgUBY+Pq2V7BakWojwiiLkO4R3y+mwjdtjWLGWI5pdeIDCZ6RSaPCS2dO5dtmJvmIWKXjRYWF52k9x1WNqzM= Received: by 10.54.33.62 with SMTP id g62mr162819wrg; Thu, 17 Feb 2005 15:06:14 -0800 (PST) Received: by 10.54.24.42 with HTTP; Thu, 17 Feb 2005 15:06:13 -0800 (PST) Message-ID: <7bca1cb5050217150642addd71@mail.gmail.com> Date: Thu, 17 Feb 2005 17:06:13 -0600 From: Asim Shankar Reply-To: Asim Shankar To: Chetan Kumar Subject: Re: Some query on ingress policing Cc: netdev@oss.sgi.com In-Reply-To: <17fe83cb05021616323c3dab@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <17fe83cb0502160349a4190d1@mail.gmail.com> <17fe83cb05021616323c3dab@mail.gmail.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 799 Lines: 20 > I was going thro the packet journey thro the network stack in Linux. > Now if I want enable ingress policing, it looks like packet > classification and policing should happen in netif_rx (i.e in the > interrupt context) before packet is queued on to the input queue am I > missing something. My understanding is that ingress policing (the qdisc_ingress->enqueue() call) is done in the softint. See netif_receive_skb() for a call to ing_filter(). Alternatively, if CONFIG_NET_CLS_ACT=n and CONFIG_NETFILTER=y then the policing happens as an NF_IP_PRE_ROUTING netfilter hook instead. Also, netif_rx() is not the single point of entry for skb's to the stack. NAPI drivers are polled for packets, so packets aren't always picked up from the NIC in the interrupt context. Hope that helps, -- Asim From davem@davemloft.net Thu Feb 17 15:18:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:18:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HNHwiL031439 for ; Thu, 17 Feb 2005 15:18:00 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D1unq-0002Yy-00; Thu, 17 Feb 2005 15:11:22 -0800 Date: Thu, 17 Feb 2005 15:11:22 -0800 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM]: Always reroute in tunnel mode Message-Id: <20050217151122.098c6def.davem@davemloft.net> In-Reply-To: <42152283.4030800@trash.net> References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> <42150B36.5080609@trash.net> <20050217221031.GA4554@gondor.apana.org.au> <42152283.4030800@trash.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 487 Lines: 13 On Fri, 18 Feb 2005 00:02:27 +0100 Patrick McHardy wrote: > >Well we'll have to disagree on that. IMHO the flow with the internal > >addresses equal to the external addresses over a tunnel mode SA should > >be treated the same as that over a transport mode SA. > > Maybe Dave can help resolve this with a third opinion. I have to side with Patrick on this one. This is one of the fundamental tunnel behavior differences between Transport mode and Tunnel mode SAs. From kaber@trash.net Thu Feb 17 15:27:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:27:06 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HNR1AU032397 for ; Thu, 17 Feb 2005 15:27:01 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D1v2v-0006TD-6D; Fri, 18 Feb 2005 00:26:57 +0100 Message-ID: <42152841.5000707@trash.net> Date: Fri, 18 Feb 2005 00:26:57 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> In-Reply-To: <20050217091137.GA9476@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 4579 Lines: 94 Herbert Xu wrote: >On Thu, Feb 17, 2005 at 08:48:15AM +0100, Patrick McHardy wrote: > >>sorry for the delay, I haven't made much progress yet. The old patch was >>crap, I started over again. So far I've been mostly looking into a better >>wake-up mechanism for SADB changes than the brute-force approach currently >>taken with km_waitq. All incomplete bundles are waiting on exactly one >>SA at a time. Keying daemons need to specify the sequence number for SAs >>installed in response to an acquire request, finding everything waiting >>on this SA is easy. But it could also be added manually by the user, in >>which case the larval state SA continues to exist. I'm not sure if we need >>to cover this case. A different problem is finding everything waiting on a >>SA when SAs turn invalid to send back an ICMP error without waiting for a >>timeout. Adding a wait list to larval state SAs would be ok (if useful), >>but adding a list to every state would be a big mess. So it seems we can't >>do much better than km_waitq. SPD changes are fortunately pretty easy, >>when policies are inserted we do nothing, packets should always use the >>policy that was active for them at the time of the first lookup. When the >>policy that was selected is removed we simply drop the packets. >>I appreciate any comments you might have, I'll try to come up with some code >>in the next days. >> > >Thanks for the update. I think there's another aspect of the problem >that we can tackle first. > >To me there are two parts to the puzzle. We've got packets whose flow >resolves to an incomplete bundle and we've got sockets whose dst is an >incomplete bundle. > >Whatever solution we come up with needs to resolve both problems. > >First of all the sockets shouldn't wait for the larval states to >materialise. The reason is that the information they need from >the bundle (such as the MTU) is either already available or >can be provided through a best-effort guess such that the socket >can handle a change later on when the larval state is filled in. > >To do this we need to be able to generate xfrm_dst bundles with >larval states. This shouldn't be difficult. > Yes, this part is simple. There's one thing I think we need to do slightly different from what you describe. The current behaviour is to resolve one SA at a time, we should keep it this way because we may need an early SA in the bundle for a different policy to resolve a follow-up SA for nested tunnels with different peers where the second peer is only reachable through a tunnel to the first peer. I'm not sure if this actually works, but it also saves traffic when resolving a SA fails. So in addition to larval state SAs we also add XFRM_STATE_VOID SAs initialized to the parameters contained in the template to the bundle. I'm not sure yet how to deal with optional SAs. We shouldn't add incomplete optional tunnel mode SAs to the bundle because then we can't determine the output device, but if we don't nothing will trigger resolving of optional SAs following a non-optional SA that needs to be resolved. >If we apply the same strategy to the packets (by giving them bundles >with larval states in them) then we can defer the waiting from the >route loop-up stage to the dst output stage. There the packet can >be placed on a queue similar to arp_queue. > >At this point we can come back and revisit the problem that you've >pointed out. I haven't thought about it very much so this might >sound silly: We could either key the packets by the larval SA so that >when that larval SA is updated through UPDATESA or GETSPI/UPDATESA >we process the packets. Or we could key the packets by its flow so >that the creation of any SA matching that flow causes them to be >processed. > I thought about adding the queue to the xfrm_dst and adding a dummy xfrm_state with a selector that matches only the current flow. This allows us to cache incomplete bundles, more easily find all packets affected by SADB changes and only resolve the bundle once for the entire queue. The downside is that we could potentially get a lot of bundles. Finding all queues affected by ADDSA/UPDATESA is not easy. A SA installed in response to an acquire request doesn't need to match the one requested, so theoretically states waiting on different larval states SAs might be able to use it. I don't think we have much choice other than looking at all incomplete bundles (or one per flow) on SADB changes. >Feel free to move the discussion to netdev so that others can voice >their thoughts. > Thanks for your input. Regards Patrick From jgarzik@pobox.com Thu Feb 17 15:30:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:30:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HNUTDA000572 for ; Thu, 17 Feb 2005 15:30:30 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D1v6K-0002KZ-0S; Thu, 17 Feb 2005 23:30:28 +0000 Message-ID: <42152900.7090100@pobox.com> Date: Thu, 17 Feb 2005 18:30:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew J Galgoci CC: netdev@oss.sgi.com Subject: Re: [patch] wireless-2.6 stuff References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1772 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: 199 Lines: 13 Matthew J Galgoci wrote: > > Jeff, > > Here are some basic no-brainer stuff for wireless-2.6. I don't have any atmel hardware > to test though. wanna resend without the _OBSOLETE stuff? Jeff From romieu@fr.zoreil.com Thu Feb 17 15:31:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 15:31:37 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1HNVPtA001009 for ; Thu, 17 Feb 2005 15:31:26 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1HNSEGV009691; Fri, 18 Feb 2005 00:28:14 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1HNS4KU009690; Fri, 18 Feb 2005 00:28:04 +0100 Date: Fri, 18 Feb 2005 00:28:04 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up Message-ID: <20050217232804.GA4992@electric-eye.fr.zoreil.com> References: <200502161823.43562.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502161823.43562.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1773 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: 3017 Lines: 106 Jon Mason : > This patch removes netif_poll_disable if NAPI is not enabled (otherwise > adapter will hang while changing MTUs). I am currently running a non-napi r8169 on x86/sparc64 based on 2.6.11-rc4 + patches in Jeff's netdev and it apparently does not mind change of mtu. How am I supposed to make it hang ? > This patch also fixes a possible skb alignment overrun, Ok. Added some bits, see below. > and fixes the rx skb allocation error logging. It also Ok. I'd rather see it as shown below though (cuts some code and more ppc-friendly unsigned ints). > removes an unnecessary define, Ok. > adds a link down notification, and cleans up Ok. I'll netif_msg it before someone else complains that the driver is too verbose. ----------------------8<----------------------------------------- Fix rx skb allocation error logging Signed arithmetic is not required as rtl8169_rx_fill() return belongs to the [0; NUM_RX_DESC] interval. Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-400 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-400 2005-02-17 21:50:09.820173216 +0100 +++ b/drivers/net/r8169.c 2005-02-17 22:00:00.210450784 +0100 @@ -2156,8 +2156,8 @@ static int rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void __iomem *ioaddr) { - unsigned int cur_rx, rx_left, count; - int delta; + unsigned int cur_rx, rx_left; + unsigned int delta, count; assert(dev != NULL); assert(tp != NULL); @@ -2225,10 +2225,8 @@ rtl8169_rx_interrupt(struct net_device * tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta < 0) { + if (!delta && count) printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); - delta = 0; - } tp->dirty_rx += delta; /* _ Nail an overrun in skb alignment and remove the relevant magic variable. Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-410 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-410 2005-02-17 22:13:04.209897364 +0100 +++ b/drivers/net/r8169.c 2005-02-17 22:17:25.747969121 +0100 @@ -1697,11 +1697,11 @@ static int rtl8169_alloc_rx_skb(struct p dma_addr_t mapping; int ret = 0; - skb = dev_alloc_skb(rx_buf_sz); + skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); if (!skb) goto err_out; - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); *sk_buff = skb; mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, @@ -2140,9 +2140,9 @@ static inline int rtl8169_try_rx_copy(st if (pkt_size < rx_copybreak) { struct sk_buff *skb; - skb = dev_alloc_skb(pkt_size + 2); + skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (skb) { - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); *sk_buff = skb; rtl8169_return_to_asic(desc, rx_buf_sz); _ -- Ueimor From ganesh.venkatesan@intel.com Thu Feb 17 18:12:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 18:12:41 -0800 (PST) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I2CXq7014898 for ; Thu, 17 Feb 2005 18:12:35 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j1I2CSmi003604; Fri, 18 Feb 2005 02:12:28 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j1I2COaC008364; Fri, 18 Feb 2005 02:12:27 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021718122726430 ; Thu, 17 Feb 2005 18:12:27 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 18:12:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [2.6 patch] drivers/net/e1000/: possible cleanup Date: Thu, 17 Feb 2005 18:12:26 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E044D4074@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.6 patch] drivers/net/e1000/: possible cleanup Thread-Index: AcUVX0nXxnjK8+pgSjmCa5hWfQ7r0Q== From: "Venkatesan, Ganesh" To: Cc: , X-OriginalArrivalTime: 18 Feb 2005 02:12:27.0512 (UTC) FILETIME=[4B0C9780:01C5155F] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1I2CXq7014898 X-archive-position: 1774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 313 Lines: 10 Adrian: Thanks for the comments. Although all your comments are valid, we will not be able to apply your patch as is. This is because of the way we have set up our source code (some of which is shared with non-GPL code). We will submit a patch that addresses all the issues you've raised here. Thanks, Ganesh. From jdmason@us.ibm.com Thu Feb 17 20:00:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 20:01:00 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I40loC022916 for ; Thu, 17 Feb 2005 20:00:53 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1I40f0D609958 for ; Thu, 17 Feb 2005 23:00:41 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1I40fXt143544 for ; Thu, 17 Feb 2005 21:00:41 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1I40eb9009524 for ; Thu, 17 Feb 2005 21:00:40 -0700 Received: from sig-9-65-20-6.mts.ibm.com (sig-9-65-20-6.mts.ibm.com [9.65.20.6]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1I40edq009521; Thu, 17 Feb 2005 21:00:40 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Thu, 17 Feb 2005 22:00:39 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <20050217232804.GA4992@electric-eye.fr.zoreil.com> In-Reply-To: <20050217232804.GA4992@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: <200502172200.39423.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3653 Lines: 119 On Thursday 17 February 2005 05:28 pm, Francois Romieu wrote: > Jon Mason : > > This patch removes netif_poll_disable if NAPI is not enabled (otherwise > > adapter will hang while changing MTUs). > > I am currently running a non-napi r8169 on x86/sparc64 based on 2.6.11-rc4 > + patches in Jeff's netdev and it apparently does not mind change of mtu. > > How am I supposed to make it hang ? I can't seem to make it hang anymore. I guess I was wrong. Please remove this part of the patch. > > This patch also fixes a possible skb alignment overrun, > > Ok. Added some bits, see below. Sorry for the oversight, but I had the 2nd part in the jumbo frames patch. > > and fixes the rx skb allocation error logging. It also > > Ok. I'd rather see it as shown below though (cuts some code and more > ppc-friendly unsigned ints). Actually, I think it should be something like: if (delta != count) > > removes an unnecessary define, > > Ok. > > > adds a link down notification, and cleans up > > Ok. I'll netif_msg it before someone else complains that the driver > is too verbose. ya, I was thinking about modifying most of the printks to dprintks (and possibly moving to the e1000 dprintk model), but I like the link down notification. > ----------------------8<----------------------------------------- > > Fix rx skb allocation error logging > > Signed arithmetic is not required as rtl8169_rx_fill() return belongs > to the [0; NUM_RX_DESC] interval. > > Signed-off-by: Jon Mason > Signed-off-by: Francois Romieu > > diff -puN drivers/net/r8169.c~r8169-400 drivers/net/r8169.c > --- a/drivers/net/r8169.c~r8169-400 2005-02-17 21:50:09.820173216 +0100 > +++ b/drivers/net/r8169.c 2005-02-17 22:00:00.210450784 +0100 > @@ -2156,8 +2156,8 @@ static int > rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, > void __iomem *ioaddr) > { > - unsigned int cur_rx, rx_left, count; > - int delta; > + unsigned int cur_rx, rx_left; > + unsigned int delta, count; > > assert(dev != NULL); > assert(tp != NULL); > @@ -2225,10 +2225,8 @@ rtl8169_rx_interrupt(struct net_device * > tp->cur_rx = cur_rx; > > delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); > - if (delta < 0) { > + if (!delta && count) > printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); > - delta = 0; > - } > tp->dirty_rx += delta; > > /* > > _ > > Nail an overrun in skb alignment and remove the relevant magic variable. > > Signed-off-by: Jon Mason > Signed-off-by: Francois Romieu > > diff -puN drivers/net/r8169.c~r8169-410 drivers/net/r8169.c > --- a/drivers/net/r8169.c~r8169-410 2005-02-17 22:13:04.209897364 +0100 > +++ b/drivers/net/r8169.c 2005-02-17 22:17:25.747969121 +0100 > @@ -1697,11 +1697,11 @@ static int rtl8169_alloc_rx_skb(struct p > dma_addr_t mapping; > int ret = 0; > > - skb = dev_alloc_skb(rx_buf_sz); > + skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); > if (!skb) > goto err_out; > > - skb_reserve(skb, 2); > + skb_reserve(skb, NET_IP_ALIGN); > *sk_buff = skb; > > mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, > @@ -2140,9 +2140,9 @@ static inline int rtl8169_try_rx_copy(st > if (pkt_size < rx_copybreak) { > struct sk_buff *skb; > > - skb = dev_alloc_skb(pkt_size + 2); > + skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); > if (skb) { > - skb_reserve(skb, 2); > + skb_reserve(skb, NET_IP_ALIGN); > eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); > *sk_buff = skb; > rtl8169_return_to_asic(desc, rx_buf_sz); > > _ > > > -- > Ueimor From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:49 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTXM032231 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PJpn006769; Thu, 17 Feb 2005 23:25:19 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20dj-0000kk-02; Thu, 17 Feb 2005 23:25:19 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <6.378217222@selenic.com> Message-Id: <7.378217222@selenic.com> Subject: [PATCH 6/6] netpoll: handle xmit_lock recursion similarly Date: Thu, 17 Feb 2005 23:25:19 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1783 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: 622 Lines: 20 Handle possible recursion on xmit_lock while we're at it. Signed-off-by: Matt Mackall Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:40:05.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:07.000000000 -0600 @@ -247,8 +247,9 @@ return; } - /* avoid ->poll recursion */ - if(np->poll_owner == __smp_processor_id()) { + /* avoid recursion */ + if(np->poll_owner == __smp_processor_id() || + np->dev->xmit_lock_owner == __smp_processor_id()) { if (np->drop) np->drop(skb); else From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:48 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTHC032236 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PIWr006744; Thu, 17 Feb 2005 23:25:19 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20di-0000kk-03; Thu, 17 Feb 2005 23:25:18 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <3.378217222@selenic.com> Message-Id: <4.378217222@selenic.com> Subject: [PATCH 3/6] netpoll: add netpoll point to net_device Date: Thu, 17 Feb 2005 23:25:18 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1780 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: 5726 Lines: 215 Add struct netpoll pointer to struct netdevice Move netpoll rx flags to netpoll struct Stop traversing rx_list and get np pointer from skb->dev->np Remove now unneeded rx_list Signed-off-by: Matt Mackall Index: rc4/include/linux/netdevice.h =================================================================== --- rc4.orig/include/linux/netdevice.h 2005-02-17 22:32:12.000000000 -0600 +++ rc4/include/linux/netdevice.h 2005-02-17 22:32:20.000000000 -0600 @@ -41,7 +41,7 @@ struct divert_blk; struct vlan_group; struct ethtool_ops; - +struct netpoll; /* source back-compat hooks */ #define SET_ETHTOOL_OPS(netdev,ops) \ ( (netdev)->ethtool_ops = (ops) ) @@ -471,7 +471,7 @@ int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); int (*accept_fastpath)(struct net_device *, struct dst_entry*); #ifdef CONFIG_NETPOLL - int netpoll_rx; + struct netpoll *np; #endif #ifdef CONFIG_NET_POLL_CONTROLLER void (*poll_controller)(struct net_device *dev); Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:32:19.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:39:59.000000000 -0600 @@ -35,9 +35,6 @@ static int nr_skbs; static struct sk_buff *skbs; -static DEFINE_SPINLOCK(rx_list_lock); -static LIST_HEAD(rx_list); - static atomic_t trapped; static DEFINE_SPINLOCK(netpoll_poll_lock); @@ -84,13 +81,13 @@ queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && !list_empty(&queue->poll_list)) { - np->dev->netpoll_rx |= NETPOLL_RX_DROP; + np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); np->dev->poll(np->dev, &budget); atomic_dec(&trapped); - np->dev->netpoll_rx &= ~NETPOLL_RX_DROP; + np->rx_flags &= ~NETPOLL_RX_DROP; } spin_unlock_irqrestore(&netpoll_poll_lock, flags); } @@ -279,18 +276,7 @@ int size, type = ARPOP_REPLY, ptype = ETH_P_ARP; u32 sip, tip; struct sk_buff *send_skb; - unsigned long flags; - struct list_head *p; - struct netpoll *np = NULL; - - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if ( np->dev == skb->dev ) - break; - np = NULL; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + struct netpoll *np = skb->dev->np; if (!np) return; @@ -373,10 +359,10 @@ int proto, len, ulen; struct iphdr *iph; struct udphdr *uh; - struct netpoll *np; - struct list_head *p; - unsigned long flags; + struct netpoll *np = skb->dev->np; + if (!np->rx_hook) + goto out; if (skb->dev->type != ARPHRD_ETHER) goto out; @@ -420,30 +406,19 @@ goto out; if (checksum_udp(skb, uh, ulen, iph->saddr, iph->daddr) < 0) goto out; + if (np->local_ip && np->local_ip != ntohl(iph->daddr)) + goto out; + if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) + goto out; + if (np->local_port && np->local_port != ntohs(uh->dest)) + goto out; - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if (np->dev && np->dev != skb->dev) - continue; - if (np->local_ip && np->local_ip != ntohl(iph->daddr)) - continue; - if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) - continue; - if (np->local_port && np->local_port != ntohs(uh->dest)) - continue; - - spin_unlock_irqrestore(&rx_list_lock, flags); - - if (np->rx_hook) - np->rx_hook(np, ntohs(uh->source), - (char *)(uh+1), - ulen - sizeof(struct udphdr)); + np->rx_hook(np, ntohs(uh->source), + (char *)(uh+1), + ulen - sizeof(struct udphdr)); - kfree_skb(skb); - return 1; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + kfree_skb(skb); + return 1; out: if (atomic_read(&trapped)) { @@ -574,6 +549,10 @@ np->name, np->dev_name); return -1; } + + np->dev = ndev; + ndev->np = np; + if (!ndev->poll_controller) { printk(KERN_ERR "%s: %s doesn't support polling, aborting.\n", np->name, np->dev_name); @@ -639,36 +618,22 @@ np->name, HIPQUAD(np->local_ip)); } - np->dev = ndev; - - if(np->rx_hook) { - unsigned long flags; - - np->dev->netpoll_rx = NETPOLL_RX_ENABLED; - - spin_lock_irqsave(&rx_list_lock, flags); - list_add(&np->rx_list, &rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } + if(np->rx_hook) + np->rx_flags = NETPOLL_RX_ENABLED; return 0; + release: + ndev->np = NULL; + np->dev = NULL; dev_put(ndev); return -1; } void netpoll_cleanup(struct netpoll *np) { - if (np->rx_hook) { - unsigned long flags; - - spin_lock_irqsave(&rx_list_lock, flags); - list_del(&np->rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } - if (np->dev) - np->dev->netpoll_rx = 0; + np->dev->np = NULL; dev_put(np->dev); np->dev = NULL; } Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:32:19.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:39:59.000000000 -0600 @@ -16,11 +16,11 @@ struct netpoll { struct net_device *dev; char dev_name[16], *name; + int rx_flags; void (*rx_hook)(struct netpoll *, int, char *, int); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; - struct list_head rx_list; }; void netpoll_poll(struct netpoll *np); @@ -35,7 +35,7 @@ #ifdef CONFIG_NETPOLL static inline int netpoll_rx(struct sk_buff *skb) { - return skb->dev->netpoll_rx && __netpoll_rx(skb); + return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } #else #define netpoll_rx(a) 0 From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:49 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTXa032235 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PJjs006752; Thu, 17 Feb 2005 23:25:19 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20dj-0000kk-00; Thu, 17 Feb 2005 23:25:19 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <4.378217222@selenic.com> Message-Id: <5.378217222@selenic.com> Subject: [PATCH 4/6] netpoll: fix ->poll() locking Date: Thu, 17 Feb 2005 23:25:19 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1782 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: 4289 Lines: 149 Introduce a per-client poll lock and flag. The lock assures we never have more than one caller in dev->poll(). The flag provides recursion avoidance on UP where the lock disappears. Signed-off-by: Matt Mackall Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:39:59.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:02.000000000 -0600 @@ -36,7 +36,6 @@ static struct sk_buff *skbs; static atomic_t trapped; -static DEFINE_SPINLOCK(netpoll_poll_lock); #define NETPOLL_RX_ENABLED 1 #define NETPOLL_RX_DROP 2 @@ -63,8 +62,15 @@ } /* - * Check whether delayed processing was scheduled for our current CPU, - * and then manually invoke NAPI polling to pump data off the card. + * Check whether delayed processing was scheduled for our NIC. If so, + * we attempt to grab the poll lock and use ->poll() to pump the card. + * If this fails, either we've recursed in ->poll() or it's already + * running on another CPU. + * + * Note: we don't mask interrupts with this lock because we're using + * trylock here and interrupts are already disabled in the softirq + * case. Further, we test the poll_owner to avoid recursion on UP + * systems where the lock doesn't exist. * * In cases where there is bi-directional communications, reading only * one message at a time can lead to packets being dropped by the @@ -74,13 +80,10 @@ static void poll_napi(struct netpoll *np) { int budget = 16; - unsigned long flags; - struct softnet_data *queue; - spin_lock_irqsave(&netpoll_poll_lock, flags); - queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && - !list_empty(&queue->poll_list)) { + np->poll_owner != __smp_processor_id() && + spin_trylock(&np->poll_lock)) { np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); @@ -88,8 +91,8 @@ atomic_dec(&trapped); np->rx_flags &= ~NETPOLL_RX_DROP; + spin_unlock(&np->poll_lock); } - spin_unlock_irqrestore(&netpoll_poll_lock, flags); } void netpoll_poll(struct netpoll *np) @@ -194,6 +197,12 @@ return; } + /* avoid ->poll recursion */ + if(np->poll_owner == __smp_processor_id()) { + __kfree_skb(skb); + return; + } + spin_lock(&np->dev->xmit_lock); np->dev->xmit_lock_owner = smp_processor_id(); @@ -542,6 +551,9 @@ struct net_device *ndev = NULL; struct in_device *in_dev; + np->poll_lock = SPIN_LOCK_UNLOCKED; + np->poll_owner = -1; + if (np->dev_name) ndev = dev_get_by_name(np->dev_name); if (!ndev) { Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:39:59.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:40:02.000000000 -0600 @@ -21,6 +21,8 @@ u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; + spinlock_t poll_lock; + int poll_owner; }; void netpoll_poll(struct netpoll *np); @@ -37,8 +39,27 @@ { return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } + +static inline void netpoll_poll_lock(struct net_device *dev) +{ + if (dev->np) { + spin_lock(&dev->np->poll_lock); + dev->np->poll_owner = __smp_processor_id(); + } +} + +static inline void netpoll_poll_unlock(struct net_device *dev) +{ + if (dev->np) { + spin_unlock(&dev->np->poll_lock); + dev->np->poll_owner = -1; + } +} + #else #define netpoll_rx(a) 0 +#define netpoll_poll_lock(a) +#define netpoll_poll_unlock(a) #endif #endif Index: rc4/net/core/dev.c =================================================================== --- rc4.orig/net/core/dev.c 2005-02-17 22:39:59.000000000 -0600 +++ rc4/net/core/dev.c 2005-02-17 22:40:02.000000000 -0600 @@ -1775,8 +1775,10 @@ dev = list_entry(queue->poll_list.next, struct net_device, poll_list); + netpoll_poll_lock(dev); if (dev->quota <= 0 || dev->poll(dev, &budget)) { + netpoll_poll_unlock(dev); local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); @@ -1785,6 +1787,7 @@ else dev->quota = dev->weight; } else { + netpoll_poll_unlock(dev); dev_put(dev); local_irq_disable(); } From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:47 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTwK032234 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PJP2006763; Thu, 17 Feb 2005 23:25:19 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20dj-0000kk-01; Thu, 17 Feb 2005 23:25:19 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <5.378217222@selenic.com> Message-Id: <6.378217222@selenic.com> Subject: [PATCH 5/6] netpoll: add optional dropping and queueing support Date: Thu, 17 Feb 2005 23:25:19 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1779 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: 3690 Lines: 145 This adds a callback for packets we can't deliver immediately and a helper function for clients to queue such packets to the device post-interrupt. Netconsole is modified to use the queueing function for best-effort delivery. Signed-off-by: Matt Mackall Index: rc4/drivers/net/netconsole.c =================================================================== --- rc4.orig/drivers/net/netconsole.c 2005-02-17 22:39:29.000000000 -0600 +++ rc4/drivers/net/netconsole.c 2005-02-17 22:40:05.000000000 -0600 @@ -60,6 +60,7 @@ .local_port = 6665, .remote_port = 6666, .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, + .drop = netpoll_queue, }; static int configured = 0; Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:40:02.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:05.000000000 -0600 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -28,13 +29,18 @@ * message gets out even in extreme OOM situations. */ -#define MAX_SKBS 32 #define MAX_UDP_CHUNK 1460 +#define MAX_SKBS 32 +#define MAX_QUEUE_DEPTH (MAX_SKBS / 2) static DEFINE_SPINLOCK(skb_list_lock); static int nr_skbs; static struct sk_buff *skbs; +static DEFINE_SPINLOCK(queue_lock); +static int queue_depth; +static struct sk_buff *queue_head, *queue_tail; + static atomic_t trapped; #define NETPOLL_RX_ENABLED 1 @@ -46,6 +52,50 @@ static void zap_completion_queue(void); +static void queue_process(void *p) +{ + unsigned long flags; + struct sk_buff *skb; + + while (queue_head) { + spin_lock_irqsave(&queue_lock, flags); + + skb = queue_head; + queue_head = skb->next; + if (skb == queue_tail) + queue_head = NULL; + + queue_depth--; + + spin_unlock_irqrestore(&queue_lock, flags); + + dev_queue_xmit(skb); + } +} + +static DECLARE_WORK(send_queue, queue_process, NULL); + +void netpoll_queue(struct sk_buff *skb) +{ + unsigned long flags; + + if (queue_depth == MAX_QUEUE_DEPTH) { + __kfree_skb(skb); + return; + } + + spin_lock_irqsave(&queue_lock, flags); + if (!queue_head) + queue_head = skb; + else + queue_tail->next = skb; + queue_tail = skb; + queue_depth++; + spin_unlock_irqrestore(&queue_lock, flags); + + schedule_work(&send_queue); +} + static int checksum_udp(struct sk_buff *skb, struct udphdr *uh, unsigned short ulen, u32 saddr, u32 daddr) { @@ -199,7 +249,10 @@ /* avoid ->poll recursion */ if(np->poll_owner == __smp_processor_id()) { - __kfree_skb(skb); + if (np->drop) + np->drop(skb); + else + __kfree_skb(skb); return; } @@ -275,6 +328,8 @@ memcpy(eth->h_source, np->local_mac, 6); memcpy(eth->h_dest, np->remote_mac, 6); + skb->dev = np->dev; + netpoll_send_skb(np, skb); } Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:40:02.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:40:05.000000000 -0600 @@ -18,6 +18,7 @@ char dev_name[16], *name; int rx_flags; void (*rx_hook)(struct netpoll *, int, char *, int); + void (*drop)(struct sk_buff *skb); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; @@ -33,6 +34,7 @@ void netpoll_set_trap(int trap); void netpoll_cleanup(struct netpoll *np); int __netpoll_rx(struct sk_buff *skb); +void netpoll_queue(struct sk_buff *skb); #ifdef CONFIG_NETPOLL static inline int netpoll_rx(struct sk_buff *skb) From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:46 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTsA032232 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PIJx006737; Thu, 17 Feb 2005 23:25:18 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20di-0000kk-00; Thu, 17 Feb 2005 23:25:18 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer Message-Id: <1.378217222@selenic.com> Subject: [PATCH 0/6] netpoll: recursion fixes, queueing, and cleanups Date: Thu, 17 Feb 2005 23:25:18 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1777 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: 220 Lines: 5 This patch series against -rc4 fixes up some recursion deadlocks in netpoll and adds support for fallback to queueing. Various cleanups along the way. Holds up under load testing via ipt_LOG on a dual Opteron with tg3. From mpm@selenic.com Thu Feb 17 21:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:46 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PTL0032233 for ; Thu, 17 Feb 2005 21:25:30 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PInG006739; Thu, 17 Feb 2005 23:25:18 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20di-0000kk-01; Thu, 17 Feb 2005 23:25:18 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <1.378217222@selenic.com> Message-Id: <2.378217222@selenic.com> Subject: [PATCH 1/6] netpoll: shorten carrier detect timeout Date: Thu, 17 Feb 2005 23:25:18 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1778 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: 844 Lines: 26 Shorten carrier detect timeout to 4 seconds. Signed-off-by: Matt Mackall Index: tiny-new/net/core/netpoll.c =================================================================== --- tiny-new.orig/net/core/netpoll.c 2004-11-17 00:05:28.000000000 -0800 +++ tiny-new/net/core/netpoll.c 2004-12-02 11:51:15.775256063 -0800 @@ -584,7 +584,7 @@ rtnl_shunlock(); atleast = jiffies + HZ/10; - atmost = jiffies + 10*HZ; + atmost = jiffies + 4*HZ; while (!netif_carrier_ok(ndev)) { if (time_after(jiffies, atmost)) { printk(KERN_NOTICE @@ -597,7 +597,7 @@ if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," - " waiting 10 seconds\n", + " waiting 4 seconds\n", np->name); while (time_before(jiffies, atmost)) cond_resched(); From mpm@selenic.com Thu Feb 17 21:25:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 21:25:48 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I5PVem032237 for ; Thu, 17 Feb 2005 21:25:32 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1I5PI7S006741; Thu, 17 Feb 2005 23:25:18 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D20di-0000kk-02; Thu, 17 Feb 2005 23:25:18 -0600 From: Matt Mackall To: "David S. Miller" X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <2.378217222@selenic.com> Message-Id: <3.378217222@selenic.com> Subject: [PATCH 2/6] netpoll: filter inlines Date: Thu, 17 Feb 2005 23:25:18 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1781 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: 2470 Lines: 95 Add netpoll rx helpers Move skb_free for rx into __netpoll_rx Signed-off-by: Matt Mackall Index: rc4bk2/net/core/netpoll.c =================================================================== --- rc4bk2.orig/net/core/netpoll.c 2005-02-14 10:34:12.000000000 -0800 +++ rc4bk2/net/core/netpoll.c 2005-02-14 17:10:34.000000000 -0800 @@ -368,7 +368,7 @@ netpoll_send_skb(np, send_skb); } -int netpoll_rx(struct sk_buff *skb) +int __netpoll_rx(struct sk_buff *skb) { int proto, len, ulen; struct iphdr *iph; @@ -440,12 +440,18 @@ (char *)(uh+1), ulen - sizeof(struct udphdr)); + kfree_skb(skb); return 1; } spin_unlock_irqrestore(&rx_list_lock, flags); out: - return atomic_read(&trapped); + if (atomic_read(&trapped)) { + kfree_skb(skb); + return 1; + } + + return 0; } int netpoll_parse_options(struct netpoll *np, char *opt) Index: rc4bk2/include/linux/netpoll.h =================================================================== --- rc4bk2.orig/include/linux/netpoll.h 2005-02-14 10:34:08.000000000 -0800 +++ rc4bk2/include/linux/netpoll.h 2005-02-14 17:10:34.000000000 -0800 @@ -30,7 +30,15 @@ int netpoll_trap(void); void netpoll_set_trap(int trap); void netpoll_cleanup(struct netpoll *np); -int netpoll_rx(struct sk_buff *skb); +int __netpoll_rx(struct sk_buff *skb); +#ifdef CONFIG_NETPOLL +static inline int netpoll_rx(struct sk_buff *skb) +{ + return skb->dev->netpoll_rx && __netpoll_rx(skb); +} +#else +#define netpoll_rx(a) 0 +#endif #endif Index: rc4bk2/net/core/dev.c =================================================================== --- rc4bk2.orig/net/core/dev.c 2005-02-14 10:34:12.000000000 -0800 +++ rc4bk2/net/core/dev.c 2005-02-14 17:10:34.000000000 -0800 @@ -1427,13 +1427,10 @@ struct softnet_data *queue; unsigned long flags; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && netpoll_rx(skb)) { - kfree_skb(skb); + /* if netpoll wants it, pretend we never saw it */ + if (netpoll_rx(skb)) return NET_RX_DROP; - } -#endif - + if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); @@ -1629,12 +1626,9 @@ int ret = NET_RX_DROP; unsigned short type; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && skb->dev->poll && netpoll_rx(skb)) { - kfree_skb(skb); + /* if we've gotten here through NAPI, check netpoll */ + if (skb->dev->poll && netpoll_rx(skb)) return NET_RX_DROP; - } -#endif if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); From shivakumar.chetan@gmail.com Thu Feb 17 23:19:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Feb 2005 23:19:54 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I7Jnw7009933 for ; Thu, 17 Feb 2005 23:19:49 -0800 Received: by wproxy.gmail.com with SMTP id 68so493332wra for ; Thu, 17 Feb 2005 23:19:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Cd+GCT+i3FD3Px5wStZmZAjSgR5yI9eCt4RdG99+ZSY4JX2yU0rYxBKtxK80P6rSLTsVbyB/rgim5/lEHC7CNKkvtTdSn5zjSdX4VSiA+VgxFIqAvwpRlHt83ItWHsuaDdJ/z/2SCf7R3+jqUJ4EtYl0Nq0hTJRC5QdcnYM47hA= Received: by 10.54.27.63 with SMTP id a63mr221186wra; Thu, 17 Feb 2005 23:19:43 -0800 (PST) Received: by 10.54.39.8 with HTTP; Thu, 17 Feb 2005 23:19:43 -0800 (PST) Message-ID: <17fe83cb050217231925c43a8e@mail.gmail.com> Date: Fri, 18 Feb 2005 12:49:43 +0530 From: Chetan Kumar Reply-To: Chetan Kumar To: Asim Shankar Subject: Re: Some query on ingress policing Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb5050217150642addd71@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <17fe83cb0502160349a4190d1@mail.gmail.com> <17fe83cb05021616323c3dab@mail.gmail.com> <7bca1cb5050217150642addd71@mail.gmail.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shivakumar.chetan@gmail.com Precedence: bulk X-list: netdev Content-Length: 1438 Lines: 34 Yes, That is the point. Now since the ingress policing is done in net_rx_action (i.e) after queueing the packet on the input queue, the packet which was misbehaving would have used the queue resources. One would drop the packet only after you clear the backlog queue, and a greedy flow could potentially over-run the buffer of well behaved flows. Also another serious issues is that if I ever want to provide priority for the VOIP traffic, that is not feasible since the backlog queue is drained in a FIFO manner. On Thu, 17 Feb 2005 17:06:13 -0600, Asim Shankar wrote: > > I was going thro the packet journey thro the network stack in Linux. > > Now if I want enable ingress policing, it looks like packet > > classification and policing should happen in netif_rx (i.e in the > > interrupt context) before packet is queued on to the input queue am I > > missing something. > > My understanding is that ingress policing (the > qdisc_ingress->enqueue() call) is done in the softint. See > netif_receive_skb() for a call to ing_filter(). > > Alternatively, if CONFIG_NET_CLS_ACT=n and CONFIG_NETFILTER=y then the > policing happens as an NF_IP_PRE_ROUTING netfilter hook instead. > > Also, netif_rx() is not the single point of entry for skb's to the > stack. NAPI drivers are polled for packets, so packets aren't always > picked up from the NIC in the interrupt context. > > Hope that helps, > > -- Asim > From herbert@gondor.apana.org.au Fri Feb 18 01:54:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 01:54:45 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1I9sYZv023489 for ; Fri, 18 Feb 2005 01:54:35 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D24pw-0002zH-00; Fri, 18 Feb 2005 20:54:12 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D24pV-00052u-00; Fri, 18 Feb 2005 20:53:45 +1100 Date: Fri, 18 Feb 2005 20:53:44 +1100 To: "David S. Miller" Cc: Patrick McHardy , netdev@oss.sgi.com Subject: Re: [XFRM]: Always reroute in tunnel mode Message-ID: <20050218095344.GA19307@gondor.apana.org.au> References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> <42150B36.5080609@trash.net> <20050217221031.GA4554@gondor.apana.org.au> <42152283.4030800@trash.net> <20050217151122.098c6def.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050217151122.098c6def.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1674 Lines: 43 On Thu, Feb 17, 2005 at 03:11:22PM -0800, David S. Miller wrote: > > I have to side with Patrick on this one. OK. > This is one of the fundamental tunnel behavior differences between > Transport mode and Tunnel mode SAs. I don't see it that way. To me IPsec is about encapsulating a packet so that it gets to the destination securely. It shouldn't affect the routing of the packet on the host itself. Of course, once the packet leaves the host the IPsec encapsulation will certainly affect its routing. In this respect, the difference between transport mode SAs and tunnel mode SAs is simply that one adds an IP header while the other doesn't. Ideally I should be able to only look at the routing table and determine which interface/gateway a packet is going to be sent through. As it is I need to look at the routing table plus the IPsec database. Put it another way, my solution to Patrick's inconsistency would be to always inherit the routing decision from the top to the bottom of the bundle. For example, suppose you had ip ro add 192.168.0.0/16 \ nexthop via 10.0.0.1 dev eth0 \ nexthop via 10.0.0.2 dev eth0 Then the packets to 192.168.0.0/16 should be sent via 10.0.0.1/10.0.0.2 regardless of what IPsec protections are applied to it. This is something that can't be done in a clean way with the current setup. I'd like to see that available in Linux at some point. It'll have to be optional of course (selectable per-policy). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Feb 18 02:09:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 02:09:32 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IA9L11025028 for ; Fri, 18 Feb 2005 02:09:24 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D254R-00034E-00; Fri, 18 Feb 2005 21:09:11 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D254A-00054U-00; Fri, 18 Feb 2005 21:08:54 +1100 Date: Fri, 18 Feb 2005 21:08:54 +1100 To: Patrick McHardy Cc: Maillist netdev Subject: Re: IPsec xfrm resolution Message-ID: <20050218100854.GA19427@gondor.apana.org.au> References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42152841.5000707@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2080 Lines: 47 On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote: > > Yes, this part is simple. There's one thing I think we need to do > slightly different from what you describe. The current behaviour is > to resolve one SA at a time, we should keep it this way because we > may need an early SA in the bundle for a different policy to resolve > a follow-up SA for nested tunnels with different peers where the > second peer is only reachable through a tunnel to the first peer. Agreed. This doesn't stop us from creating the bundle object of course. > I'm not sure yet how to deal with optional SAs. We shouldn't add > incomplete optional tunnel mode SAs to the bundle because then we > can't determine the output device, but if we don't nothing will > trigger resolving of optional SAs following a non-optional SA that > needs to be resolved. I don't get it. Can't you just add it into the bundle but ignore it for dst->output and other calculations until it's either realised or removed? > I thought about adding the queue to the xfrm_dst and adding a dummy > xfrm_state with a selector that matches only the current flow. This The inner flow is probably not the best key for this. How about keying it using the outer remote address on the template? The SAs have a bydst hash which makes this easy to look up. So we would attach each packet to a queue shared by all SAs to a specific (outer) remote address. > Finding all queues affected by ADDSA/UPDATESA is not easy. A SA > installed in response to an acquire request doesn't need to match > the one requested, so theoretically states waiting on different > larval states SAs might be able to use it. I don't think we have > much choice other than looking at all incomplete bundles (or > one per flow) on SADB changes. If you key it on the remote address then you only have to look up those. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Fri Feb 18 02:23:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 02:23:28 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IANMXS026438 for ; Fri, 18 Feb 2005 02:23:22 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D655D33CC2; Fri, 18 Feb 2005 19:24:36 +0900 (JST) Date: Fri, 18 Feb 2005 19:24:30 +0900 (JST) Message-Id: <20050218.192430.98634850.yoshfuji@linux-ipv6.org> To: torvalds@osdl.org, akpm@osdl.org, davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [IPV4] Fix ip_rt_gc_min_interval_ms procfs/sysctl 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1787 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: 7325 Lines: 242 Hello, Linus, Andrew and David; Recently, we added gc_min_interval_ms procfs/sysctl. Because type of ip_rt_gc_min_interval is int, use of ulong helpers is inappropriate and unsafe. I believe it breaks some archs that the size of unsigned long is not equal to one of int. So, let's add new sysctl helpers and use them instead. This also fixes inconsistency between procfs and sysctl. Please pull following changesets available at into 2.6.11 tree. Thanks. P.S. I will send several changesets to add other users (neighbour and ipv6 routing) after 2.6.12 opens. HEADLINES --------- ChangeSet@1.2063, 2005-02-18 18:23:43+09:00, yoshfuji@linux-ipv6.org add sysctl helper functions to provide milliseconds-based interfaces. ChangeSet@1.2064, 2005-02-18 18:54:30+09:00, yoshfuji@linux-ipv6.org [IPV4] Use appropriate sysctl helpers for gc_min_interval_ms. DIFFSTATS --------- include/linux/sysctl.h | 3 + kernel/sysctl.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++ net/ipv4/route.c | 6 +-- 3 files changed, 97 insertions(+), 3 deletions(-) CHANGESETS ---------- ChangeSet@1.2063, 2005-02-18 18:23:43+09:00, yoshfuji@linux-ipv6.org add sysctl helper functions to provide milliseconds-based interfaces. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-02-18 18:55:25 +09:00 +++ b/include/linux/sysctl.h 2005-02-18 18:55:25 +09:00 @@ -796,6 +796,8 @@ void __user *, size_t *, loff_t *); extern int proc_dointvec_userhz_jiffies(ctl_table *, int, struct file *, void __user *, size_t *, loff_t *); +extern int proc_dointvec_ms_jiffies(ctl_table *, int, struct file *, + void __user *, size_t *, loff_t *); extern int proc_doulongvec_minmax(ctl_table *, int, struct file *, void __user *, size_t *, loff_t *); extern int proc_doulongvec_ms_jiffies_minmax(ctl_table *table, int, @@ -813,6 +815,7 @@ extern ctl_handler sysctl_string; extern ctl_handler sysctl_intvec; extern ctl_handler sysctl_jiffies; +extern ctl_handler sysctl_ms_jiffies; /* diff -Nru a/kernel/sysctl.c b/kernel/sysctl.c --- a/kernel/sysctl.c 2005-02-18 18:55:25 +09:00 +++ b/kernel/sysctl.c 2005-02-18 18:55:25 +09:00 @@ -1902,6 +1902,27 @@ return 0; } +static int do_proc_dointvec_ms_jiffies_conv(int *negp, unsigned long *lvalp, + int *valp, + int write, void *data) +{ + if (write) { + *valp = msecs_to_jiffies(*negp ? -*lvalp : *lvalp); + } else { + int val = *valp; + unsigned long lval; + if (val < 0) { + *negp = -1; + lval = (unsigned long)-val; + } else { + *negp = 0; + lval = (unsigned long)val; + } + *lvalp = jiffies_to_msecs(lval); + } + return 0; +} + /** * proc_dointvec_jiffies - read a vector of integers as seconds * @table: the sysctl table @@ -1946,6 +1967,28 @@ do_proc_dointvec_userhz_jiffies_conv,NULL); } +/** + * proc_dointvec_ms_jiffies - read a vector of integers as 1 milliseconds + * @table: the sysctl table + * @write: %TRUE if this is a write to the sysctl file + * @filp: the file structure + * @buffer: the user buffer + * @lenp: the size of the user buffer + * + * Reads/writes up to table->maxlen/sizeof(unsigned int) integer + * values from/to the user buffer, treated as an ASCII string. + * The values read are assumed to be in 1/1000 seconds, and + * are converted into jiffies. + * + * Returns 0 on success. + */ +int proc_dointvec_ms_jiffies(ctl_table *table, int write, struct file *filp, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + return do_proc_dointvec(table, write, filp, buffer, lenp, ppos, + do_proc_dointvec_ms_jiffies_conv, NULL); +} + #else /* CONFIG_PROC_FS */ int proc_dostring(ctl_table *table, int write, struct file *filp, @@ -1990,6 +2033,12 @@ return -ENOSYS; } +int proc_dointvec_ms_jiffies(ctl_table *table, int write, struct file *filp, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + return -ENOSYS; +} + int proc_doulongvec_minmax(ctl_table *table, int write, struct file *filp, void __user *buffer, size_t *lenp, loff_t *ppos) { @@ -2119,6 +2168,33 @@ return 1; } +/* Strategy function to convert jiffies to seconds */ +int sysctl_ms_jiffies(ctl_table *table, int __user *name, int nlen, + void __user *oldval, size_t __user *oldlenp, + void __user *newval, size_t newlen, void **context) +{ + if (oldval) { + size_t olen; + if (oldlenp) { + if (get_user(olen, oldlenp)) + return -EFAULT; + if (olen!=sizeof(int)) + return -EINVAL; + } + if (put_user(jiffies_to_msecs(*(int *)(table->data)), (int __user *)oldval) || + (oldlenp && put_user(sizeof(int),oldlenp))) + return -EFAULT; + } + if (newval && newlen) { + int new; + if (newlen != sizeof(int)) + return -EINVAL; + if (get_user(new, (int __user *)newval)) + return -EFAULT; + *(int *)(table->data) = msecs_to_jiffies(new); + } + return 1; +} #else /* CONFIG_SYSCTL */ @@ -2149,6 +2225,13 @@ return -ENOSYS; } +int sysctl_ms_jiffies(ctl_table *table, int __user *name, int nlen, + void __user *oldval, size_t __user *oldlenp, + void __user *newval, size_t newlen, void **context) +{ + return -ENOSYS; +} + int proc_dostring(ctl_table *table, int write, struct file *filp, void __user *buffer, size_t *lenp, loff_t *ppos) { @@ -2185,6 +2268,12 @@ return -ENOSYS; } +int proc_dointvec_ms_jiffies(ctl_table *table, int write, struct file *filp, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + return -ENOSYS; +} + int proc_doulongvec_minmax(ctl_table *table, int write, struct file *filp, void __user *buffer, size_t *lenp, loff_t *ppos) { @@ -2219,11 +2308,13 @@ EXPORT_SYMBOL(proc_dointvec_jiffies); EXPORT_SYMBOL(proc_dointvec_minmax); EXPORT_SYMBOL(proc_dointvec_userhz_jiffies); +EXPORT_SYMBOL(proc_dointvec_ms_jiffies); EXPORT_SYMBOL(proc_dostring); EXPORT_SYMBOL(proc_doulongvec_minmax); EXPORT_SYMBOL(proc_doulongvec_ms_jiffies_minmax); EXPORT_SYMBOL(register_sysctl_table); EXPORT_SYMBOL(sysctl_intvec); EXPORT_SYMBOL(sysctl_jiffies); +EXPORT_SYMBOL(sysctl_ms_jiffies); EXPORT_SYMBOL(sysctl_string); EXPORT_SYMBOL(unregister_sysctl_table); ChangeSet@1.2064, 2005-02-18 18:54:30+09:00, yoshfuji@linux-ipv6.org [IPV4] Use appropriate sysctl helpers for gc_min_interval_ms. Because its type is int, inappropriate to use ulong helpers. This also fixes inconsistency between sysctl and procfs. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c 2005-02-18 18:55:29 +09:00 +++ b/net/ipv4/route.c 2005-02-18 18:55:29 +09:00 @@ -2545,10 +2545,10 @@ .ctl_name = NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS, .procname = "gc_min_interval_ms", .data = &ip_rt_gc_min_interval, - .maxlen = sizeof(unsigned long), + .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_doulongvec_ms_jiffies_minmax, - .strategy = &sysctl_jiffies, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, }, { .ctl_name = NET_IPV4_ROUTE_GC_TIMEOUT, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Fri Feb 18 02:49:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 02:49:47 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IAng36030445 for ; Fri, 18 Feb 2005 02:49:42 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1IAnRqi030403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Feb 2005 02:49:28 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1IAnQ7g015440; Fri, 18 Feb 2005 02:49:26 -0800 Date: Fri, 18 Feb 2005 02:49:17 -0800 From: Andrew Morton To: YOSHIFUJI Hideaki Cc: torvalds@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [IPV4] Fix ip_rt_gc_min_interval_ms procfs/sysctl Message-Id: <20050218024917.2e5c19ec.akpm@osdl.org> In-Reply-To: <20050218.192430.98634850.yoshfuji@linux-ipv6.org> References: <20050218.192430.98634850.yoshfuji@linux-ipv6.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=ISO-8859-1 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1IAng36030445 X-archive-position: 1788 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: 925 Lines: 23 YOSHIFUJI Hideaki / ____________ wrote: > > Recently, we added gc_min_interval_ms procfs/sysctl. > > Because type of ip_rt_gc_min_interval is int, > use of ulong helpers is inappropriate and unsafe. > I believe it breaks some archs that the size of unsigned long > is not equal to one of int. > > So, let's add new sysctl helpers and use them instead. > This also fixes inconsistency between procfs and sysctl. I disagree. ip_rt_gc_min_interval is an `int' and does not need to be changed to `long' - note how is is always used as a time delta. So the current code works OK. However it is rather poor design, because it exposes the value of jiffies to userspace. So the user and his scripts need to know what the machine's current HZ value is to set this tunable sanely. A better approach wold be to rework ip_rt_gc_min_interval so that its userspace-visible units are milliseconds. From yoshfuji@linux-ipv6.org Fri Feb 18 02:58:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 02:58:12 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IAw7Ni031568 for ; Fri, 18 Feb 2005 02:58:08 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 72D0C33CC2; Fri, 18 Feb 2005 19:59:20 +0900 (JST) Date: Fri, 18 Feb 2005 19:59:13 +0900 (JST) Message-Id: <20050218.195913.07287814.yoshfuji@linux-ipv6.org> To: akpm@osdl.org Cc: torvalds@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [IPV4] Fix ip_rt_gc_min_interval_ms procfs/sysctl From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050218024917.2e5c19ec.akpm@osdl.org> References: <20050218.192430.98634850.yoshfuji@linux-ipv6.org> <20050218024917.2e5c19ec.akpm@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1789 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: 1303 Lines: 36 In article <20050218024917.2e5c19ec.akpm@osdl.org> (at Fri, 18 Feb 2005 02:49:17 -0800), Andrew Morton says: > YOSHIFUJI Hideaki / ____________ wrote: > > > > Recently, we added gc_min_interval_ms procfs/sysctl. > > > > Because type of ip_rt_gc_min_interval is int, > > use of ulong helpers is inappropriate and unsafe. > > I believe it breaks some archs that the size of unsigned long > > is not equal to one of int. > > > > So, let's add new sysctl helpers and use them instead. > > This also fixes inconsistency between procfs and sysctl. > > I disagree. ip_rt_gc_min_interval is an `int' and does not need to be > changed to `long' - note how is is always used as a time delta. I'm not suggesting to use ulong helpers. The type of variable (ip_rt_gc_min_interval) is int, and we erroneously started using ulong helpers for it. This break memory. So, I suggest to use appropriate helpers. > A better approach wold be to rework ip_rt_gc_min_interval so that its > userspace-visible units are milliseconds. My patch add a sysctl/procfs helpers to convert units between milliseconds and jiffies. Do you still disagree? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Fri Feb 18 03:02:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 03:03:00 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IB2tgF032260 for ; Fri, 18 Feb 2005 03:02:55 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1IB2bqi031379 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Feb 2005 03:02:37 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1IB2WmT015592; Fri, 18 Feb 2005 03:02:34 -0800 Date: Fri, 18 Feb 2005 03:02:22 -0800 From: Andrew Morton To: yoshfuji@linux-ipv6.org, torvalds@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [IPV4] Fix ip_rt_gc_min_interval_ms procfs/sysctl Message-Id: <20050218030222.51fcc83f.akpm@osdl.org> In-Reply-To: <20050218024917.2e5c19ec.akpm@osdl.org> References: <20050218.192430.98634850.yoshfuji@linux-ipv6.org> <20050218024917.2e5c19ec.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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1790 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: 1397 Lines: 41 Andrew Morton wrote: > > A better approach wold be to rework ip_rt_gc_min_interval so that its > userspace-visible units are milliseconds. We are doing, via gc_min_interval_ms. Funny thing is, sysctl table is treating ip_rt_gc_min_interval as a long, and it isn't. I wonder if the current code works correctly on 64-bit big-endian. Seems to me a simpler fix would be to make it a long? diff -puN net/ipv4/route.c~a net/ipv4/route.c --- 25/net/ipv4/route.c~a 2005-02-18 02:58:19.000000000 -0800 +++ 25-akpm/net/ipv4/route.c 2005-02-18 03:01:30.000000000 -0800 @@ -113,7 +113,7 @@ static int ip_rt_max_delay = 10 * HZ; static int ip_rt_max_size; static int ip_rt_gc_timeout = RT_GC_TIMEOUT; static int ip_rt_gc_interval = 60 * HZ; -static int ip_rt_gc_min_interval = HZ / 2; +static long ip_rt_gc_min_interval = HZ / 2; static int ip_rt_redirect_number = 9; static int ip_rt_redirect_load = HZ / 50; static int ip_rt_redirect_silence = ((HZ / 50) << (9 + 1)); @@ -2536,9 +2536,9 @@ ctl_table ipv4_route_table[] = { .ctl_name = NET_IPV4_ROUTE_GC_MIN_INTERVAL, .procname = "gc_min_interval", .data = &ip_rt_gc_min_interval, - .maxlen = sizeof(int), + .maxlen = sizeof(long), .mode = 0644, - .proc_handler = &proc_dointvec_jiffies, + .proc_handler = &proc_doulongvec_minmax, .strategy = &sysctl_jiffies, }, { _ From akpm@osdl.org Fri Feb 18 03:10:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 03:10:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IBABdN000686 for ; Fri, 18 Feb 2005 03:10:11 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1IBA0qi031916 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Feb 2005 03:10:01 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1IB9xRd015720; Fri, 18 Feb 2005 03:09:59 -0800 Date: Fri, 18 Feb 2005 03:09:50 -0800 From: Andrew Morton To: yoshfuji@linux-ipv6.org, torvalds@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [IPV4] Fix ip_rt_gc_min_interval_ms procfs/sysctl Message-Id: <20050218030950.02d628cf.akpm@osdl.org> In-Reply-To: <20050218030222.51fcc83f.akpm@osdl.org> References: <20050218.192430.98634850.yoshfuji@linux-ipv6.org> <20050218024917.2e5c19ec.akpm@osdl.org> <20050218030222.51fcc83f.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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1791 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: 242 Lines: 8 Andrew Morton wrote: > > Seems to me a simpler fix would be to make it a long? That doesn't work either, does it? gc_min_interval is in seconds. OK, I give up - we need a whole batch of new conversion functions. How sad. From herbert@gondor.apana.org.au Fri Feb 18 03:23:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 03:23:42 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IBNTGT001807 for ; Fri, 18 Feb 2005 03:23:32 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D26De-0003RF-00; Fri, 18 Feb 2005 22:22:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D26BP-0005Lg-00; Fri, 18 Feb 2005 22:20:27 +1100 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot Cc: netdev@oss.sgi.com, mangus@deprecated.it, jgarzik@pobox.com, webvenza@libero.it Organization: Core In-Reply-To: <20050217134440.44f591e2.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 18 Feb 2005 22:20:27 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4880 Lines: 154 > Feb 15 18:26:20 saturno kernel: Unable to handle kernel NULL pointer > dereference at virtual address 0000000e > Feb 15 18:26:20 saturno kernel: printing eip: > Feb 15 18:26:20 saturno kernel: e1113417 > Feb 15 18:26:20 saturno kernel: *pde = 00000000 > Feb 15 18:26:20 saturno kernel: Oops: 0000 [#1] > Feb 15 18:26:20 saturno kernel: PREEMPT > Feb 15 18:26:20 saturno kernel: Modules linked in: sis900 nvidia 8250_pci 8250 > serial_core psmouse > Feb 15 18:26:20 saturno kernel: CPU: 0 > Feb 15 18:26:20 saturno kernel: EIP: 0060:[] Tainted: P > VLI > Feb 15 18:26:20 saturno kernel: EFLAGS: 00010296 (2.6.10-M7) > Feb 15 18:26:20 saturno kernel: EIP is at sis900_check_mode+0x17/0xa0 [sis900] OK, this happened because we got preempted before sis900_mii_probe finished setting the sis_priv->mii. Theoretically this can happen with SMP as well but I suppose the number of SMP machines with sis900 is fairly small. Anyway, the fix is to make sure that sis900_mii_probe is done before the device can be opened. This patch does it by moving the setup after register_netdevice into the netdev init function. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== drivers/net/sis900.c 1.62 vs edited ===== --- 1.62/drivers/net/sis900.c 2005-01-11 03:52:27 +11:00 +++ edited/drivers/net/sis900.c 2005-02-18 22:15:13 +11:00 @@ -365,6 +365,48 @@ return 0; } +static int __devinit sis900_init_netdev(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = netdev_priv(net_dev); + struct pci_dev *pci_dev = sis_priv->pci_dev; + long ioaddr = net_dev->base_addr; + struct pci_dev *dev; + int ret; + u8 revision; + + /* Get Mac address according to the chip revision */ + pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); + + if (revision == SIS630E_900_REV) + ret = sis630e_get_mac_addr(pci_dev, net_dev); + else if ((revision > 0x81) && (revision <= 0x90) ) + ret = sis635_get_mac_addr(pci_dev, net_dev); + else if (revision == SIS96x_900_REV) + ret = sis96x_get_mac_addr(pci_dev, net_dev); + else + ret = sis900_get_mac_addr(pci_dev, net_dev); + + if (ret == 0) + return -ENODEV; + + /* 630ET : set the mii access mode as software-mode */ + if (revision == SIS630ET_900_REV) + outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr); + + /* probe for mii transceiver */ + if (sis900_mii_probe(net_dev) == 0) + return -ENODEV; + + /* save our host bridge revision */ + dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); + if (dev) { + pci_read_config_byte(dev, PCI_CLASS_REVISION, &sis_priv->host_bridge_rev); + pci_dev_put(dev); + } + + return 0; +} + /** * sis900_probe - Probe for sis900 device * @pci_dev: the sis900 pci device @@ -381,12 +423,10 @@ { struct sis900_private *sis_priv; struct net_device *net_dev; - struct pci_dev *dev; dma_addr_t ring_dma; void *ring_space; long ioaddr; int i, ret; - u8 revision; char *card_name = card_names[pci_id->driver_data]; /* when built into the kernel, we only print version if device is found */ @@ -456,45 +496,11 @@ net_dev->tx_timeout = sis900_tx_timeout; net_dev->watchdog_timeo = TX_TIMEOUT; net_dev->ethtool_ops = &sis900_ethtool_ops; + net_dev->init = &sis900_init_netdev; ret = register_netdev(net_dev); if (ret) goto err_unmap_rx; - - /* Get Mac address according to the chip revision */ - pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); - ret = 0; - - if (revision == SIS630E_900_REV) - ret = sis630e_get_mac_addr(pci_dev, net_dev); - else if ((revision > 0x81) && (revision <= 0x90) ) - ret = sis635_get_mac_addr(pci_dev, net_dev); - else if (revision == SIS96x_900_REV) - ret = sis96x_get_mac_addr(pci_dev, net_dev); - else - ret = sis900_get_mac_addr(pci_dev, net_dev); - - if (ret == 0) { - ret = -ENODEV; - goto err_out_unregister; - } - - /* 630ET : set the mii access mode as software-mode */ - if (revision == SIS630ET_900_REV) - outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr); - - /* probe for mii transceiver */ - if (sis900_mii_probe(net_dev) == 0) { - ret = -ENODEV; - goto err_out_unregister; - } - - /* save our host bridge revision */ - dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); - if (dev) { - pci_read_config_byte(dev, PCI_CLASS_REVISION, &sis_priv->host_bridge_rev); - pci_dev_put(dev); - } /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, @@ -505,8 +511,6 @@ return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); From klassert@mathematik.tu-chemnitz.de Fri Feb 18 07:57:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 07:57:41 -0800 (PST) Received: from lana.hrz.tu-chemnitz.de (lana.hrz.tu-chemnitz.de [134.109.132.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IFvYdg022084 for ; Fri, 18 Feb 2005 07:57:35 -0800 Received: from bayes.mathematik.tu-chemnitz.de ([134.109.41.17] helo=box17.mathematik.tu-chemnitz.de) by lana.hrz.tu-chemnitz.de with esmtp (Exim 4.41) id 1D2AVX-0001Qz-Ej; Fri, 18 Feb 2005 16:57:31 +0100 Received: by box17.mathematik.tu-chemnitz.de (Postfix, from userid 274) id 41AC4370A9; Fri, 18 Feb 2005 16:57:31 +0100 (CET) Date: Fri, 18 Feb 2005 16:57:31 +0100 From: Steffen Klassert To: Jeff Garzik Cc: Network Development Mailing List Subject: [PATCH] mii_check_media, update link status in any case Message-ID: <20050218155731.GA32352@bayes.mathematik.tu-chemnitz.de> Mail-Followup-To: Jeff Garzik , Network Development Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Scan-Signature: d7bb2b01975254b8f41cda1475e3c4ea X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klassert@mathematik.tu-chemnitz.de Precedence: bulk X-list: netdev Content-Length: 1089 Lines: 33 In some cases it is necessary to check for link and duplex status. This patch changes the behavior of mii_check_media() to update the link status in any case. Signed-off-by: Steffen Klassert --- vanilla-2.6.11-rc4/drivers/net/mii.c Sun Feb 13 04:06:05 2005 +++ linux-2.6.11-rc4/drivers/net/mii.c Fri Feb 18 12:28:14 2005 @@ -208,10 +208,6 @@ unsigned int old_carrier, new_carrier; int advertise, lpa, media, duplex; - /* if forced media, go no further */ - if (mii->force_media) - return 0; /* duplex did not change */ - /* check current and old link status */ old_carrier = netif_carrier_ok(mii->dev) ? 1 : 0; new_carrier = (unsigned int) mii_link_ok(mii); @@ -234,6 +230,13 @@ * we have carrier, see who's on the other end */ netif_carrier_on(mii->dev); + + /* if forced media, go no further */ + if (mii->force_media) { + if (ok_to_print) + printk(KERN_INFO "%s: link up\n", mii->dev->name); + return 0; /* duplex did not change */ + } /* get MII advertise and LPA values */ if ((!init_media) && (mii->advertising)) From mmporter@cox.net Fri Feb 18 09:12:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 09:12:59 -0800 (PST) Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IHCs8j028974 for ; Fri, 18 Feb 2005 09:12:54 -0800 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050218171248.YJKU13353.fed1rmmtao04.cox.net@liberty.homelinux.org>; Fri, 18 Feb 2005 12:12:48 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id KAA11828; Fri, 18 Feb 2005 10:12:47 -0700 Date: Fri, 18 Feb 2005 10:12:46 -0700 From: Matt Porter To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: [PATCH] emac: filter illegal frame sizes Message-ID: <20050218101245.D11439@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 3787 Lines: 116 Fix to drop frames that are too large for the current MTU. Signed-off-by: Matt Porter ===== drivers/net/ibm_emac/ibm_emac_core.c 1.9 vs edited ===== --- 1.9/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 13:25:10 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-18 09:23:08 -07:00 @@ -665,14 +665,21 @@ fep->rx_skb[i]->dev = dev; fep->rx_skb[i]->protocol = eth_type_trans(fep->rx_skb[i], dev); - error = netif_rx(fep->rx_skb[i]); - if ((error == NET_RX_DROP) || - (error == NET_RX_BAD)) { - fep->stats.rx_dropped++; + /* Filter frame sizes > our MTU */ + if (fep->rx_skb[i]->len <= (dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE)) { + error = netif_rx(fep->rx_skb[i]); + if ((error == NET_RX_DROP) || + (error == NET_RX_BAD)) { + fep->stats.rx_dropped++; + } else { + fep->stats.rx_packets++; + fep->stats.rx_bytes += frame_length; + } } else { - fep->stats.rx_packets++; - fep->stats.rx_bytes += frame_length; + dev_kfree_skb(fep->rx_skb[i]); + fep->stats.rx_length_errors++; + fep->stats.rx_errors++; } fep->rx_skb[i] = NULL; } else { @@ -752,15 +759,23 @@ fep->rx_skb[buf[0]]->protocol = eth_type_trans(fep->rx_skb[buf[0]], dev); - error = netif_rx(fep->rx_skb[buf[0]]); - if ((error == NET_RX_DROP) - || (error == NET_RX_BAD)) { - fep->stats.rx_dropped++; + /* Filter frame sizes > our MTU */ + if (fep->rx_skb[buf[0]]->len <= (dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE)) { + error = netif_rx(fep->rx_skb[buf[0]]); + + if ((error == NET_RX_DROP) + || (error == NET_RX_BAD)) { + fep->stats.rx_dropped++; + } else { + fep->stats.rx_packets++; + fep->stats.rx_bytes += + fep->rx_skb[buf[0]]->len; + } } else { - fep->stats.rx_packets++; - fep->stats.rx_bytes += - fep->rx_skb[buf[0]]->len; + fep->stats.rx_length_errors++; + fep->stats.rx_errors++; + dev_kfree_skb(fep->rx_skb[buf[0]]); } for (b = 0; b < bnum; b++) fep->rx_skb[buf[b]] = NULL; @@ -1041,7 +1056,7 @@ /* set speed (default is 10Mb) */ switch (speed) { case SPEED_1000: - mode_reg |= EMAC_M1_JUMBO_ENABLE | EMAC_M1_RFS_16K; + mode_reg |= EMAC_M1_RFS_16K; if (fep->rgmii_dev) { struct ibm_ocp_rgmii *rgmii = RGMII_PRIV(fep->rgmii_dev); @@ -1118,6 +1133,7 @@ { struct ocp_enet_private *fep = dev->priv; int old_mtu = dev->mtu; + unsigned long mode_reg; emac_t *emacp = fep->emacp; u32 em0mr0; int i, full; @@ -1160,10 +1176,17 @@ fep->rx_skb[i] = NULL; } - /* Set new rx_buffer_size and advertise new mtu */ - fep->rx_buffer_size = - new_mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE; + /* Set new rx_buffer_size, jumbo cap, and advertise new mtu */ + mode_reg = in_be32(&emacp->em0mr1); + if (new_mtu > ENET_DEF_MTU_SIZE) { + mode_reg |= EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = EMAC_MAX_FRAME; + } else { + mode_reg &= ~EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = ENET_DEF_BUF_SIZE; + } dev->mtu = new_mtu; + out_be32(&emacp->em0mr1, mode_reg); /* Re-init rx skbs */ fep->rx_slot = 0; ===== drivers/net/ibm_emac/ibm_emac_core.h 1.3 vs edited ===== --- 1.3/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-08 22:24:52 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-18 09:30:07 -07:00 @@ -77,6 +77,8 @@ #define ENET_HEADER_SIZE 14 #define ENET_FCS_SIZE 4 +#define ENET_DEF_MTU_SIZE 1500 +#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE) #define EMAC_MIN_FRAME 64 #define EMAC_MAX_FRAME 9018 #define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE) From webvenza@libero.it Fri Feb 18 10:17:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 10:17:51 -0800 (PST) Received: from gateway.milesteg.arr (venza@adsl-ull-235-84.42-151.net24.it [151.42.84.235]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IIHibR032154 for ; Fri, 18 Feb 2005 10:17:45 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5ce5a5e4fed105451a3b7700bf40b04d@libero.it> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, akpm@osdl.org (Andrew Morton), mangus@deprecated.it, jgarzik@pobox.com From: Daniele Venzano Subject: Re: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot Date: Fri, 18 Feb 2005 19:17:06 +0100 To: Herbert Xu X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 941 Lines: 23 On 18/feb/05, at 12:20, Herbert Xu wrote: > OK, this happened because we got preempted before sis900_mii_probe > finished setting the sis_priv->mii. Theoretically this can happen > with SMP as well but I suppose the number of SMP machines with sis900 > is fairly small. > > Anyway, the fix is to make sure that sis900_mii_probe is done before > the device can be opened. This patch does it by moving the setup > after register_netdevice into the netdev init function. I think the patch is ok, but it will not apply with the latest changes I sent to Jeff Garzik (see . Don't know if this is a problem, since those changes have not yet reached Linus tree. > Signed-off-by: Herbert Xu Signed-off-by: Daniele Venzano -- Daniele Venzano http://teg.homeunix.org From rddunlap@osdl.org Fri Feb 18 13:42:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 13:42:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ILgSeP002291 for ; Fri, 18 Feb 2005 13:42:28 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1ILgDqi019045 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Feb 2005 13:42:14 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1ILgCVU032045; Fri, 18 Feb 2005 13:42:13 -0800 Date: Fri, 18 Feb 2005 13:42:19 -0800 From: "Randy.Dunlap" To: robert.olsson@its.uu.se Cc: netdev Subject: [PATCH] pktgen: reduce stack usage Message-Id: <20050218134219.3f079110.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1796 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: 8379 Lines: 229 (resend) Any comments this time? pktgen: proc_if_write: reduce stack usage (on i386) from 776 to 296 bytes by combining/reusing locals. Signed-off-by: Randy Dunlap diffstat:= net/core/pktgen.c | 94 ++++++++++++++++++++++++------------------------------ 1 files changed, 42 insertions(+), 52 deletions(-) diff -Naurp ./net/core/pktgen.c~pktgen_stack ./net/core/pktgen.c --- ./net/core/pktgen.c~pktgen_stack 2005-01-27 16:31:49.000000000 -0800 +++ ./net/core/pktgen.c 2005-01-30 19:07:55.252712936 -0800 @@ -811,6 +811,8 @@ static int proc_if_write(struct file *fi struct pktgen_dev *pkt_dev = (struct pktgen_dev*)(data); char* pg_result = NULL; int tmp = 0; + char buf4[IP_NAME_SZ]; + char buf6[128]; pg_result = &(pkt_dev->result[0]); @@ -1071,16 +1073,15 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst_min") || !strcmp(name, "dst")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_min) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->dst_min) != 0) { + buf4[len] = 0; + if (strcmp(buf4, pkt_dev->dst_min) != 0) { memset(pkt_dev->dst_min, 0, sizeof(pkt_dev->dst_min)); - strncpy(pkt_dev->dst_min, buf, len); + strncpy(pkt_dev->dst_min, buf4, len); pkt_dev->daddr_min = in_aton(pkt_dev->dst_min); pkt_dev->cur_daddr = pkt_dev->daddr_min; } @@ -1091,17 +1092,16 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_max) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->dst_max) != 0) { + buf4[len] = 0; + if (strcmp(buf4, pkt_dev->dst_max) != 0) { memset(pkt_dev->dst_max, 0, sizeof(pkt_dev->dst_max)); - strncpy(pkt_dev->dst_max, buf, len); + strncpy(pkt_dev->dst_max, buf4, len); pkt_dev->daddr_max = in_aton(pkt_dev->dst_max); pkt_dev->cur_daddr = pkt_dev->daddr_max; } @@ -1112,108 +1112,99 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst6")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + buf6[len] = 0; - scan_ip6(buf, pkt_dev->in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->in6_daddr.s6_addr); + scan_ip6(buf6, pkt_dev->in6_daddr.s6_addr); + fmt_ip6(buf6, pkt_dev->in6_daddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_daddr, &pkt_dev->in6_daddr); if(debug) - printk("pktgen: dst6 set to: %s\n", buf); + printk("pktgen: dst6 set to: %s\n", buf6); i += len; - sprintf(pg_result, "OK: dst6=%s", buf); + sprintf(pg_result, "OK: dst6=%s", buf6); return count; } if (!strcmp(name, "dst6_min")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + buf6[len] = 0; - scan_ip6(buf, pkt_dev->min_in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->min_in6_daddr.s6_addr); + scan_ip6(buf6, pkt_dev->min_in6_daddr.s6_addr); + fmt_ip6(buf6, pkt_dev->min_in6_daddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_daddr, &pkt_dev->min_in6_daddr); if(debug) - printk("pktgen: dst6_min set to: %s\n", buf); + printk("pktgen: dst6_min set to: %s\n", buf6); i += len; - sprintf(pg_result, "OK: dst6_min=%s", buf); + sprintf(pg_result, "OK: dst6_min=%s", buf6); return count; } if (!strcmp(name, "dst6_max")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + buf6[len] = 0; - scan_ip6(buf, pkt_dev->max_in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->max_in6_daddr.s6_addr); + scan_ip6(buf6, pkt_dev->max_in6_daddr.s6_addr); + fmt_ip6(buf6, pkt_dev->max_in6_daddr.s6_addr); if(debug) - printk("pktgen: dst6_max set to: %s\n", buf); + printk("pktgen: dst6_max set to: %s\n", buf6); i += len; - sprintf(pg_result, "OK: dst6_max=%s", buf); + sprintf(pg_result, "OK: dst6_max=%s", buf6); return count; } if (!strcmp(name, "src6")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + buf6[len] = 0; - scan_ip6(buf, pkt_dev->in6_saddr.s6_addr); - fmt_ip6(buf, pkt_dev->in6_saddr.s6_addr); + scan_ip6(buf6, pkt_dev->in6_saddr.s6_addr); + fmt_ip6(buf6, pkt_dev->in6_saddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_saddr, &pkt_dev->in6_saddr); if(debug) - printk("pktgen: src6 set to: %s\n", buf); + printk("pktgen: src6 set to: %s\n", buf6); i += len; - sprintf(pg_result, "OK: src6=%s", buf); + sprintf(pg_result, "OK: src6=%s", buf6); return count; } if (!strcmp(name, "src_min")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_min) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->src_min) != 0) { + buf4[len] = 0; + if (strcmp(buf4, pkt_dev->src_min) != 0) { memset(pkt_dev->src_min, 0, sizeof(pkt_dev->src_min)); - strncpy(pkt_dev->src_min, buf, len); + strncpy(pkt_dev->src_min, buf4, len); pkt_dev->saddr_min = in_aton(pkt_dev->src_min); pkt_dev->cur_saddr = pkt_dev->saddr_min; } @@ -1224,15 +1215,14 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "src_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_max) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->src_max) != 0) { + buf4[len] = 0; + if (strcmp(buf4, pkt_dev->src_max) != 0) { memset(pkt_dev->src_max, 0, sizeof(pkt_dev->src_max)); - strncpy(pkt_dev->src_max, buf, len); + strncpy(pkt_dev->src_max, buf4, len); pkt_dev->saddr_max = in_aton(pkt_dev->src_max); pkt_dev->cur_saddr = pkt_dev->saddr_max; } --- From romieu@fr.zoreil.com Fri Feb 18 14:15:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 14:15:52 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IMFjTK004190 for ; Fri, 18 Feb 2005 14:15:46 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1IMBQof024765; Fri, 18 Feb 2005 23:11:26 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1IMBL8g024764; Fri, 18 Feb 2005 23:11:21 +0100 Date: Fri, 18 Feb 2005 23:11:21 +0100 From: Francois Romieu To: "Randy.Dunlap" Cc: robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage Message-ID: <20050218221121.GA22845@electric-eye.fr.zoreil.com> References: <20050218134219.3f079110.rddunlap@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050218134219.3f079110.rddunlap@osdl.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1797 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: 382 Lines: 13 Randy.Dunlap : > (resend) > Any comments this time? Did I miss a simultaneous use of both buffers or could it be possible to save an extra IP_NAME_SZ bytes of data with an evil ugly union ? Btw, does anyone intend to fix the use of sleepable functions in proc_thread_write() with spinlock ("thread_lock") held or should I allocate it some cycles ? -- Ueimor From rddunlap@osdl.org Fri Feb 18 14:20:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 14:20:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IMKiba004792 for ; Fri, 18 Feb 2005 14:20:45 -0800 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1IMKWqi022040 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 18 Feb 2005 14:20:33 -0800 Message-ID: <42166A38.4020200@osdl.org> Date: Fri, 18 Feb 2005 14:20:40 -0800 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> In-Reply-To: <20050218221121.GA22845@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1798 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: 496 Lines: 18 Francois Romieu wrote: > Randy.Dunlap : > >>(resend) >>Any comments this time? > > > Did I miss a simultaneous use of both buffers or could it be possible to > save an extra IP_NAME_SZ bytes of data with an evil ugly union ? That's probably doable, I'll double-check it and modify the patch... > Btw, does anyone intend to fix the use of sleepable functions in > proc_thread_write() with spinlock ("thread_lock") held or should > I allocate it some cycles ? -- ~Randy From herbert@gondor.apana.org.au Fri Feb 18 14:21:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 14:21:12 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IML2ki004907 for ; Fri, 18 Feb 2005 14:21:03 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2GUP-0000Ja-00; Sat, 19 Feb 2005 09:20:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2GSb-0003yF-00; Sat, 19 Feb 2005 09:18:53 +1100 Date: Sat, 19 Feb 2005 09:18:52 +1100 To: Daniele Venzano Cc: netdev@oss.sgi.com, Andrew Morton , mangus@deprecated.it, jgarzik@pobox.com Subject: Re: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot Message-ID: <20050218221852.GA15250@gondor.apana.org.au> References: <5ce5a5e4fed105451a3b7700bf40b04d@libero.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <5ce5a5e4fed105451a3b7700bf40b04d@libero.it> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5132 Lines: 163 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 18, 2005 at 07:17:06PM +0100, Daniele Venzano wrote: > > I think the patch is ok, but it will not apply with the latest changes > I sent to Jeff Garzik (see > sis900.c?nav=index.html|src/.|src/drivers|src/drivers/net>. > Don't know if this is a problem, since those changes have not yet > reached Linus tree. Thanks for the pointer. I've rediffed the patch against netdev-2.6. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/sis900.c 1.67 vs edited ===== --- 1.67/drivers/net/sis900.c 2005-01-27 11:00:00 +11:00 +++ edited/drivers/net/sis900.c 2005-02-19 09:16:13 +11:00 @@ -373,6 +373,55 @@ return 0; } +static int __devinit sis900_init_netdev(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = netdev_priv(net_dev); + struct pci_dev *pci_dev = sis_priv->pci_dev; + long ioaddr = net_dev->base_addr; + struct pci_dev *dev; + int ret; + + /* Get Mac address according to the chip revision */ + pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); + if (netif_msg_probe(sis_priv)) + printk(KERN_DEBUG "%s: detected revision %2.2x, " + "trying to get MAC address...\n", + net_dev->name, sis_priv->chipset_rev); + + if (sis_priv->chipset_rev == SIS630E_900_REV) + ret = sis630e_get_mac_addr(pci_dev, net_dev); + else if ((sis_priv->chipset_rev > 0x81) && (sis_priv->chipset_rev <= 0x90)) + ret = sis635_get_mac_addr(pci_dev, net_dev); + else if (sis_priv->chipset_rev == SIS96x_900_REV) + ret = sis96x_get_mac_addr(pci_dev, net_dev); + else + ret = sis900_get_mac_addr(pci_dev, net_dev); + + if (ret == 0) { + printk(KERN_WARNING "%s: Cannot read MAC address.\n", net_dev->name); + return -ENODEV; + } + + /* 630ET : set the mii access mode as software-mode */ + if (sis_priv->chipset_rev == SIS630ET_900_REV) + outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr); + + /* probe for mii transceiver */ + if (sis900_mii_probe(net_dev) == 0) { + printk(KERN_WARNING "%s: Error probing MII device.\n", net_dev->name); + return -ENODEV; + } + + /* save our host bridge revision */ + dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); + if (dev) { + pci_read_config_byte(dev, PCI_CLASS_REVISION, &sis_priv->host_bridge_rev); + pci_dev_put(dev); + } + + return 0; +} + /** * sis900_probe - Probe for sis900 device * @pci_dev: the sis900 pci device @@ -389,7 +438,6 @@ { struct sis900_private *sis_priv; struct net_device *net_dev; - struct pci_dev *dev; dma_addr_t ring_dma; void *ring_space; long ioaddr; @@ -463,6 +511,7 @@ net_dev->tx_timeout = sis900_tx_timeout; net_dev->watchdog_timeo = TX_TIMEOUT; net_dev->ethtool_ops = &sis900_ethtool_ops; + net_dev->init = &sis900_init_netdev; if (sis900_debug > 0) sis_priv->msg_enable = sis900_debug; @@ -472,47 +521,6 @@ ret = register_netdev(net_dev); if (ret) goto err_unmap_rx; - - /* Get Mac address according to the chip revision */ - pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); - if(netif_msg_probe(sis_priv)) - printk(KERN_DEBUG "%s: detected revision %2.2x, " - "trying to get MAC address...\n", - net_dev->name, sis_priv->chipset_rev); - - ret = 0; - if (sis_priv->chipset_rev == SIS630E_900_REV) - ret = sis630e_get_mac_addr(pci_dev, net_dev); - else if ((sis_priv->chipset_rev > 0x81) && (sis_priv->chipset_rev <= 0x90) ) - ret = sis635_get_mac_addr(pci_dev, net_dev); - else if (sis_priv->chipset_rev == SIS96x_900_REV) - ret = sis96x_get_mac_addr(pci_dev, net_dev); - else - ret = sis900_get_mac_addr(pci_dev, net_dev); - - if (ret == 0) { - printk(KERN_WARNING "%s: Cannot read MAC address.\n", net_dev->name); - ret = -ENODEV; - goto err_out_unregister; - } - - /* 630ET : set the mii access mode as software-mode */ - if (sis_priv->chipset_rev == SIS630ET_900_REV) - outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr); - - /* probe for mii transceiver */ - if (sis900_mii_probe(net_dev) == 0) { - printk(KERN_WARNING "%s: Error probing MII device.\n", net_dev->name); - ret = -ENODEV; - goto err_out_unregister; - } - - /* save our host bridge revision */ - dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); - if (dev) { - pci_read_config_byte(dev, PCI_CLASS_REVISION, &sis_priv->host_bridge_rev); - pci_dev_put(dev); - } /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, @@ -523,8 +531,6 @@ return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); --gKMricLos+KVdGMg-- From rddunlap@osdl.org Fri Feb 18 14:38:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 14:38:05 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IMbvqj006152 for ; Fri, 18 Feb 2005 14:37:58 -0800 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1IMbiqi023330 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 18 Feb 2005 14:37:44 -0800 Message-ID: <42166E3F.2050304@osdl.org> Date: Fri, 18 Feb 2005 14:37:51 -0800 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> In-Reply-To: <20050218221121.GA22845@electric-eye.fr.zoreil.com> Content-Type: multipart/mixed; boundary="------------060305080105070604010102" X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1800 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: 9548 Lines: 259 This is a multi-part message in MIME format. --------------060305080105070604010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francois Romieu wrote: > Randy.Dunlap : > >>(resend) >>Any comments this time? > > > Did I miss a simultaneous use of both buffers or could it be possible to > save an extra IP_NAME_SZ bytes of data with an evil ugly union ? I don't see any simultaneous uses of the 2 buffers, so here's the union version of the patch (attached this time), although it only saves 4 bytes... so maybe the compiler had already realized that usage. Either one accomplishes a large stack reduction, but the first one is slightly more readable & maintainable (to me), and less error-prone (or more future-proof) (again, to me). Thanks, -- ~Randy --------------060305080105070604010102 Content-Type: text/x-patch; name="pktgen_stack_v2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pktgen_stack_v2.patch" pktgen: proc_if_write: reduce stack usage (on i386) from 776 to 292 bytes by combining/reusing locals. Signed-off-by: Randy Dunlap diffstat:= net/core/pktgen.c | 96 ++++++++++++++++++++++++------------------------------ 1 files changed, 44 insertions(+), 52 deletions(-) diff -Naurp ./net/core/pktgen.c~pktgen_stack ./net/core/pktgen.c --- ./net/core/pktgen.c~pktgen_stack 2005-02-18 13:39:12.309983016 -0800 +++ ./net/core/pktgen.c 2005-02-18 14:28:54.007696064 -0800 @@ -811,6 +811,10 @@ static int proc_if_write(struct file *fi struct pktgen_dev *pkt_dev = (struct pktgen_dev*)(data); char* pg_result = NULL; int tmp = 0; + union bufs { + char buf4[IP_NAME_SZ]; + char buf6[128]; + } bu; pg_result = &(pkt_dev->result[0]); @@ -1071,16 +1075,15 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst_min") || !strcmp(name, "dst")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_min) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->dst_min) != 0) { + bu.buf4[len] = 0; + if (strcmp(bu.buf4, pkt_dev->dst_min) != 0) { memset(pkt_dev->dst_min, 0, sizeof(pkt_dev->dst_min)); - strncpy(pkt_dev->dst_min, buf, len); + strncpy(pkt_dev->dst_min, bu.buf4, len); pkt_dev->daddr_min = in_aton(pkt_dev->dst_min); pkt_dev->cur_daddr = pkt_dev->daddr_min; } @@ -1091,17 +1094,16 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_max) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->dst_max) != 0) { + bu.buf4[len] = 0; + if (strcmp(bu.buf4, pkt_dev->dst_max) != 0) { memset(pkt_dev->dst_max, 0, sizeof(pkt_dev->dst_max)); - strncpy(pkt_dev->dst_max, buf, len); + strncpy(pkt_dev->dst_max, bu.buf4, len); pkt_dev->daddr_max = in_aton(pkt_dev->dst_max); pkt_dev->cur_daddr = pkt_dev->daddr_max; } @@ -1112,108 +1114,99 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "dst6")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + bu.buf6[len] = 0; - scan_ip6(buf, pkt_dev->in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->in6_daddr.s6_addr); + scan_ip6(bu.buf6, pkt_dev->in6_daddr.s6_addr); + fmt_ip6(bu.buf6, pkt_dev->in6_daddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_daddr, &pkt_dev->in6_daddr); if(debug) - printk("pktgen: dst6 set to: %s\n", buf); + printk("pktgen: dst6 set to: %s\n", bu.buf6); i += len; - sprintf(pg_result, "OK: dst6=%s", buf); + sprintf(pg_result, "OK: dst6=%s", bu.buf6); return count; } if (!strcmp(name, "dst6_min")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + bu.buf6[len] = 0; - scan_ip6(buf, pkt_dev->min_in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->min_in6_daddr.s6_addr); + scan_ip6(bu.buf6, pkt_dev->min_in6_daddr.s6_addr); + fmt_ip6(bu.buf6, pkt_dev->min_in6_daddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_daddr, &pkt_dev->min_in6_daddr); if(debug) - printk("pktgen: dst6_min set to: %s\n", buf); + printk("pktgen: dst6_min set to: %s\n", bu.buf6); i += len; - sprintf(pg_result, "OK: dst6_min=%s", buf); + sprintf(pg_result, "OK: dst6_min=%s", bu.buf6); return count; } if (!strcmp(name, "dst6_max")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + bu.buf6[len] = 0; - scan_ip6(buf, pkt_dev->max_in6_daddr.s6_addr); - fmt_ip6(buf, pkt_dev->max_in6_daddr.s6_addr); + scan_ip6(bu.buf6, pkt_dev->max_in6_daddr.s6_addr); + fmt_ip6(bu.buf6, pkt_dev->max_in6_daddr.s6_addr); if(debug) - printk("pktgen: dst6_max set to: %s\n", buf); + printk("pktgen: dst6_max set to: %s\n", bu.buf6); i += len; - sprintf(pg_result, "OK: dst6_max=%s", buf); + sprintf(pg_result, "OK: dst6_max=%s", bu.buf6); return count; } if (!strcmp(name, "src6")) { - char buf[128]; - len = strn_len(&user_buffer[i], 128 - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf6, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; + bu.buf6[len] = 0; - scan_ip6(buf, pkt_dev->in6_saddr.s6_addr); - fmt_ip6(buf, pkt_dev->in6_saddr.s6_addr); + scan_ip6(bu.buf6, pkt_dev->in6_saddr.s6_addr); + fmt_ip6(bu.buf6, pkt_dev->in6_saddr.s6_addr); ipv6_addr_copy(&pkt_dev->cur_in6_saddr, &pkt_dev->in6_saddr); if(debug) - printk("pktgen: src6 set to: %s\n", buf); + printk("pktgen: src6 set to: %s\n", bu.buf6); i += len; - sprintf(pg_result, "OK: src6=%s", buf); + sprintf(pg_result, "OK: src6=%s", bu.buf6); return count; } if (!strcmp(name, "src_min")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_min) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->src_min) != 0) { + bu.buf4[len] = 0; + if (strcmp(bu.buf4, pkt_dev->src_min) != 0) { memset(pkt_dev->src_min, 0, sizeof(pkt_dev->src_min)); - strncpy(pkt_dev->src_min, buf, len); + strncpy(pkt_dev->src_min, bu.buf4, len); pkt_dev->saddr_min = in_aton(pkt_dev->src_min); pkt_dev->cur_saddr = pkt_dev->saddr_min; } @@ -1224,15 +1217,14 @@ static int proc_if_write(struct file *fi return count; } if (!strcmp(name, "src_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_max) - 1); if (len < 0) { return len; } - if (copy_from_user(buf, &user_buffer[i], len)) + if (copy_from_user(bu.buf4, &user_buffer[i], len)) return -EFAULT; - buf[len] = 0; - if (strcmp(buf, pkt_dev->src_max) != 0) { + bu.buf4[len] = 0; + if (strcmp(bu.buf4, pkt_dev->src_max) != 0) { memset(pkt_dev->src_max, 0, sizeof(pkt_dev->src_max)); - strncpy(pkt_dev->src_max, buf, len); + strncpy(pkt_dev->src_max, bu.buf4, len); pkt_dev->saddr_max = in_aton(pkt_dev->src_max); pkt_dev->cur_saddr = pkt_dev->saddr_max; } --------------060305080105070604010102-- From greearb@candelatech.com Fri Feb 18 18:56:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 18:56:50 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J2uhiO016544 for ; Fri, 18 Feb 2005 18:56:44 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1J3HbLH011601; Fri, 18 Feb 2005 19:17:37 -0800 Message-ID: <4216AAE4.1080804@candelatech.com> Date: Fri, 18 Feb 2005 18:56:36 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage References: <20050218134219.3f079110.rddunlap@osdl.org> In-Reply-To: <20050218134219.3f079110.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1802 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: 454 Lines: 21 Randy.Dunlap wrote: > (resend) > Any comments this time? > > > > pktgen: proc_if_write: reduce stack usage (on i386) > from 776 to 296 bytes by combining/reusing locals. Since these methods are not in the fast path, and the stack usage is not near 4k, does this really matter? I'm asking more to be educated than to dismiss the changes.... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Fri Feb 18 19:45:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 19:45:14 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J3j6E0018986 for ; Fri, 18 Feb 2005 19:45:07 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D2LYE-0005cO-Sj for netdev@oss.sgi.com; Sat, 19 Feb 2005 03:45:03 +0000 Message-ID: <4216B62D.6000502@pobox.com> Date: Fri, 18 Feb 2005 22:44:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Intel and TOE in the news Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1804 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: 891 Lines: 25 http://www.theregister.co.uk/2005/02/18/intel_tcpip_attack/ Intel to attack greedy TCP/IP stack Intel next year will plant itself square in the middle of the budding market for systems that speed network traffic by rolling out something called I/OAT. I/OAT stands for I/O Acceleration Technology and it will be previewed for the first time at next month's Intel Developer Forum (IDF) in San Francisco. Intel remains cagey about what exactly I/OAT is, but it dangled a few details today in front of reporters ahead of the IDF event. [...] Intel plans to sidestep the need for separate TOE cards by building this technology into its server processor package - the chip itself, chipset and network controller. This should reduce some of the time a processor typically spends waiting for memory to feed back information and improve overall application processing speeds. [...] From buytenh@wantstofly.org Fri Feb 18 20:10:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 20:10:13 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J4A8Np020119 for ; Fri, 18 Feb 2005 20:10:09 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 8C5BD2B0EC; Sat, 19 Feb 2005 05:10:07 +0100 (MET) Date: Sat, 19 Feb 2005 05:10:07 +0100 From: Lennert Buytenhek To: Jeff Garzik Cc: Netdev Subject: Re: Intel and TOE in the news Message-ID: <20050219041007.GA17896@xi.wantstofly.org> References: <4216B62D.6000502@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4216B62D.6000502@pobox.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 713 Lines: 17 On Fri, Feb 18, 2005 at 10:44:45PM -0500, Jeff Garzik wrote: > Intel plans to sidestep the need for separate TOE cards by building this > technology into its server processor package - the chip itself, chipset > and network controller. This should reduce some of the time a processor > typically spends waiting for memory to feed back information and improve > overall application processing speeds. I wonder if they could just take the network processing circuitry from the IXP2800 (an extra 16-core (!) RISCy processor on-die, dedicated to doing just network stuff, and a 10gbps pipe going straight into the CPU itself) and graft it onto the Xeon. Now _that_ would be something worth experiencing. --L From jgarzik@pobox.com Fri Feb 18 21:03:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 21:03:56 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J53mcO025118 for ; Fri, 18 Feb 2005 21:03:49 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D2MmR-00076I-R7; Sat, 19 Feb 2005 05:03:47 +0000 Message-ID: <4216C8A3.4020303@pobox.com> Date: Sat, 19 Feb 2005 00:03:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sfeldma@pobox.com CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] eepro100: remove ID for 82556 References: <1107285106.3366.106.camel@sfeldma-mobl.dsl-verizon.net> In-Reply-To: <1107285106.3366.106.camel@sfeldma-mobl.dsl-verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1806 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: 564 Lines: 19 Scott Feldman wrote: > 82556 support doesn't work with eepro100, so this removes the ID > (0x1228) for 82556. See this thread for more info: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110726223221165&w=2 > > Signed-off-by: Scott Feldman I see the thread, but I still worry about removing the id in your patch, since the poster in the thread says that they had to -add- an ID to both e100 and eepro100 in order to perform their test. Has anyone with this PCI ID actually confirmed that eepro100 does not work for them? Jeff From kaber@trash.net Fri Feb 18 22:03:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 22:03:45 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J63d3R026691 for ; Fri, 18 Feb 2005 22:03:39 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2NiG-0006zN-RN; Sat, 19 Feb 2005 07:03:32 +0100 Message-ID: <4216D6B4.5070901@trash.net> Date: Sat, 19 Feb 2005 07:03:32 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> In-Reply-To: <20050218100854.GA19427@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1774 Lines: 51 Herbert Xu wrote: >On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote: > > >>I'm not sure yet how to deal with optional SAs. We shouldn't add >>incomplete optional tunnel mode SAs to the bundle because then we >>can't determine the output device, but if we don't nothing will >>trigger resolving of optional SAs following a non-optional SA that >>needs to be resolved. >> >> > >I don't get it. Can't you just add it into the bundle but ignore it >for dst->output and other calculations until it's either realised or >removed? > > An optional tunnel mode SA might change peer/dev/rt_gateway/rt_type if successfully resolved. This introduces a couple of problems: - MTU estimatation impossible - netfilter LOCAL_OUT hook sees incorrect output device - strict source routing check done with incorrect rt_gateway Simply ignoring these SAs if they are not available when the bundle is created looks like the easiest solution to me. >>I thought about adding the queue to the xfrm_dst and adding a dummy >>xfrm_state with a selector that matches only the current flow. This >> >> > >The inner flow is probably not the best key for this. How about >keying it using the outer remote address on the template? The SAs >have a bydst hash which makes this easy to look up. > >So we would attach each packet to a queue shared by all SAs to a >specific (outer) remote address. > > That sounds reasonable. The selector initialized to the inner flow is meant for cacheing the incomplete bundle at the policy. We can have multiple SAs with equal family/reqid/saddr/daddr/mode/proto differing only be SPI and selector. If we use a selector selecting more than the inner flow we could create a conflict with an already existing cached bundle. Regards Patrick From kaber@trash.net Fri Feb 18 22:23:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Feb 2005 22:23:47 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J6Nh8o027630 for ; Fri, 18 Feb 2005 22:23:43 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2O1C-0007d1-Ou; Sat, 19 Feb 2005 07:23:06 +0100 Message-ID: <4216DB4A.2000109@trash.net> Date: Sat, 19 Feb 2005 07:23:06 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [XFRM]: Always reroute in tunnel mode References: <4214381F.5020507@trash.net> <20050217113654.GA10346@gondor.apana.org.au> <4214DF5B.3010608@trash.net> <20050217203805.GA4047@gondor.apana.org.au> <42150B36.5080609@trash.net> <20050217221031.GA4554@gondor.apana.org.au> <42152283.4030800@trash.net> <20050217151122.098c6def.davem@davemloft.net> <20050218095344.GA19307@gondor.apana.org.au> In-Reply-To: <20050218095344.GA19307@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 815 Lines: 23 Herbert Xu wrote: >Put it another way, my solution to Patrick's inconsistency would be to >always inherit the routing decision from the top to the bottom of the >bundle. For example, suppose you had > >ip ro add 192.168.0.0/16 \ > nexthop via 10.0.0.1 dev eth0 \ > nexthop via 10.0.0.2 dev eth0 > >Then the packets to 192.168.0.0/16 should be sent via 10.0.0.1/10.0.0.2 >regardless of what IPsec protections are applied to it. > I agree it is a nice alternative to the current way. It would solve another inconsistency caused by overriding the routing result in tunnel mode: on output we don't care about oif, so packets from a socket will be tunneled independent of sk_bound_dev_if. On input packets won't be delivered to the socket if the encapsulated packet arrived on a different interface. Regards Patrick From mroos@tartu.cyber.ee Sat Feb 19 00:08:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 00:08:18 -0800 (PST) Received: from tartu.cyber.ee (tartu.cyber.ee [193.40.6.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J884Lf030175 for ; Sat, 19 Feb 2005 00:08:05 -0800 Received: Message by Barricade tartu.cyber.ee with ESMTP id j1J7s1B09004; Sat, 19 Feb 2005 09:54:01 +0200 Received: from rhn.tartu-labor (rhn.tartu-labor [192.168.74.17]) by ondatra.tartu-labor (Postfix) with ESMTP id EBB2F14C54; Sat, 19 Feb 2005 10:08:02 +0200 (EET) Received: from mroos by rhn.tartu-labor with local (Exim 4.44) id 1D2Pek-0007RZ-Tk; Sat, 19 Feb 2005 10:08:02 +0200 From: Meelis Roos To: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] eepro100: remove ID for 82556 In-Reply-To: <4216C8A3.4020303@pobox.com> User-Agent: tin/1.7.6-20040906 ("Baleshare") (UNIX) (Linux/2.6.11-rc4 (i686)) Message-Id: Date: Sat, 19 Feb 2005 10:08:02 +0200 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev Content-Length: 528 Lines: 14 JG> I see the thread, but I still worry about removing the id in your patch, JG> since the poster in the thread says that they had to -add- an ID to both JG> e100 and eepro100 in order to perform their test. JG> JG> Has anyone with this PCI ID actually confirmed that eepro100 does not JG> work for them? I added the PCI ID only to e100, it was already present in eepro100. Neither unmodified eepro100 nor pci-id-added e100 worked with this chip so IMHO it's safe to remove this PCI ID from eepro100 too. -- Meelis Roos From jgarzik@pobox.com Sat Feb 19 00:48:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 00:49:00 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J8msBj002275 for ; Sat, 19 Feb 2005 00:48:56 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D2QIE-0001ch-1y; Sat, 19 Feb 2005 08:48:50 +0000 Message-ID: <4216FD64.9020509@pobox.com> Date: Sat, 19 Feb 2005 03:48:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Porter CC: netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: Re: [PATCH] emac: filter illegal frame sizes References: <20050218101245.D11439@cox.net> In-Reply-To: <20050218101245.D11439@cox.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1810 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: 172 Lines: 11 Matt Porter wrote: > Fix to drop frames that are too large for the current MTU. What is this fixing? You should be passing all frames up to the software stack. Jeff From herbert@gondor.apana.org.au Sat Feb 19 01:24:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 01:24:12 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1J9O1vO003604 for ; Sat, 19 Feb 2005 01:24:02 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2Qpy-00035X-00; Sat, 19 Feb 2005 20:23:42 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2QpW-00029E-00; Sat, 19 Feb 2005 20:23:14 +1100 Date: Sat, 19 Feb 2005 20:23:14 +1100 To: Patrick McHardy Cc: Maillist netdev Subject: Re: IPsec xfrm resolution Message-ID: <20050219092314.GA8153@gondor.apana.org.au> References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4216D6B4.5070901@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1543 Lines: 39 On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote: > > An optional tunnel mode SA might change peer/dev/rt_gateway/rt_type if > successfully resolved. This introduces a couple of problems: > > - MTU estimatation impossible This is OK for two reasons: 1) The application must be able to react to MTU changes anyway. 2) The most common use for optional SAs is IPCOMP which has zero overhead. Actually, 2) gives us the real reason why we must include optional SAs. Even though we can skip the compression of a tunnel mode IPCOMP SA, we must perform the IPIP encapsulation. > - netfilter LOCAL_OUT hook sees incorrect output device > - strict source routing check done with incorrect rt_gateway Once you take the above into account these turn out to be non-issues. If the optional SA is transport mode, then the route is identical with or without it. If it's tunnel mode, then we must perform the IPIP encapsulation regardless. > That sounds reasonable. The selector initialized to the inner flow is > meant for cacheing the incomplete bundle at the policy. We can have > multiple SAs with equal family/reqid/saddr/daddr/mode/proto differing > only be SPI and selector. If we use a selector selecting more than the > inner flow we could create a conflict with an already existing cached > bundle. Agreed. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sat Feb 19 03:44:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 03:44:28 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JBiL42009541 for ; Sat, 19 Feb 2005 03:44:22 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2T1T-0005xd-W2; Sat, 19 Feb 2005 12:43:44 +0100 Message-ID: <4217266F.6090700@trash.net> Date: Sat, 19 Feb 2005 12:43:43 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , Maillist netdev Subject: [XFRM]: Fix ICMP tempsel Content-Type: multipart/mixed; boundary="------------070100090607050204020104" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2277 Lines: 71 This is a multi-part message in MIME format. --------------070100090607050204020104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The selector ports are initialized to fl_ip_sport/fl_ip_dport instead of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, type and code should be stored in sport and dport, in struct flowi both are contained in fl_ip_sport. --------------070100090607050204020104 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/19 12:35:18+01:00 kaber@coreworks.de # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_state.c # 2005/02/19 12:35:06+01:00 kaber@coreworks.de +2 -2 # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_state.c # 2005/02/19 12:35:06+01:00 kaber@coreworks.de +2 -2 # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_state.c b/net/ipv4/xfrm4_state.c --- a/net/ipv4/xfrm4_state.c 2005-02-19 12:36:31 +01:00 +++ b/net/ipv4/xfrm4_state.c 2005-02-19 12:36:31 +01:00 @@ -20,9 +20,9 @@ { x->sel.daddr.a4 = fl->fl4_dst; x->sel.saddr.a4 = fl->fl4_src; - x->sel.dport = fl->fl_ip_dport; + x->sel.dport = xfrm_flowi_dport(fl); x->sel.dport_mask = ~0; - x->sel.sport = fl->fl_ip_sport; + x->sel.sport = xfrm_flowi_sport(fl); x->sel.sport_mask = ~0; x->sel.prefixlen_d = 32; x->sel.prefixlen_s = 32; diff -Nru a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c --- a/net/ipv6/xfrm6_state.c 2005-02-19 12:36:31 +01:00 +++ b/net/ipv6/xfrm6_state.c 2005-02-19 12:36:31 +01:00 @@ -27,9 +27,9 @@ * to current session. */ ipv6_addr_copy((struct in6_addr *)&x->sel.daddr, &fl->fl6_dst); ipv6_addr_copy((struct in6_addr *)&x->sel.saddr, &fl->fl6_src); - x->sel.dport = fl->fl_ip_dport; + x->sel.dport = xfrm_flowi_dport(fl); x->sel.dport_mask = ~0; - x->sel.sport = fl->fl_ip_sport; + x->sel.sport = xfrm_flowi_sport(fl); x->sel.sport_mask = ~0; x->sel.prefixlen_d = 128; x->sel.prefixlen_s = 128; --------------070100090607050204020104-- From yoshfuji@linux-ipv6.org Sat Feb 19 04:21:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 04:21:59 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JCLnjd014560 for ; Sat, 19 Feb 2005 04:21:50 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A351C33CC2; Sat, 19 Feb 2005 21:23:05 +0900 (JST) Date: Sat, 19 Feb 2005 21:23:04 +0900 (JST) Message-Id: <20050219.212304.08460936.yoshfuji@linux-ipv6.org> To: kaber@trash.net, davem@davemloft.net Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4217266F.6090700@trash.net> References: <4217266F.6090700@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1813 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: 391 Lines: 10 In article <4217266F.6090700@trash.net> (at Sat, 19 Feb 2005 12:43:43 +0100), Patrick McHardy says: > The selector ports are initialized to fl_ip_sport/fl_ip_dport instead > of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, > type and code should be stored in sport and dport, in struct flowi both > are contained in fl_ip_sport. I agree. --yoshfuji From kaber@trash.net Sat Feb 19 04:29:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 04:29:34 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JCTTg4015186 for ; Sat, 19 Feb 2005 04:29:30 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2Tjh-0006XI-92; Sat, 19 Feb 2005 13:29:25 +0100 Message-ID: <42173125.3040505@trash.net> Date: Sat, 19 Feb 2005 13:29:25 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> In-Reply-To: <20050219092314.GA8153@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 698 Lines: 23 Herbert Xu wrote: >On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote: > > >>- netfilter LOCAL_OUT hook sees incorrect output device >>- strict source routing check done with incorrect rt_gateway >> >> > >Once you take the above into account these turn out to be non-issues. >If the optional SA is transport mode, then the route is identical with >or without it. If it's tunnel mode, then we must perform the IPIP >encapsulation regardless. > This is not what happens currently. If an optional IPCOMP SA is missing it is skipped entirely. It is also legal to configure an optional ah/esp tunnel, although we don't accept such packets if the SA isn't present. Regards Patrick From jdmason@us.ibm.com Sat Feb 19 09:47:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 09:47:32 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JHlLgS027916 for ; Sat, 19 Feb 2005 09:47:28 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1JHlGMN211522 for ; Sat, 19 Feb 2005 12:47:16 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1JHlGN6257560 for ; Sat, 19 Feb 2005 10:47:16 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1JHlFv5024564 for ; Sat, 19 Feb 2005 10:47:15 -0700 Received: from sig-9-65-12-11.mts.ibm.com (sig-9-65-12-11.mts.ibm.com [9.65.12.11]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1JHlFf7024555; Sat, 19 Feb 2005 10:47:15 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Sat, 19 Feb 2005 11:47:14 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <200502181918.07859.jdmason@us.ibm.com> <20050219104640.GA31035@electric-eye.fr.zoreil.com> In-Reply-To: <20050219104640.GA31035@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: <200502191147.14845.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4451 Lines: 128 On Saturday 19 February 2005 04:46 am, Francois Romieu wrote: > Jon Mason : > > Would you like me to rediff with the changes you suggested? > > I have done it and separated the changes. The printk stuff will go in > a separate netif_msg_xxx and friends patch. See below if you have any > question. Btw, you can Cc: netdev. It's interesting for everyone to know > what's going on with r8169 devel. netdev Cc'ed per your suggestion. I've taken the liberity of removing all the patches, as they take up alot of space and look fine to me. Good work. [...] > > Also, how does the jumbo frames patch look? > > 1 - Mangled. I never said it was pretty, simply a working snapshot of my test driver. I figured that I had been promising you this update for so long, I better send it out before you get upset with me. ;-) > 2 - > > @@ -1627,7 +1652,8 @@ out: > static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) > { > desc->addr = 0x0badbadbadbadbadull; > - desc->opts1 &= ~cpu_to_le32(DescOwn | RsvdMask); > + desc->opts1 &= cpu_to_le32(RingEnd); > + desc->opts2 = 0; > } > > static void rtl8169_free_rx_skb(struct rtl8169_private *tp, > > Can you describe the scenario related to the change ? The change to opts1 seems cleaner to me. As the only the that the adapter needs to know is the RingEnd. I can try removing it and see if it makes any difference. Opts2 is VERY necessary to zero. Without this zero, the adapter will change the partition point randomly of each packet (random because I have yet to determine the rhyme or reason). I didn't want to spend too much time trying to determine the bahavior of this since I found out that zeroing it solved the problem. If you can think of a reason why this doesn't work, I can always go back and try to figure it out. > 3 - > > @@ -1652,6 +1680,7 @@ static inline void rtl8169_give_to_asic( > { > desc->addr = cpu_to_le64(mapping); > desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); > + desc->opts2 = 0; > } > > I am curious to know if it's there because you noticed that the asic did > not always update this word or because it is a good practice. > > Please note that in its current form it is racy: opts2 should be updated > before opts1 and a memory barrier should be added. See above for reason. I can re-order the operations and a mb (rmd I would think). > 4 - > > @@ -2152,37 +2216,38 @@ rtl8169_rx_interrupt(struct net_device * > } else { > struct RxDesc *desc = tp->RxDescArray + entry; > struct sk_buff *skb = tp->Rx_skbuff[entry]; > - int pkt_size = (status & 0x00001FFF) - 4; > + int pkt_size = (status & 0x00003FFF) - 4; > void (*pci_action)(struct pci_dev *, dma_addr_t, > size_t, int) = pci_dma_sync_single_for_device; > > - rtl8169_rx_csum(skb, desc); > - > pci_dma_sync_single_for_cpu(tp->pci_dev, > le64_to_cpu(desc->addr), tp->rx_buf_sz, > PCI_DMA_FROMDEVICE); > - > - if (rtl8169_try_rx_copy(&skb, pkt_size, desc, > - tp->rx_buf_sz)) { > + > + rtl8169_rx_csum(skb, desc); > > Why is rtl8169_rx_csum() moved around ? Seemed to make more sense to me to have it after the pci_dma_sync_single_for_cpu. If you disagree, I can move it back. > 5 - > + if (pkt_size > rx_copybreak) { > + memcpy(skb->data, sk_buff[0]->tail, > + tp->desc_part); > + skb_put(skb, tp->desc_part); > + } else { > + memcpy(skb->data, sk_buff[0]->tail, pkt_size); > + skb_put(skb, pkt_size); > + } > + } else > > I'd rather avoid the code duplication. Me too, but I couldn't think of a better way. Suggestions welcomed. > 5 - rtl8169_return_to_asic() in rtl8169_rx_copy() seems suspect > when FirstFrag is true and the skb allocation failed. In this case the desc is only a portion of the whole packet. I thought it best to toss the whole packet if the driver couldn't alloc a skb, and return the descriptor so that it can be used again. Actually, talking about this gave me an idea. Since desc_part is the largest skb we will ever need (aside from when they are combined), it would be more efficient to use that instead of the full size. I will create a patch for this (and the mb changes) and resubmit it. Let me know if you want me to return other things to their original spot. > 6 - skb_put() ends duplicated. It should be possible to avoid it. Is it? I was specifically trying to aviod that. Where do you see that? Thanks, Jon From john.ronciak@gmail.com Sat Feb 19 10:18:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 10:18:33 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JIIQHp029117 for ; Sat, 19 Feb 2005 10:18:27 -0800 Received: by rproxy.gmail.com with SMTP id c51so78492rne for ; Sat, 19 Feb 2005 10:18:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=fuGPP718Cz/DANK8fwKDLBRXxzWd+WstBu95frCE79PtvFJmZ94M42icawEM+S/Wqn7xVCjkUHMHmJjZwqCCBtaknmrWcI789pVhxQFlVp3u765EGf7NVf0e5qIrRfjSAbrmK6KBiaOfq6mDpdvsgepS69ABGM28RDW2/60J64A= Received: by 10.38.78.51 with SMTP id a51mr442796rnb; Sat, 19 Feb 2005 10:18:25 -0800 (PST) Received: by 10.38.150.13 with HTTP; Sat, 19 Feb 2005 10:18:25 -0800 (PST) Message-ID: <56a8daef05021910184ababbe5@mail.gmail.com> Date: Sat, 19 Feb 2005 10:18:25 -0800 From: John Ronciak Reply-To: John Ronciak To: Meelis Roos Subject: Re: [PATCH 2.6] eepro100: remove ID for 82556 Cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4216C8A3.4020303@pobox.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@gmail.com Precedence: bulk X-list: netdev Content-Length: 815 Lines: 27 The 82556 is not support by the e100 driver. It is a different architecture than the one started with the 82557 thru the current generation of PRO/100 controllers. On Sat, 19 Feb 2005 10:08:02 +0200, Meelis Roos wrote: > JG> I see the thread, but I still worry about removing the id in your patch, > JG> since the poster in the thread says that they had to -add- an ID to both > JG> e100 and eepro100 in order to perform their test. > JG> > JG> Has anyone with this PCI ID actually confirmed that eepro100 does not > JG> work for them? > > I added the PCI ID only to e100, it was already present in eepro100. > > Neither unmodified eepro100 nor pci-id-added e100 worked with this > chip so IMHO it's safe to remove this PCI ID from eepro100 too. > > -- > Meelis Roos > > -- Cheers, John From herbert@gondor.apana.org.au Sat Feb 19 10:32:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 10:32:44 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JIWZ3i030144 for ; Sat, 19 Feb 2005 10:32:37 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2ZOy-0005xA-00; Sun, 20 Feb 2005 05:32:24 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2ZOc-0002oQ-00; Sun, 20 Feb 2005 05:32:02 +1100 Date: Sun, 20 Feb 2005 05:32:02 +1100 To: Patrick McHardy Cc: Maillist netdev Subject: Re: IPsec xfrm resolution Message-ID: <20050219183202.GA10773@gondor.apana.org.au> References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42173125.3040505@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 597 Lines: 16 On Sat, Feb 19, 2005 at 01:29:25PM +0100, Patrick McHardy wrote: > > This is not what happens currently. If an optional IPCOMP SA is missing > it is skipped entirely. It is also legal to configure an optional > ah/esp tunnel, although we don't accept such packets if the SA isn't > present. That's a bug. How can you forward packets properly if the tunnel mode SA is missing? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Feb 19 10:44:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 10:44:41 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JIiWP9030933 for ; Sat, 19 Feb 2005 10:44:33 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2ZaP-00064I-00; Sun, 20 Feb 2005 05:44:13 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2Za3-0005jl-00; Sun, 20 Feb 2005 05:43:51 +1100 Date: Sun, 20 Feb 2005 05:43:51 +1100 To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Fix ICMP tempsel Message-ID: <20050219184351.GB10773@gondor.apana.org.au> References: <4217266F.6090700@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217266F.6090700@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 841 Lines: 25 On Sat, Feb 19, 2005 at 12:43:43PM +0100, Patrick McHardy wrote: > The selector ports are initialized to fl_ip_sport/fl_ip_dport instead > of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, > type and code should be stored in sport and dport, in struct flowi both > are contained in fl_ip_sport. I know this comment is probably a bit late but why didn't we simply put type/code into sport/dport in struct flowi instead of introducing the monstrosities of xfrm_flowi_sport/xfrm_flowi_dport? Something like struct { __u16 type; __u16 code; } icmpt; would've done (and still would do) the trick, no? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sat Feb 19 10:47:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 10:47:20 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JIlFUu031416 for ; Sat, 19 Feb 2005 10:47:16 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2ZdH-0001LE-HS; Sat, 19 Feb 2005 19:47:11 +0100 Message-ID: <421789AF.4020705@trash.net> Date: Sat, 19 Feb 2005 19:47:11 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> <20050219183202.GA10773@gondor.apana.org.au> In-Reply-To: <20050219183202.GA10773@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 599 Lines: 22 Herbert Xu wrote: >On Sat, Feb 19, 2005 at 01:29:25PM +0100, Patrick McHardy wrote: > > >>This is not what happens currently. If an optional IPCOMP SA is missing >>it is skipped entirely. It is also legal to configure an optional >>ah/esp tunnel, although we don't accept such packets if the SA isn't >>present. >> >> > >That's a bug. How can you forward packets properly if the tunnel mode >SA is missing? > Using normal routing. What meaning would "optional" have otherwise ? If the encapsulation has to be done, the user shouldn't mark the SA as optional in my opinion. Regards Patrick From kaber@trash.net Sat Feb 19 10:56:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 10:56:16 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JIuCSB032109 for ; Sat, 19 Feb 2005 10:56:12 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2ZlQ-0001MP-61; Sat, 19 Feb 2005 19:55:36 +0100 Message-ID: <42178BA8.4090305@trash.net> Date: Sat, 19 Feb 2005 19:55:36 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Fix ICMP tempsel References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> In-Reply-To: <20050219184351.GB10773@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 382 Lines: 20 Herbert Xu wrote: >I know this comment is probably a bit late but why didn't we simply put >type/code into sport/dport in struct flowi instead of introducing the >monstrosities of xfrm_flowi_sport/xfrm_flowi_dport? > >Something like > >struct { > __u16 type; > __u16 code; >} icmpt; > >would've done (and still would do) the trick, no? > I agree, that is better. Regards Patrick From herbert@gondor.apana.org.au Sat Feb 19 11:04:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 11:04:13 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JJ45jc032733 for ; Sat, 19 Feb 2005 11:04:06 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2ZtT-0006Bv-00; Sun, 20 Feb 2005 06:03:55 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2Zt7-0005ln-00; Sun, 20 Feb 2005 06:03:33 +1100 Date: Sun, 20 Feb 2005 06:03:33 +1100 To: Patrick McHardy Cc: Maillist netdev Subject: Re: IPsec xfrm resolution Message-ID: <20050219190333.GA22166@gondor.apana.org.au> References: <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> <20050219183202.GA10773@gondor.apana.org.au> <421789AF.4020705@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421789AF.4020705@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 694 Lines: 18 On Sat, Feb 19, 2005 at 07:47:11PM +0100, Patrick McHardy wrote: > > >That's a bug. How can you forward packets properly if the tunnel mode > >SA is missing? > > Using normal routing. What meaning would "optional" have otherwise ? > If the encapsulation has to be done, the user shouldn't mark the SA > as optional in my opinion. In that case you can't mark IPCOMP SAs as optional in this scenario which is the most common application of optional: IPCOMP(tunnel) -- ESP(transport) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sat Feb 19 11:47:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 11:47:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JJlD71001590 for ; Sat, 19 Feb 2005 11:47:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D2aYa-0004a5-00; Sat, 19 Feb 2005 11:46:24 -0800 Date: Sat, 19 Feb 2005 11:46:24 -0800 From: "David S. Miller" To: Lennert Buytenhek Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Intel and TOE in the news Message-Id: <20050219114624.373af63f.davem@davemloft.net> In-Reply-To: <20050219041007.GA17896@xi.wantstofly.org> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1174 Lines: 26 On Sat, 19 Feb 2005 05:10:07 +0100 Lennert Buytenhek wrote: > On Fri, Feb 18, 2005 at 10:44:45PM -0500, Jeff Garzik wrote: > > > Intel plans to sidestep the need for separate TOE cards by building this > > technology into its server processor package - the chip itself, chipset > > and network controller. This should reduce some of the time a processor > > typically spends waiting for memory to feed back information and improve > > overall application processing speeds. > > I wonder if they could just take the network processing circuitry from > the IXP2800 (an extra 16-core (!) RISCy processor on-die, dedicated to > doing just network stuff, and a 10gbps pipe going straight into the CPU > itself) and graft it onto the Xeon. > > Now _that_ would be something worth experiencing. No, that would be garbage. Read what they are doing. The idea is not to have all of this network protocol logic off-cpu, the idea is to "reduce some of the time a processor typically spends waiting for memory to feed back information" Think about what part of the network I/O equation that is working on. It's not protocol offload, that's for sure. From kaber@trash.net Sat Feb 19 11:53:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 11:53:42 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JJrcVd002160 for ; Sat, 19 Feb 2005 11:53:38 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2afV-0001PI-KF; Sat, 19 Feb 2005 20:53:33 +0100 Message-ID: <4217993D.4070107@trash.net> Date: Sat, 19 Feb 2005 20:53:33 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> <20050219183202.GA10773@gondor.apana.org.au> <421789AF.4020705@trash.net> <20050219190333.GA22166@gondor.apana.org.au> In-Reply-To: <20050219190333.GA22166@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1244 Lines: 36 Herbert Xu wrote: >On Sat, Feb 19, 2005 at 07:47:11PM +0100, Patrick McHardy wrote: > > >>>That's a bug. How can you forward packets properly if the tunnel mode >>>SA is missing? >>> >>> >>Using normal routing. What meaning would "optional" have otherwise ? >>If the encapsulation has to be done, the user shouldn't mark the SA >>as optional in my opinion. >> >> > >In that case you can't mark IPCOMP SAs as optional in this scenario >which is the most common application of optional: > >IPCOMP(tunnel) -- ESP(transport) > > I've checked KAME, it also skips IPSEC_LEVEL_USE SAs if they aren't present. IPCOMP in tunnel mode is a special case. It wants to express more than just "optional". It means to say "use SA if present and some things wrt. size apply, otherwise use a similar SA with proto=IPIP". One of both has to be used, and this is what "optional" can't express. The current method is to use the IPIP SA automatically created with the IPCOMP SA when the compressed size exceeds the uncompressed size, but it doesn't handle a missing SA. This suggests we need to special-case tunnel mode IPCOMP in xfrm_tmpl_resolve() and either ignore "optional" for IPIP tunnel mode SAs or create them on demand. Regards Patrick From kaber@trash.net Sat Feb 19 12:26:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 12:26:11 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JKQ6Cp006758 for ; Sat, 19 Feb 2005 12:26:07 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2bAw-0001Ri-AJ; Sat, 19 Feb 2005 21:26:02 +0100 Message-ID: <4217A0DA.7050409@trash.net> Date: Sat, 19 Feb 2005 21:26:02 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Maillist netdev Subject: Re: IPsec xfrm resolution References: <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> <20050219183202.GA10773@gondor.apana.org.au> <421789AF.4020705@trash.net> <20050219190333.GA22166@gondor.apana.org.au> <4217993D.4070107@trash.net> In-Reply-To: <4217993D.4070107@trash.net> Content-Type: multipart/mixed; boundary="------------010607080902030008090807" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1544 Lines: 53 This is a multi-part message in MIME format. --------------010607080902030008090807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > I've checked KAME, it also skips IPSEC_LEVEL_USE SAs if they aren't > present. > IPCOMP in tunnel mode is a special case. It wants to express more than > just > "optional". It means to say "use SA if present and some things wrt. > size apply, > otherwise use a similar SA with proto=IPIP". One of both has to be > used, and > this is what "optional" can't express. The current method is to use > the IPIP > SA automatically created with the IPCOMP SA when the compressed size > exceeds > the uncompressed size, but it doesn't handle a missing SA. This > suggests we > need to special-case tunnel mode IPCOMP in xfrm_tmpl_resolve() and either > ignore "optional" for IPIP tunnel mode SAs or create them on demand. How about this patch ? It ignores "optional" for missing tunnel mode SAs, symetric to input. Regards Patrick --------------010607080902030008090807 Content-Type: text/plain; name="x1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x1" ===== net/xfrm/xfrm_policy.c 1.66 vs edited ===== --- 1.66/net/xfrm/xfrm_policy.c 2005-02-16 00:16:04 +01:00 +++ edited/net/xfrm/xfrm_policy.c 2005-02-19 21:12:38 +01:00 @@ -656,7 +656,7 @@ xfrm_state_put(x); } - if (!tmpl->optional) + if (!tmpl->optional || tmpl->mode) goto fail; } return nx; --------------010607080902030008090807-- From ak@muc.de Sat Feb 19 12:27:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 12:27:41 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JKRaJe007116 for ; Sat, 19 Feb 2005 12:27:36 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id DABA1D033E; Sat, 19 Feb 2005 21:27:31 +0100 (CET) To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> From: Andi Kleen Date: Sat, 19 Feb 2005 21:27:31 +0100 In-Reply-To: <20050219114624.373af63f.davem@davemloft.net> (David S. Miller's message of "Sat, 19 Feb 2005 11:46:24 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1825 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: 903 Lines: 27 "David S. Miller" writes: > Read what they are doing. The idea is not to have all of this network > protocol logic off-cpu, the idea is to "reduce some of the time > a processor typically spends waiting for memory to feed back information" > > Think about what part of the network I/O equation that is working on. > It's not protocol offload, that's for sure. It would be nice if the NIC could asynchronously trigger prefetches in the CPU. Currently a lot of the packet processing cost goes to waiting for read cache misses. E.g. - NIC receives packet. - Tells target CPU to prefetch RX descriptor and headers. - CPU later looks at them and doesn't have to wait a for a cache miss. Drawback is that you would need to tell the NIC in advance on which CPU you want to process the packet, but with Linux IRQ affinity that's easy to figure out. -Andi From buytenh@wantstofly.org Sat Feb 19 12:29:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 12:29:38 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JKTXiM007741 for ; Sat, 19 Feb 2005 12:29:34 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 1177D2B0EC; Sat, 19 Feb 2005 21:29:32 +0100 (MET) Date: Sat, 19 Feb 2005 21:29:32 +0100 From: Lennert Buytenhek To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Intel and TOE in the news Message-ID: <20050219202931.GA21315@xi.wantstofly.org> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050219114624.373af63f.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 2564 Lines: 51 On Sat, Feb 19, 2005 at 11:46:24AM -0800, David S. Miller wrote: > > I wonder if they could just take the network processing circuitry from > > the IXP2800 (an extra 16-core (!) RISCy processor on-die, dedicated to > > doing just network stuff, and a 10gbps pipe going straight into the CPU > > itself) and graft it onto the Xeon. > > > > Now _that_ would be something worth experiencing. > > No, that would be garbage. > > Read what they are doing. The idea is not to have all of this network > protocol logic off-cpu, the idea is to "reduce some of the time > a processor typically spends waiting for memory to feed back information" I agree that offloading just for the sake of offloading is silly. The reason a 1.4GHz IXP2800 processes 15Mpps while a high-end PC hardly does 1Mpps is exactly because the PC spends all of its cycles stalling on memory and PCI reads (i.e. 'latency'), and the IXP2800 has various ways of mitigating this cost that the PC doesn't have. First of all, the IXP has 16 cores which are 8-way 'hyperthreaded' each (128 threads total.) Second, the SDRAM controller and the the NIC circuitry are all on-chip, which saves you having to cross the FSB and the PCI bus a gazillion times for everything you do. (An L2 miss is hundreds of wasted cycles, and just reading the interrupt status register of the e1000 that's on a dedicated 64bit 100MHz PCI bus is ~2500 wasted cycles on my Xeon 2.4GHz.) Third, SDRAM is treated as an async resource -- i.e. you submit a memory read or write, and get an async signal when it's done, so you can do other stuff instead of stalling. The goal of the IXP2800 design, AFAICS, was not to create the possiblity to offload the TCP stack per se, but to create an architecture that is better suited to the kind of nonlocal reference patterns that you see with network traffic. It wasn't even specifically designed for offloading things as such. For something somewhat more conventional, look at the Broadcom BCM1250: a dual core MIPS CPU, relatively slow (600MHz-1GHz), but with three GigE MACs and a SDRAM controller inside the CPU. It gives the PC a good run for its money for networking stuff. Any kind of "make networking go faster" solution will be all about reducing the cost of latency, and less about increasing raw processing power. Multi-core CPUs help not because they have more MIPS, but because if they stall, it's only one core that stalls and all the other cores just keep on going. For certain tasks, I'll take a 4-core 1.0GHz CPU over a single-core 4.0GHz one any day. --L From buytenh@wantstofly.org Sat Feb 19 12:32:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 12:32:09 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JKW5kC008245 for ; Sat, 19 Feb 2005 12:32:06 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 08AE22B0EC; Sat, 19 Feb 2005 21:32:05 +0100 (MET) Date: Sat, 19 Feb 2005 21:32:04 +0100 From: Lennert Buytenhek To: Andi Kleen Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Intel and TOE in the news Message-ID: <20050219203204.GB21315@xi.wantstofly.org> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 395 Lines: 12 On Sat, Feb 19, 2005 at 09:27:31PM +0100, Andi Kleen wrote: > It would be nice if the NIC could asynchronously trigger prefetches > in the CPU. Currently a lot of the packet processing cost goes to > waiting for read cache misses. I've been told that this is something that the BCM-1250 can do. The MACs are in the CPU, and they can (reportedly) DMA the packet headers straight into L2. --L From romieu@fr.zoreil.com Sat Feb 19 14:31:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 14:31:42 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1JMVVef011659 for ; Sat, 19 Feb 2005 14:31:32 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1JMUKXp004280; Sat, 19 Feb 2005 23:30:20 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1JMUC3B004279; Sat, 19 Feb 2005 23:30:12 +0100 Date: Sat, 19 Feb 2005 23:30:12 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up Message-ID: <20050219223012.GA3601@electric-eye.fr.zoreil.com> References: <200502161823.43562.jdmason@us.ibm.com> <200502181918.07859.jdmason@us.ibm.com> <20050219104640.GA31035@electric-eye.fr.zoreil.com> <200502191147.14845.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502191147.14845.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1828 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: 4024 Lines: 104 Jon Mason : [...] > I never said it was pretty, simply a working snapshot of my test driver. I > figured that I had been promising you this update for so long, I better send > it out before you get upset with me. ;-) No, no, I meant mangled as in "kmail fcuked the tabs again". [...] > The change to opts1 seems cleaner to me. As the only the that the adapter > needs to know is the RingEnd. I can try removing it and see if it makes any > difference. Until there is a stability or performance reason for it, I will not take the change: - it would add one extra parameter in any future problem report; - neither me nor you can reproduce on it the testing done on the current form. I would lazily label it as too much work with too low a priority. > Opts2 is VERY necessary to zero. Without this zero, the adapter will change > the partition point randomly of each packet (random because I have yet to > determine the rhyme or reason). I didn't want to spend too much time trying > to determine the bahavior of this since I found out that zeroing it solved > the problem. If you can think of a reason why this doesn't work, I can > always go back and try to figure it out. Ok, this one really changes the behavior of the driver. [...] > See above for reason. I can re-order the operations and a mb (rmd I would > think). So this one changes the behavior of the driver as well, right ? The window may be narrow but I'll sleep more quietly if the ordering is modified and the memory barrier added. [...] > > Why is rtl8169_rx_csum() moved around ? > > Seemed to make more sense to me to have it after the > pci_dma_sync_single_for_cpu. If you disagree, I can move it back. rtl8169_rx_csum() only uses the consistent DMA mapping so it does not care. [skb_put/memcpy duplication] > > Me too, but I couldn't think of a better way. Suggestions welcomed. Nothing fancy. Something like: len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; memcpy(skb->data, sk_buff[0]->tail, len); skb_put(skb, len); > > 5 - rtl8169_return_to_asic() in rtl8169_rx_copy() seems suspect > > when FirstFrag is true and the skb allocation failed. > > In this case the desc is only a portion of the whole packet. I thought it > best to toss the whole packet if the driver couldn't alloc a skb, and return > the descriptor so that it can be used again. 1 - the packet could be under rx_copybreak as well; 2 - the driver currently defers the loss of a packet until there is no memory pointed by the current descriptor used for Rx DMA from the adapter. If it is refilled soon enough, no one notices it. > Actually, talking about this gave me an idea. Since desc_part is the largest > skb we will ever need (aside from when they are combined), it would be more > efficient to use that instead of the full size. I will create a patch for > this (and the mb changes) and resubmit it. Let me know if you want me to > return other things to their original spot. I am not sure I understand exactly what you mean. If you are saying that the max size is known and can be allocated in advance so that only the rx_copybreak calls for an instant allocation, we are saying the same thing (actually this should have been point 3- above :o) ). It will make my life easier if the patch only contains the minimal amount of changes (easier reviewing, testing, confidence, blah blah, it's boring but you got the idea). > > 6 - skb_put() ends duplicated. It should be possible to avoid it. > > Is it? I was specifically trying to aviod that. Where do you see that? -> + if (rtl8169_rx_copy(&skb, pkt_size, desc, tp)) { pci_action = pci_unmap_single; tp->Rx_skbuff[entry] = NULL; + skb_put(skb, pkt_size); } -> rtl8169_rx_copy() Lots of skb_put() Don't bother too much about this one. I had expected to keep the skb->dev = ...; skb_put(...); skb->proto = ... sequence as is to minimize the changes but it is not necessarily doable/sane. -- Ueimor From kaber@trash.net Sat Feb 19 21:31:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 21:31:31 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K5VNWK027491 for ; Sat, 19 Feb 2005 21:31:24 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2jg3-0002gT-H9; Sun, 20 Feb 2005 06:30:43 +0100 Message-ID: <42182082.9060301@trash.net> Date: Sun, 20 Feb 2005 06:30:42 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Maillist netdev Subject: Re: [XFRM]: Fix ICMP tempsel References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> In-Reply-To: <20050219184351.GB10773@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070001030401070402070602" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 4985 Lines: 165 This is a multi-part message in MIME format. --------------070001030401070402070602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > I know this comment is probably a bit late but why didn't we simply put > type/code into sport/dport in struct flowi instead of introducing the > monstrosities of xfrm_flowi_sport/xfrm_flowi_dport? > > Something like > > struct { > __u16 type; > __u16 code; > } icmpt; > > would've done (and still would do) the trick, no? Here is an updated patch that kills xfrm_flowi_{sport,dport}. I've checked around, there seems to be nothing that relies on type and code beeing u8. --------------070001030401070402070602 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/20 06:19:59+01:00 kaber@coreworks.de # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport # and kills xfrm_flowi_sport/dport instead of changing xfrm_init_tempsel(), # as suggested by Herbert Xu. # # Signed-off-by: Patrick McHardy # # include/net/xfrm.h # 2005/02/20 06:19:50+01:00 kaber@coreworks.de +4 -44 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport # and kills xfrm_flowi_sport/dport instead of changing xfrm_init_tempsel(), # as suggested by Herbert Xu. # # Signed-off-by: Patrick McHardy # # include/net/flow.h # 2005/02/20 06:19:50+01:00 kaber@coreworks.de +2 -2 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport # and kills xfrm_flowi_sport/dport instead of changing xfrm_init_tempsel(), # as suggested by Herbert Xu. # # Signed-off-by: Patrick McHardy # diff -Nru a/include/net/flow.h b/include/net/flow.h --- a/include/net/flow.h 2005-02-20 06:20:34 +01:00 +++ b/include/net/flow.h 2005-02-20 06:20:34 +01:00 @@ -58,8 +58,8 @@ } ports; struct { - __u8 type; - __u8 code; + __u16 type; + __u16 code; } icmpt; struct { diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2005-02-20 06:20:34 +01:00 +++ b/include/net/xfrm.h 2005-02-20 06:20:34 +01:00 @@ -417,53 +417,13 @@ return 1; } -static __inline__ -u16 xfrm_flowi_sport(struct flowi *fl) -{ - u16 port; - switch(fl->proto) { - case IPPROTO_TCP: - case IPPROTO_UDP: - case IPPROTO_SCTP: - port = fl->fl_ip_sport; - break; - case IPPROTO_ICMP: - case IPPROTO_ICMPV6: - port = htons(fl->fl_icmp_type); - break; - default: - port = 0; /*XXX*/ - } - return port; -} - -static __inline__ -u16 xfrm_flowi_dport(struct flowi *fl) -{ - u16 port; - switch(fl->proto) { - case IPPROTO_TCP: - case IPPROTO_UDP: - case IPPROTO_SCTP: - port = fl->fl_ip_dport; - break; - case IPPROTO_ICMP: - case IPPROTO_ICMPV6: - port = htons(fl->fl_icmp_code); - break; - default: - port = 0; /*XXX*/ - } - return port; -} - static inline int __xfrm4_selector_match(struct xfrm_selector *sel, struct flowi *fl) { return addr_match(&fl->fl4_dst, &sel->daddr, sel->prefixlen_d) && addr_match(&fl->fl4_src, &sel->saddr, sel->prefixlen_s) && - !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) && - !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) && + !((fl->fl_ip_dport ^ sel->dport) & sel->dport_mask) && + !((fl->fl_ip_sport ^ sel->sport) & sel->sport_mask) && (fl->proto == sel->proto || !sel->proto) && (fl->oif == sel->ifindex || !sel->ifindex); } @@ -473,8 +433,8 @@ { return addr_match(&fl->fl6_dst, &sel->daddr, sel->prefixlen_d) && addr_match(&fl->fl6_src, &sel->saddr, sel->prefixlen_s) && - !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) && - !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) && + !((fl->fl_ip_dport ^ sel->dport) & sel->dport_mask) && + !((fl->fl_ip_sport ^ sel->sport) & sel->sport_mask) && (fl->proto == sel->proto || !sel->proto) && (fl->oif == sel->ifindex || !sel->ifindex); } --------------070001030401070402070602-- From yoshfuji@linux-ipv6.org Sat Feb 19 22:54:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 22:54:18 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K6sC66030079 for ; Sat, 19 Feb 2005 22:54:12 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1B87533CC2; Sun, 20 Feb 2005 15:55:29 +0900 (JST) Date: Sun, 20 Feb 2005 15:55:27 +0900 (JST) Message-Id: <20050220.155527.54695259.yoshfuji@linux-ipv6.org> To: kaber@trash.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [XFRM]: Fix ICMP tempsel From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <42182082.9060301@trash.net> References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1830 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: 1184 Lines: 36 In article <42182082.9060301@trash.net> (at Sun, 20 Feb 2005 06:30:42 +0100), Patrick McHardy says: > Herbert Xu wrote: > > > I know this comment is probably a bit late but why didn't we simply put > > type/code into sport/dport in struct flowi instead of introducing the > > monstrosities of xfrm_flowi_sport/xfrm_flowi_dport? > > > > Something like > > > > struct { > > __u16 type; > > __u16 code; > > } icmpt; > > > > would've done (and still would do) the trick, no? > > Here is an updated patch that kills xfrm_flowi_{sport,dport}. > I've checked around, there seems to be nothing that relies > on type and code beeing u8. I didn't this because there are several places which depend on u8. If we go this way, we need to fix other places as well. e.g. net/ipv4/raw.c:raw_probe_proto_opt() net/ipv4/xfrm4_policy.c:_decode_session4() net/ipv6/raw.c:rawv6_probe_proto_opt() net/ipv6/netfilter/ip6t_REJECT.c:send_unreach() net/ipv6/xfrm6_policy.c:_decode_session6() net/ipv6/ndisc.c:ndisc_flow_init() net/ipv6/icmp.c:icmpv6_send() net/ipv6/icmp.c:icmpv6_echo_reply() (Note that type and code are stored in network-byte order.) --yoshfuji From herbert@gondor.apana.org.au Sat Feb 19 22:57:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 22:57:54 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K6vj5X030756 for ; Sat, 19 Feb 2005 22:57:46 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2l29-0000am-00; Sun, 20 Feb 2005 17:57:37 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2l1s-0006ou-00; Sun, 20 Feb 2005 17:57:20 +1100 Date: Sun, 20 Feb 2005 17:57:20 +1100 To: Patrick McHardy Cc: Maillist netdev Subject: Re: IPsec xfrm resolution Message-ID: <20050220065720.GA26175@gondor.apana.org.au> References: <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <42173125.3040505@trash.net> <20050219183202.GA10773@gondor.apana.org.au> <421789AF.4020705@trash.net> <20050219190333.GA22166@gondor.apana.org.au> <4217993D.4070107@trash.net> <4217A0DA.7050409@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217A0DA.7050409@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 609 Lines: 18 On Sat, Feb 19, 2005 at 09:26:02PM +0100, Patrick McHardy wrote: > > How about this patch ? It ignores "optional" for missing tunnel mode > SAs, symetric > to input. Actually, I've been convinced by your earlier argument :) I now think that IPCOMP users like racoon/openswan should simply not set the optional flag on the sending policy. It only needs to be set on the receiving side. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sat Feb 19 23:14:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 23:14:21 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K7EHE2031562 for ; Sat, 19 Feb 2005 23:14:18 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2lHV-0000tV-1Q; Sun, 20 Feb 2005 08:13:29 +0100 Message-ID: <42183898.7020607@trash.net> Date: Sun, 20 Feb 2005 08:13:28 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org CC: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> <20050220.155527.54695259.yoshfuji@linux-ipv6.org> In-Reply-To: <20050220.155527.54695259.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1330 Lines: 61 YOSHIFUJI Hideaki / $B5HF#1QL@ wrote: > I didn't this because there are several places which depend on u8. > If we go this way, we need to fix other places as well. e.g. > > net/ipv4/raw.c:raw_probe_proto_opt() get_user(fl->fl_icmp_type, type); __get_user(fl->fl_icmp_code, code); On x86_64 both care only about the pointer type, not the target type. > net/ipv4/xfrm4_policy.c:_decode_session4() u8 *icmp = xprth; fl->fl_icmp_type = icmp[0]; fl->fl_icmp_code = icmp[1]; No problem here. > net/ipv6/raw.c:rawv6_probe_proto_opt() Same as IPv4. > net/ipv6/netfilter/ip6t_REJECT.c:send_unreach() Not in mainline :) > net/ipv6/xfrm6_policy.c:_decode_session6() Same as IPv4. > net/ipv6/ndisc.c:ndisc_flow_init() fl->fl_icmp_type = type; fl->fl_icmp_code = 0; No problem. > net/ipv6/icmp.c:icmpv6_send() fl.fl_icmp_type = type; fl.fl_icmp_code = code; Also ok. > net/ipv6/icmp.c:icmpv6_echo_reply() fl.fl_icmp_type = ICMPV6_ECHO_REPLY; Same here. > > (Note that type and code are stored in network-byte order.) Both are u8 so there is no byte order. Regards Patrick From herbert@gondor.apana.org.au Sat Feb 19 23:38:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Feb 2005 23:38:21 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K7cBTs032662 for ; Sat, 19 Feb 2005 23:38:12 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2lf0-0000kT-00; Sun, 20 Feb 2005 18:37:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2leZ-0003Oa-00; Sun, 20 Feb 2005 18:37:19 +1100 Date: Sun, 20 Feb 2005 18:37:19 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: kaber@trash.net, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel Message-ID: <20050220073719.GA13008@gondor.apana.org.au> References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> <20050220.155527.54695259.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20050220.155527.54695259.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3607 Lines: 127 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 20, 2005 at 03:55:27PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > I didn't this because there are several places which depend on u8. > If we go this way, we need to fix other places as well. e.g. Good point. However, I think it's better to fix things up once when we cross from user-space to the kernel rather than converting it for every single packet. So here we can do something like this. Please note that this patch needs to be used with Patrick's earlier work. Patrick, if you're OK with it please merge it in with your patch. By all means give xfrm_selector_fixup a better name :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/key/af_key.c 1.69 vs edited ===== --- 1.69/net/key/af_key.c 2005-01-26 16:53:19 +11:00 +++ edited/net/key/af_key.c 2005-02-20 18:26:57 +11:00 @@ -1914,6 +1914,8 @@ if (xp->selector.dport) xp->selector.dport_mask = ~0; + xfrm_selector_fixup(&xp->selector); + xp->lft.soft_byte_limit = XFRM_INF; xp->lft.hard_byte_limit = XFRM_INF; xp->lft.soft_packet_limit = XFRM_INF; @@ -2004,6 +2006,7 @@ if (sel.dport) sel.dport_mask = ~0; + xfrm_selector_fixup(&sel); xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &sel, 1); if (xp == NULL) return -ENOENT; ===== net/xfrm/xfrm_user.c 1.52 vs edited ===== --- 1.52/net/xfrm/xfrm_user.c 2005-01-26 16:53:19 +11:00 +++ edited/net/xfrm/xfrm_user.c 2005-02-20 18:23:41 +11:00 @@ -204,6 +204,7 @@ { memcpy(&x->id, &p->id, sizeof(x->id)); memcpy(&x->sel, &p->sel, sizeof(x->sel)); + xfrm_selector_fixup(&x->sel); memcpy(&x->lft, &p->lft, sizeof(x->lft)); x->props.mode = p->mode; x->props.replay_window = p->replay_window; @@ -626,6 +627,7 @@ xp->priority = p->priority; xp->index = p->index; memcpy(&xp->selector, &p->sel, sizeof(xp->selector)); + xfrm_selector_fixup(&xp->selector); memcpy(&xp->lft, &p->lft, sizeof(xp->lft)); xp->action = p->action; xp->flags = p->flags; @@ -808,6 +810,7 @@ struct xfrm_userpolicy_id *p; int err; int delete; + struct xfrm_selector sel; p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -818,8 +821,11 @@ if (p->index) xp = xfrm_policy_byid(p->dir, p->index, delete); - else + else { + memcpy(&sel, &p->sel, sizeof(sel)); + xfrm_selector_fixup(&sel); xp = xfrm_policy_bysel(p->dir, &p->sel, delete); + } if (xp == NULL) return -ENOENT; ===== include/net/flow.h 1.11 vs edited ===== --- 1.11/include/net/flow.h 2004-03-19 15:20:28 +11:00 +++ edited/include/net/flow.h 2005-02-20 18:07:39 +11:00 @@ -58,7 +58,9 @@ } ports; struct { + __u8 pad1; __u8 type; + __u8 pad2; __u8 code; } icmpt; ===== include/net/xfrm.h 1.74 vs edited ===== --- 1.74/include/net/xfrm.h 2005-01-26 16:53:19 +11:00 +++ edited/include/net/xfrm.h 2005-02-20 18:29:01 +11:00 @@ -492,6 +492,17 @@ return 0; } +static inline void xfrm_selector_fixup(struct xfrm_selector *sel) +{ + switch (sel->proto) { + case IPPROTO_ICMP: + case IPPROTO_ICMPV6: + sel->sport_mask &= htons(0xff); + sel->dport_mask &= htons(0xff); + break; + } +} + /* A struct encoding bundle of transformations to apply to some set of flow. * * dst->child points to the next element of bundle. --VbJkn9YxBvnuCH5J-- From kaber@trash.net Sun Feb 20 00:36:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 00:36:07 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K8a0op005338 for ; Sun, 20 Feb 2005 00:36:01 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2mYc-0002Ga-Ud; Sun, 20 Feb 2005 09:35:14 +0100 Message-ID: <42184BC2.1030907@trash.net> Date: Sun, 20 Feb 2005 09:35:14 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> <20050220.155527.54695259.yoshfuji@linux-ipv6.org> <20050220073719.GA13008@gondor.apana.org.au> In-Reply-To: <20050220073719.GA13008@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------030203030103040308070504" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 8667 Lines: 280 This is a multi-part message in MIME format. --------------030203030103040308070504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > So here we can do something like this. Please note that this patch > needs to be used with Patrick's earlier work. Patrick, if you're > OK with it please merge it in with your patch. Attached. Now I understand what Yoshifuji meant with byteorder :) > > By all means give xfrm_selector_fixup a better name :) I'm not very talented with choosing good names myself, so I kept it. On second thought .. isn't there a risk of confusing userspace by changing the masks ? Regards Patrick --------------030203030103040308070504 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/20 09:29:12+01:00 kaber@coreworks.de # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport, # kills xfrm_flowi_{sport,dport} and converts the selector values only once # when they enter the kernel. # # Mostly done by Herbert Xu # # Signed-off-by: Patrick McHardy # # net/xfrm/xfrm_user.c # 2005/02/20 09:29:04+01:00 kaber@coreworks.de +7 -1 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport, # kills xfrm_flowi_{sport,dport} and converts the selector values only once # when they enter the kernel. # # Mostly done by Herbert Xu # # Signed-off-by: Patrick McHardy # # net/key/af_key.c # 2005/02/20 09:29:04+01:00 kaber@coreworks.de +3 -0 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport, # kills xfrm_flowi_{sport,dport} and converts the selector values only once # when they enter the kernel. # # Mostly done by Herbert Xu # # Signed-off-by: Patrick McHardy # # include/net/xfrm.h # 2005/02/20 09:29:04+01:00 kaber@coreworks.de +15 -44 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport, # kills xfrm_flowi_{sport,dport} and converts the selector values only once # when they enter the kernel. # # Mostly done by Herbert Xu # # Signed-off-by: Patrick McHardy # # include/net/flow.h # 2005/02/20 09:29:04+01:00 kaber@coreworks.de +2 -0 # [XFRM]: Fix ICMP tempsel # # The selector ports are initialized to fl_ip_sport/fl_ip_dport instead # of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, # type and code should be stored in sport and dport, in struct flowi both # are contained in fl_ip_sport. # # This patch adjusts struct flowi to store ICMP type/code in sport/dport, # kills xfrm_flowi_{sport,dport} and converts the selector values only once # when they enter the kernel. # # Mostly done by Herbert Xu # # Signed-off-by: Patrick McHardy # diff -Nru a/include/net/flow.h b/include/net/flow.h --- a/include/net/flow.h 2005-02-20 09:30:04 +01:00 +++ b/include/net/flow.h 2005-02-20 09:30:04 +01:00 @@ -58,7 +58,9 @@ } ports; struct { + __u8 pad1; __u8 type; + __u8 pad2; __u8 code; } icmpt; diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2005-02-20 09:30:04 +01:00 +++ b/include/net/xfrm.h 2005-02-20 09:30:04 +01:00 @@ -417,53 +417,13 @@ return 1; } -static __inline__ -u16 xfrm_flowi_sport(struct flowi *fl) -{ - u16 port; - switch(fl->proto) { - case IPPROTO_TCP: - case IPPROTO_UDP: - case IPPROTO_SCTP: - port = fl->fl_ip_sport; - break; - case IPPROTO_ICMP: - case IPPROTO_ICMPV6: - port = htons(fl->fl_icmp_type); - break; - default: - port = 0; /*XXX*/ - } - return port; -} - -static __inline__ -u16 xfrm_flowi_dport(struct flowi *fl) -{ - u16 port; - switch(fl->proto) { - case IPPROTO_TCP: - case IPPROTO_UDP: - case IPPROTO_SCTP: - port = fl->fl_ip_dport; - break; - case IPPROTO_ICMP: - case IPPROTO_ICMPV6: - port = htons(fl->fl_icmp_code); - break; - default: - port = 0; /*XXX*/ - } - return port; -} - static inline int __xfrm4_selector_match(struct xfrm_selector *sel, struct flowi *fl) { return addr_match(&fl->fl4_dst, &sel->daddr, sel->prefixlen_d) && addr_match(&fl->fl4_src, &sel->saddr, sel->prefixlen_s) && - !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) && - !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) && + !((fl->fl_ip_dport ^ sel->dport) & sel->dport_mask) && + !((fl->fl_ip_sport ^ sel->sport) & sel->sport_mask) && (fl->proto == sel->proto || !sel->proto) && (fl->oif == sel->ifindex || !sel->ifindex); } @@ -473,8 +433,8 @@ { return addr_match(&fl->fl6_dst, &sel->daddr, sel->prefixlen_d) && addr_match(&fl->fl6_src, &sel->saddr, sel->prefixlen_s) && - !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) && - !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) && + !((fl->fl_ip_dport ^ sel->dport) & sel->dport_mask) && + !((fl->fl_ip_sport ^ sel->sport) & sel->sport_mask) && (fl->proto == sel->proto || !sel->proto) && (fl->oif == sel->ifindex || !sel->ifindex); } @@ -490,6 +450,17 @@ return __xfrm6_selector_match(sel, fl); } return 0; +} + +static inline void xfrm_selector_fixup(struct xfrm_selector *sel) +{ + switch (sel->proto) { + case IPPROTO_ICMP: + case IPPROTO_ICMPV6: + sel->sport_mask &= htons(0xff); + sel->dport_mask &= htons(0xff); + break; + } } /* A struct encoding bundle of transformations to apply to some set of flow. diff -Nru a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c 2005-02-20 09:30:04 +01:00 +++ b/net/key/af_key.c 2005-02-20 09:30:04 +01:00 @@ -1909,6 +1909,8 @@ if (xp->selector.dport) xp->selector.dport_mask = ~0; + xfrm_selector_fixup(&xp->selector); + xp->lft.soft_byte_limit = XFRM_INF; xp->lft.hard_byte_limit = XFRM_INF; xp->lft.soft_packet_limit = XFRM_INF; @@ -1999,6 +2001,7 @@ if (sel.dport) sel.dport_mask = ~0; + xfrm_selector_fixup(&sel); xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &sel, 1); if (xp == NULL) return -ENOENT; diff -Nru a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c --- a/net/xfrm/xfrm_user.c 2005-02-20 09:30:04 +01:00 +++ b/net/xfrm/xfrm_user.c 2005-02-20 09:30:04 +01:00 @@ -204,6 +204,7 @@ { memcpy(&x->id, &p->id, sizeof(x->id)); memcpy(&x->sel, &p->sel, sizeof(x->sel)); + xfrm_selector_fixup(&x->sel); memcpy(&x->lft, &p->lft, sizeof(x->lft)); x->props.mode = p->mode; x->props.replay_window = p->replay_window; @@ -626,6 +627,7 @@ xp->priority = p->priority; xp->index = p->index; memcpy(&xp->selector, &p->sel, sizeof(xp->selector)); + xfrm_selector_fixup(&xp->selector); memcpy(&xp->lft, &p->lft, sizeof(xp->lft)); xp->action = p->action; xp->flags = p->flags; @@ -808,6 +810,7 @@ struct xfrm_userpolicy_id *p; int err; int delete; + struct xfrm_selector sel; p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -818,8 +821,11 @@ if (p->index) xp = xfrm_policy_byid(p->dir, p->index, delete); - else + else { + memcpy(&sel, &p->sel, sizeof(sel)); + xfrm_selector_fixup(&sel); xp = xfrm_policy_bysel(p->dir, &p->sel, delete); + } if (xp == NULL) return -ENOENT; --------------030203030103040308070504-- From yoshfuji@linux-ipv6.org Sun Feb 20 00:57:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 00:57:05 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1K8uxBD006321 for ; Sun, 20 Feb 2005 00:57:00 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0272033CC2; Sun, 20 Feb 2005 17:58:16 +0900 (JST) Date: Sun, 20 Feb 2005 17:58:15 +0900 (JST) Message-Id: <20050220.175815.50673619.yoshfuji@linux-ipv6.org> To: kaber@trash.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [XFRM]: Fix ICMP tempsel From: YOSHIFUJI Hideaki In-Reply-To: <42184BC2.1030907@trash.net> References: <20050220.155527.54695259.yoshfuji@linux-ipv6.org> <20050220073719.GA13008@gondor.apana.org.au> <42184BC2.1030907@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1835 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: 497 Lines: 13 In article <42184BC2.1030907@trash.net> (at Sun, 20 Feb 2005 09:35:14 +0100), Patrick McHardy says: > Herbert Xu wrote: > > So here we can do something like this. Please note that this patch > > needs to be used with Patrick's earlier work. Patrick, if you're > > OK with it please merge it in with your patch. > > Attached. Now I understand what Yoshifuji meant with byteorder :) Sorry, still it seems wrong. Please allow me several hours. --yoshfuji @ on the way home... From herbert@gondor.apana.org.au Sun Feb 20 03:13:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 03:13:38 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KBDT4C011550 for ; Sun, 20 Feb 2005 03:13:31 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D2p1F-0001Vu-00; Sun, 20 Feb 2005 22:12:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D2p0d-0006dk-00; Sun, 20 Feb 2005 22:12:19 +1100 Date: Sun, 20 Feb 2005 22:12:19 +1100 To: Patrick McHardy Cc: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel Message-ID: <20050220111219.GA25499@gondor.apana.org.au> References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> <20050220.155527.54695259.yoshfuji@linux-ipv6.org> <20050220073719.GA13008@gondor.apana.org.au> <42184BC2.1030907@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42184BC2.1030907@trash.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 765 Lines: 21 On Sun, Feb 20, 2005 at 09:35:14AM +0100, Patrick McHardy wrote: > > On second thought .. isn't there a risk of confusing userspace by > changing the masks ? It only affects xfrm_user users, of which I only know two -- Openswan and ip(8). Neither of which should care about it. However, I forgot to do the fixup in __xfrm[46]_init_tempsel and that is going to confuse the kernel itself :) It is looking more and more like a nasty hack though so maybe it's not worth it since the policy checks are still bloated enough even after we do this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Feb 20 03:21:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 03:21:47 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KBLhqk012148 for ; Sun, 20 Feb 2005 03:21:43 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D2p91-0002kD-0L; Sun, 20 Feb 2005 12:20:59 +0100 Message-ID: <4218729A.4080201@trash.net> Date: Sun, 20 Feb 2005 12:20:58 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel References: <4217266F.6090700@trash.net> <20050219184351.GB10773@gondor.apana.org.au> <42182082.9060301@trash.net> <20050220.155527.54695259.yoshfuji@linux-ipv6.org> <20050220073719.GA13008@gondor.apana.org.au> <42184BC2.1030907@trash.net> <20050220111219.GA25499@gondor.apana.org.au> In-Reply-To: <20050220111219.GA25499@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 235 Lines: 9 Herbert Xu wrote: > It is looking more and more like a nasty hack though so maybe > it's not worth it since the policy checks are still bloated enough > even after we do this. Agreed. Let's just take the first patch. Regards Patrick From yoshfuji@linux-ipv6.org Sun Feb 20 03:58:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 03:58:54 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KBwm5r013486 for ; Sun, 20 Feb 2005 03:58:49 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C80FD33CC2; Sun, 20 Feb 2005 21:00:05 +0900 (JST) Date: Sun, 20 Feb 2005 21:00:02 +0900 (JST) Message-Id: <20050220.210002.59645733.yoshfuji@linux-ipv6.org> To: kaber@trash.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4218729A.4080201@trash.net> References: <42184BC2.1030907@trash.net> <20050220111219.GA25499@gondor.apana.org.au> <4218729A.4080201@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1838 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: 410 Lines: 12 In article <4218729A.4080201@trash.net> (at Sun, 20 Feb 2005 12:20:58 +0100), Patrick McHardy says: > Herbert Xu wrote: > > It is looking more and more like a nasty hack though so maybe > > it's not worth it since the policy checks are still bloated enough > > even after we do this. > > Agreed. Let's just take the first patch. I totally agree. I belive it is the safest fix. --yoshfuji From willy@gardiol.org Sun Feb 20 08:12:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 08:12:59 -0800 (PST) Received: from smtpa1.aruba.it (smtpa1.aruba.it [62.149.128.206] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1KGCpTt028259 for ; Sun, 20 Feb 2005 08:12:52 -0800 Received: (qmail 25571 invoked by uid 511); 20 Feb 2005 16:12:44 -0000 Received: from willy@gardiol.org by smtpa1.aruba.it by uid 503 with qmail-scanner-1.20 (avp(2004-04-15). Clear:RC:0(213.140.6.110):. Processed in 0.039635 secs); 20 Feb 2005 16:12:44 -0000 Received: from unknown (HELO ?41.5.1.42?) (willy@gardiol.org@213.140.6.110) by smtpa1.aruba.it with SMTP; 20 Feb 2005 16:12:44 -0000 From: Willy Gardiol Reply-To: willy@gardiol.org To: Francois Romieu Subject: Re: The 8169 driver: issue with cross cable Date: Sun, 20 Feb 2005 17:12:46 +0100 User-Agent: KMail/1.7.2 References: <200502192011.25428.willy@gardiol.org> <20050219205055.GA2793@electric-eye.fr.zoreil.com> In-Reply-To: <20050219205055.GA2793@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1610967.7YtWMaESEO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502201712.49589.willy@gardiol.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@gardiol.org Precedence: bulk X-list: netdev Content-Length: 5345 Lines: 177 --nextPart1610967.7YtWMaESEO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Problem: r8169 hosed sporadically using a cross-cable. Configuration: =2D server side: x86 box with r8169 on a Hamlet PCI card, file server NFS.= =20 =2D client side: x86 box with r8169 inegrated on a nForce2 motherboard. NFS= =2Droot=20 on the server (no local hard drives, four NFS mounts) =2D connection: cross cable UTP CAT5 (Alternative configuration: =2D RTL-8139 (8139too module) PCI card on both boxes. With this configurati= on=20 (same kernel, same files, same cable) everything works great.) The problem is present with any kernel versions up to 2.6.10 (tried many=20 different kernels). Step to reproduce the problem: grab a few CDs with grip (tested with ATAPI= =20 cdrw without scsi emulation).=20 Syntomps: one of the mounts will be hosed while the others will work. After= =20 some time either the nfs activity hangs on all mounts or the hosed mount wi= ll=20 un-hose. Tipically it will hose again soon. I am now doing tests using kernel 2.6.11-r4 with Francois's patch. I did two tests, one at 1000mbit/sec and one at 100mbit/sec limiting the sp= eed=20 using ethtool. The problem persist in both tests. I launch grip and start grabbing a CD,=20 after the first track is read from che CD the process hangs. Then i start a= =20 second grip and start again ripping the same CD, this time the entire nfs=20 mount hangs. Per each test i reported some general data: Output of "lspci -vx" posted to: spci-vx.txt Output of "lsmod" posted to: modules.txt Output of boot posted to:dmesg.txt Output of ethtool on r8169 (and rtl-8139): ethtool.txt And specific data: Output ifconfig and interrupts immediately after boot:=20 interrupts-ifconfig-boot.txt After some activity (login/startx/launch konsole, a few pings, and launch o= f=20 grip): interrupts-ifconfig-initial.txt When the program grip is hosed: interrupts-ifconfig-hosed.txt When mount point /deposito is hosed: interrupts-ifconfig-hosed2.txt (note: grip works on /deposito) I bzip2ed all this files into two archives, one per each test (one couple p= er=20 server and one per client) You can get them at: http://www.gardiol.org/r8169/1000-client.tar.bz2 http://www.gardiol.org/r8169/1000-server.tar.bz2 http://www.gardiol.org/r8169/100-client.tar.bz2 http://www.gardiol.org/r8169/100-server.tar.bz2 At the beginning of each file i wrote the output of "uname -a". I am available for any more data. bye and thanks. ps: i am not subscribed to the list please keep me in CC. Alle Saturday 19 February 2005 21:50, hai scritto: > Willy Gardiol : > [...] > > > i am sorry to bother you directly. > > No problem but it would be nice to Cc: netdev@oss.sgi.com. > > [...] > > > I have a fileserver and a remote client which both have a r8169 based > > card. The server has a Hamlet card and the client has the gigabit chip > > integrated. > > An 'lspci -vx' would be welcome. So will a complete dmesg from boot. > > > The two machines are linked with a cross cable about 20mt long, UTP CAT= 5. > > Which link settings does the r8169 negociate ('ethtool ethX') ? > > [...] > > > During one of these locks i can, as usual, access the other nfs mounts. > > Ok. So the card is not hosed. > > > I tried to: > > - move PCI cards to avoid conflicts > > - upgraded to latest stable kernel 2.6.10 > > - removed any binary only driver > > - changed the server mounts and filesystems (ext3/reiserfs) > > > > Also, the problem is still present if i use one r8169 based and one > > rtl-8139 100mbit card. > > Do you notice packet loss/errors or such on the 8169 side ? Typically, how > does 'ifconfig' output like when a mount point is hosed ? > > > When i remove BOTH r8169 and use 100mbit only cards (two 8139 based pci > > cards) i do not suffer from these hangs. > > Which kind of 8139 driver: 8139too or 8139cp ? > > > What can i do to solve this problem, or help you on the subject? > > It will need some debugging. It is not clear if the r8169 is the issue or > if simply triggers the problem. Suggestions: > - use 2.6.10-rc4 + attached patch; > - avoid binary modules as I don't support them; > - if r8169 negociates 1000Mbps, use ethtool to limit it at 100Mbps; > - save the content of /proc/interrupts and ifconfig output at regular > interval (say, at boot, after some ping -q -f -l 16 a.b.c.d and once > a mountpoint is hung); > - avoid gcc 2.95.x; > - when a mountpoint is hung, issue 'echo t > /proc/sysrq-trigger' and save > the kernel output. This assumes CONFIG_MAGIC_SYSRQ=3Dy at build time and > kernel.sysrq =3D 1 in /etc/sysctl.conf. > > If you have a straight cable, two 8169 should be able to do the crossing > themselves. > > -- > Ueimor =2D-=20 !=20 Willy Gardiol - willy@gardiol.org www.gardiol.org +39 3492800983 Use linux for MY freedom.=20 Your freedom may come as a side effect. "Era un mondo adulto, si sbagliava da professionisti" Paolo Conte, Boogie --nextPart1610967.7YtWMaESEO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCGLcBvgbSPju7wvkRAqpIAKCV6KPYZgyO91suma91C7XKE8wIFwCeOgv9 09I/PoLoAuAZoD5zKOt1V+I= =8jOo -----END PGP SIGNATURE----- --nextPart1610967.7YtWMaESEO-- From ebs@ebshome.net Sun Feb 20 08:46:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 08:46:17 -0800 (PST) Received: from gate.ebshome.net (gate.ebshome.net [64.81.67.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KGkDTo000348 for ; Sun, 20 Feb 2005 08:46:13 -0800 Received: (qmail 24572 invoked by uid 1000); 20 Feb 2005 08:46:07 -0800 Date: Sun, 20 Feb 2005 08:46:07 -0800 From: Eugene Surovegin To: Andi Kleen Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Intel and TOE in the news Message-ID: <20050220164607.GA27891@gate.ebshome.net> Mail-Followup-To: Andi Kleen , "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ICQ-UIN: 1193073 X-Operating-System: Linux i686 X-PGP-Key: http://www.ebshome.net/pubkey.asc User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebs@ebshome.net Precedence: bulk X-list: netdev Content-Length: 529 Lines: 16 On Sat, Feb 19, 2005 at 09:27:31PM +0100, Andi Kleen wrote: > > > It would be nice if the NIC could asynchronously trigger prefetches in > the CPU. Currently a lot of the packet processing cost goes > to waiting for read cache misses. Just FYI :), Freescale 85xx TSECs can prefetch buffers into L2 cache. IIRC they call it buffer "stashing" and gianfar driver has a config option to enable such behavior. But in embedded world you usually don't see flashy PR releases for such features :). -- Eugene. From rich@phekda.gotadsl.co.uk Sun Feb 20 09:50:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 09:51:02 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KHooNE002266 for ; Sun, 20 Feb 2005 09:50:51 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [82.133.113.212]) by smtp.nildram.co.uk (Postfix) with ESMTP id E71102BED97; Sun, 20 Feb 2005 17:50:44 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 24167381DC; Sun, 20 Feb 2005 17:52:52 +0000 (GMT) Message-ID: <4218CE73.6010206@phekda.gotadsl.co.uk> Date: Sun, 20 Feb 2005 17:52:51 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up References: <200502161823.43562.jdmason@us.ibm.com> <20050217232804.GA4992@electric-eye.fr.zoreil.com> In-Reply-To: <20050217232804.GA4992@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 631 Lines: 25 Hello. Francois Romieu wrote: > Jon Mason : [snip] >>adds a link down notification, and cleans up > > > Ok. I'll netif_msg it before someone else complains that the driver > is too verbose. [snip] I started working on adding netif_msg checks to the printks. How far have you got? I don't want to duplicate your work. Incidentally, is there a to-do list somewhere for the r8169 driver? Maybe I can help out with some of the things. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From jdmason@us.ibm.com Sun Feb 20 10:04:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 10:04:46 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KI4ZSY003062 for ; Sun, 20 Feb 2005 10:04:41 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1KI4TMN494036 for ; Sun, 20 Feb 2005 13:04:29 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1KI4SPw065734 for ; Sun, 20 Feb 2005 11:04:28 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1KI4So7009290 for ; Sun, 20 Feb 2005 11:04:28 -0700 Received: from sig-9-65-12-11.mts.ibm.com (sig-9-65-12-11.mts.ibm.com [9.65.12.11]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1KI4Sfv009287; Sun, 20 Feb 2005 11:04:28 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Sun, 20 Feb 2005 12:04:23 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <200502191147.14845.jdmason@us.ibm.com> <20050219223012.GA3601@electric-eye.fr.zoreil.com> In-Reply-To: <20050219223012.GA3601@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: <200502201204.23468.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6909 Lines: 181 On Saturday 19 February 2005 04:30 pm, Francois Romieu wrote: > Jon Mason : > [...] > > > I never said it was pretty, simply a working snapshot of my test driver. > > I figured that I had been promising you this update for so long, I better > > send it out before you get upset with me. ;-) > > No, no, I meant mangled as in "kmail fcuked the tabs again". Not 100% sure it is a kmail problem (as it could be my IMAP server). I'll trying a different mail clent, and see if that makes any difference. Thanks for the heads-up. > [...] > > > The change to opts1 seems cleaner to me. As the only the that the > > adapter needs to know is the RingEnd. I can try removing it and see if > > it makes any difference. > > Until there is a stability or performance reason for it, I will not take > the change: > - it would add one extra parameter in any future problem report; > - neither me nor you can reproduce on it the testing done on the current > form. > > I would lazily label it as too much work with too low a priority. Actually, I removed it and it causes the partition point to move, similiar to opts2. I realize this isn't really an acceptable answer, so I will try to determine what is causing this weird behavior. > > Opts2 is VERY necessary to zero. Without this zero, the adapter will > > change the partition point randomly of each packet (random because I have > > yet to determine the rhyme or reason). I didn't want to spend too much > > time trying to determine the bahavior of this since I found out that > > zeroing it solved the problem. If you can think of a reason why this > > doesn't work, I can always go back and try to figure it out. > > Ok, this one really changes the behavior of the driver. > > [...] > > > See above for reason. I can re-order the operations and a mb (rmd I > > would think). > > So this one changes the behavior of the driver as well, right ? > > The window may be narrow but I'll sleep more quietly if the ordering is > modified and the memory barrier added. fixed. > [...] > > > > Why is rtl8169_rx_csum() moved around ? > > > > Seemed to make more sense to me to have it after the > > pci_dma_sync_single_for_cpu. If you disagree, I can move it back. > > rtl8169_rx_csum() only uses the consistent DMA mapping so it does not > care. returned to its original spot. > [skb_put/memcpy duplication] > > > Me too, but I couldn't think of a better way. Suggestions welcomed. > > Nothing fancy. Something like: > len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; > memcpy(skb->data, sk_buff[0]->tail, len); > skb_put(skb, len); fixed. > > > 5 - rtl8169_return_to_asic() in rtl8169_rx_copy() seems suspect > > > when FirstFrag is true and the skb allocation failed. > > > > In this case the desc is only a portion of the whole packet. I thought > > it best to toss the whole packet if the driver couldn't alloc a skb, and > > return the descriptor so that it can be used again. > > 1 - the packet could be under rx_copybreak as well; > 2 - the driver currently defers the loss of a packet until there is no > memory pointed by the current descriptor used for Rx DMA from the adapter. > If it is refilled soon enough, no one notices it. True, but this problem existed before I made the jumbo frames changes. The only way I can think to fix this is to do the following: static inline int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, struct RxDesc *desc, struct rtl8169_private *tp) { u32 status = le32_to_cpu(desc->opts1); if ((pkt_size > rx_copybreak) && ((status & FirstFrag) && (status & LastFrag))) return -1; if (status & FirstFrag) { struct sk_buff *skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); u32 len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; if (skb) { skb_reserve(skb, NET_IP_ALIGN); memcpy(skb->data, sk_buff[0]->tail, len); skb_put(skb, len); } else { printk(KERN_INFO "no rx skb allocated\n"); if (pkt_size <= rx_copybreak) return -1; } tp->new_skb = skb; } Is this acceptable? > > Actually, talking about this gave me an idea. Since desc_part is the > > largest skb we will ever need (aside from when they are combined), it > > would be more efficient to use that instead of the full size. I will > > create a patch for this (and the mb changes) and resubmit it. Let me > > know if you want me to return other things to their original spot. > > I am not sure I understand exactly what you mean. If you are saying that > the max size is known and can be allocated in advance so that only the > rx_copybreak calls for an instant allocation, we are saying the same thing > (actually this should have been point 3- above :o) ). No, I am saying that the max size is know for the skb rx ring and it is not rx_buf_sz, but desc_part. I don't currently have this in the driver, but I can add it where driver allocs smaller skbs for jumbo frames enabled rx ring. If I am still not making sense, I can be more verbose. > It will make my life easier if the patch only contains the minimal amount > of changes (easier reviewing, testing, confidence, blah blah, it's boring > but you got the idea). Sorry, I guess I got a little over eager. I will attempt to avoid this behavior in the future. Forgiveness please. > > > 6 - skb_put() ends duplicated. It should be possible to avoid it. > > > > Is it? I was specifically trying to aviod that. Where do you see that? > > -> > + if (rtl8169_rx_copy(&skb, pkt_size, desc, tp)) { > pci_action = pci_unmap_single; > tp->Rx_skbuff[entry] = NULL; > + skb_put(skb, pkt_size); > } > > -> rtl8169_rx_copy() > Lots of skb_put() Actually, I am using skb_put more frequently for a reason, and I probably need to explain why. In rtl8169_rx_copy(), I am using it to keep track of the end of the skb, so that the driver knows the point to concatinate the next desc to the skb. when it is all over, the tail points to the end of the skb and len is correct (which is the whole point of using skb_put), thereby removing the need to call it in the jumbo frames case. I realize this is being a little creative, but it is much cleaner code this way. Otherwise the driver will need a global counter to use as a offset of the skb->tail and call skb_put after it is all over. > Don't bother too much about this one. I had expected to keep the > skb->dev = ...; skb_put(...); skb->proto = ... sequence as is to > minimize the changes but it is not necessarily doable/sane. > > -- > Ueimor I will clean-up what I currently have with the changes you suggested and resend it. Thanks, Jon From jdmason@us.ibm.com Sun Feb 20 10:14:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 10:14:29 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KIEPYc003779 for ; Sun, 20 Feb 2005 10:14:25 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1KIEJ0D081066 for ; Sun, 20 Feb 2005 13:14:19 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1KIEJPw072052 for ; Sun, 20 Feb 2005 11:14:19 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1KIEI8K027578 for ; Sun, 20 Feb 2005 11:14:18 -0700 Received: from sig-9-65-12-11.mts.ibm.com (sig-9-65-12-11.mts.ibm.com [9.65.12.11]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1KIEIiH027575; Sun, 20 Feb 2005 11:14:18 -0700 From: Jon Mason Organization: IBM To: Richard Dawe Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Sun, 20 Feb 2005 12:14:15 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <20050217232804.GA4992@electric-eye.fr.zoreil.com> <4218CE73.6010206@phekda.gotadsl.co.uk> In-Reply-To: <4218CE73.6010206@phekda.gotadsl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502201214.15884.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 794 Lines: 29 On Sunday 20 February 2005 11:52 am, Richard Dawe wrote: > Hello. > > Francois Romieu wrote: > > Jon Mason : > > [snip] > > >>adds a link down notification, and cleans up > > > > Ok. I'll netif_msg it before someone else complains that the driver > > is too verbose. > > [snip] > > I started working on adding netif_msg checks to the printks. How far > have you got? I don't want to duplicate your work. > > Incidentally, is there a to-do list somewhere for the r8169 driver? Not to my knowledge. It would be nice if there was a wiki out there which lists all of the drivers and areas to work on (features enablement, open bugs, etc.) > Maybe I can help out with some of the things. I know Francois likes it when people test his patches. :-) > Thanks, bye, Rich =] From rick.jones2@hp.com Sun Feb 20 11:45:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 11:45:18 -0800 (PST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KJjEeb006001 for ; Sun, 20 Feb 2005 11:45:14 -0800 Received: from [192.168.1.100] (adsl-66-122-50-247.dsl.sntc01.pacbell.net [66.122.50.247]) by mailhub.hp.com (Postfix) with ESMTP id 8183D27115 for ; Sun, 20 Feb 2005 14:45:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91f1bcca156f343c17918ce67ef23666@hp.com> Content-Transfer-Encoding: 7bit From: rick jones Subject: Re: Intel and TOE in the news Date: Sun, 20 Feb 2005 11:45:02 -0800 To: netdev@oss.sgi.com X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 918 Lines: 25 > > > It would be nice if the NIC could asynchronously trigger prefetches in > the CPU. Currently a lot of the packet processing cost goes > to waiting for read cache misses. > > E.g. > > - NIC receives packet. > - Tells target CPU to prefetch RX descriptor and headers. > - CPU later looks at them and doesn't have to wait a for a cache miss. > > Drawback is that you would need to tell the NIC in advance > on which CPU you want to process the packet, but with Linux > IRQ affinity that's easy to figure out. With all the interrupt avoidance that is going-on these days, would prefetching in the driver be sufficient? Presumably the driver is going to be processing multiple packets at a time on an interrupt/etc so having it issue prefetches in SW would seem to help with all but the very first packet. rick jones Wisdom teeth are impacted, people are affected by the effects of events From webmaster@rapidforum.com Sun Feb 20 12:54:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 12:54:23 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1KKsHtf010947 for ; Sun, 20 Feb 2005 12:54:18 -0800 Received: (qmail 10548 invoked by uid 1004); 20 Feb 2005 20:54:15 -0000 Received: from p3ee04292.dip0.t-ipconnect.de (HELO ?62.224.66.146?) (62.224.66.146) by www.rapidforum.com with SMTP; 20 Feb 2005 20:54:15 -0000 Message-ID: <4218F8D8.3040605@rapidforum.com> Date: Sun, 20 Feb 2005 21:53:44 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Massvie problems with 3000 sockets Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 579 Lines: 12 Hello. I have a strange problem with 2.6.10 with many many downloaders. Sockets are set to be non-blocking of course. Its running fine until it needs more than around 3300 sockets (system-wide) then it suddenly blocks on a syswrite although its a non-blocking socket. It blocks only around 100 ms but with 3000 sockets its really a pain. Outgoing-traffic breaks down to 50% with 4000 sockets. I have limited the sockets to 3000 now since it doesn't happen then. Whats wrong there??? As said, it definetly blocks on a syswrite on a non-blocking socket. Best regards, Chris From mcr@sandelman.ottawa.on.ca Sun Feb 20 13:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 13:22:01 -0800 (PST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KLLpdU012635 for ; Sun, 20 Feb 2005 13:21:52 -0800 Received: from pike.sandelman.ca ([205.150.200.164]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id j1KLLfB17524 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 20 Feb 2005 16:21:43 -0500 (EST) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by pike.sandelman.ca (Postfix) with ESMTP id 32F96602D6; Sun, 20 Feb 2005 16:20:16 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 9747BBE22; Sun, 20 Feb 2005 16:20:15 -0500 (EST) To: rick jones Cc: netdev@oss.sgi.com Subject: Re: Intel and TOE in the news In-Reply-To: Message from rick jones of "Sun, 20 Feb 2005 11:45:02 PST." <91f1bcca156f343c17918ce67ef23666@hp.com> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> <91f1bcca156f343c17918ce67ef23666@hp.com> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 16) Date: Sun, 20 Feb 2005 16:20:15 -0500 Message-ID: <30841.1108934415@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 2276 Lines: 52 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "rick" == rick jones writes: >> - NIC receives packet. - Tells target CPU to prefetch RX >> descriptor and headers. - CPU later looks at them and doesn't >> have to wait a for a cache miss. >> >> Drawback is that you would need to tell the NIC in advance on >> which CPU you want to process the packet, but with Linux IRQ >> affinity that's easy to figure out. rick> With all the interrupt avoidance that is going-on these days, rick> would prefetching in the driver be sufficient? Presumably the rick> driver is going to be processing multiple packets at a time on rick> an interrupt/etc so having it issue prefetches in SW would rick> seem to help with all but the very first packet. I did prefetching of subsequent descriptor rings in the 200Mhz days, when the descriptors lived in the NIC card. It's rather hard to write in C :-) I did prefetching of packets on a PowerPC system (actually, it was inside a TOE-like device, living in a Linux 1U). This was done with altivec instructions, and was rather easy. On Intel, one can use MMX or floating point instructions to do the prefetch. The interrupt avoidance mechanism actually makes the prefetch easier, since you are already in the bottom half, so it is easier to do. The question is: how much to prefetch? BTW: in 1996 the IETF IPv6 WG briefly toyed with the idea of swapping the source and destination addresses in the IPv6 header. Having the dst first reduces a cache miss. They decided not to do this. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQhj/DYqHRg3pndX9AQHw8QP8CzXmHRgXWFOjU7TDpp4R73iiWmFtvrfq NjFOQ9FbHkhk/xU47hwayOq8VA07Xh4baQa5YE824a2BbnFn88bz5A4kGeSia0/i XLXEH+1d0QlWZ5ZJxPDwWyxszPorQpS8Mim+3GIcX24l2l9R7Y/x5hkVKHCZ/OuY hukjy7DiObQ= =h+QI -----END PGP SIGNATURE----- From ak@muc.de Sun Feb 20 13:29:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 13:29:56 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KLTpbS013374 for ; Sun, 20 Feb 2005 13:29:52 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 19484D033E; Sun, 20 Feb 2005 22:29:45 +0100 (CET) To: rick jones Cc: netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> <91f1bcca156f343c17918ce67ef23666@hp.com> From: Andi Kleen Date: Sun, 20 Feb 2005 22:29:45 +0100 In-Reply-To: <91f1bcca156f343c17918ce67ef23666@hp.com> (rick jones's message of "Sun, 20 Feb 2005 11:45:02 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1847 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: 2825 Lines: 65 rick jones writes: >> >> >> It would be nice if the NIC could asynchronously trigger prefetches in >> the CPU. Currently a lot of the packet processing cost goes >> to waiting for read cache misses. >> >> E.g. >> >> - NIC receives packet. >> - Tells target CPU to prefetch RX descriptor and headers. >> - CPU later looks at them and doesn't have to wait a for a cache miss. >> >> Drawback is that you would need to tell the NIC in advance >> on which CPU you want to process the packet, but with Linux >> IRQ affinity that's easy to figure out. > > With all the interrupt avoidance that is going-on these days, would > prefetching in the driver be sufficient? Presumably the driver is > going to be processing multiple packets at a time on an interrupt/etc > so having it issue prefetches in SW would seem to help with all but > the very first packet. Yes, we came up with this idea some years ago too ;-). It was even tried in some simple variants, but didn't work very well: - The time between finding out you have a packet and it being processed is often too short to make it worthwhile. That gets worse with NAPI under high load. - You have to fetch the RX descriptor anyways to find out where the packet memory is to prefetch the header, and that is a cache miss too. (presumably you could keep a second sw only cache hot table that allows to figure this out faster, that hasn't been tried so far) - It really requires a NIC that tells you in the RX descriptor if a packet is IP (some do, but other popular ones don't). Otherwise the network driver has to eat an early cache miss anyways to read the 802.x protocol ID for passing the packet up the network stack. (one possible fix for that would be to shift the protocol parsing to later to avoid this, but that would be an incompatible change in the driver interface) I guess with more intrusive changes Linux could do this better. e.g. if you have the cache hot secondary table and a really cheap way to find out from the NIC on a interrupt how many packets it accepted you could aggressive prefetching and do the protocol lookup later with a callback to the driver. But this has a problems too: - Even on modern CPUs you cannot do too many prefetches in parallel because you're overwhelming the load store units. At some points new prefetches just get ignored. On older CPUs this problem is even worse. Jamal and Robert did some experiments with routing on this and they ran also into this. If the NIC initiated the transfers the bandwidth of the CPU would be much more evenly used because the transfers are spaced out in time as the packets arrive. Software prefetch will be always bursty. However I agree that probably some smaller software only improvements could be still done in this area on Linux. -Andi From leonid.grossman@neterion.com Sun Feb 20 14:45:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 14:45:57 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KMjqYt016782 for ; Sun, 20 Feb 2005 14:45:53 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1KMj4dG019063; Sun, 20 Feb 2005 17:45:04 -0500 (EST) Received: from lgt40 ([10.16.16.165]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1KMinDD013572; Sun, 20 Feb 2005 17:44:50 -0500 (EST) Message-Id: <200502202244.j1KMinDD013572@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'rick jones'" Cc: , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Sun, 20 Feb 2005 14:43:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcUXk1TI7gNXKxiHSFGUkJrKOF4/VQAB9XNg X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 3962 Lines: 101 Andi, This is an interesting idea, we'll play around... BTW - does anybody know if it's possible to indicate multiple receive packets? In other OS drivers we have an option to indicate a "packet train" that got received during an interrupt, but I'm not sure if/how it's doable in Linux. We are adding Linux driver support for message-signaled interrupts and header separation (just recently figured out how to indicate chained skb for a packet that has IP and TCP headers separated by the ASIC); If a packet train indication works then the driver could prefetch the descriptor ring segment and also a rx buffer segment that holds headers stored back-to-back, before indicating the train. Leonid > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Andi Kleen > Sent: Sunday, February 20, 2005 1:30 PM > To: rick jones > Cc: netdev@oss.sgi.com > Subject: Re: Intel and TOE in the news > > rick jones writes: > > >> > >> > >> It would be nice if the NIC could asynchronously trigger > prefetches > >> in the CPU. Currently a lot of the packet processing cost goes to > >> waiting for read cache misses. > >> > >> E.g. > >> > >> - NIC receives packet. > >> - Tells target CPU to prefetch RX descriptor and headers. > >> - CPU later looks at them and doesn't have to wait a for a > cache miss. > >> > >> Drawback is that you would need to tell the NIC in advance > on which > >> CPU you want to process the packet, but with Linux IRQ affinity > >> that's easy to figure out. > > > > With all the interrupt avoidance that is going-on these days, would > > prefetching in the driver be sufficient? Presumably the driver is > > going to be processing multiple packets at a time on an > interrupt/etc > > so having it issue prefetches in SW would seem to help with all but > > the very first packet. > > Yes, we came up with this idea some years ago too ;-). It was > even tried in some simple variants, but didn't work very well: > > - The time between finding out you have a packet and it being > processed is often too short to make it worthwhile. That gets > worse with NAPI under high load. > - You have to fetch the RX descriptor anyways to find out > where the packet memory is to prefetch the header, and that > is a cache miss too. > (presumably you could keep a second sw only cache hot table > that allows to figure this out faster, that hasn't been tried so far) > - It really requires a NIC that tells you in the RX > descriptor if a packet is IP (some do, but other popular ones don't). > Otherwise the network driver has to eat an early cache miss > anyways to read the 802.x protocol ID for passing the packet > up the network stack. > (one possible fix for that would be to shift the protocol > parsing to later to avoid this, but that would be an > incompatible change in the driver interface) > > I guess with more intrusive changes Linux could do this better. > e.g. if you have the cache hot secondary table and a really > cheap way to find out from the NIC on a interrupt how many > packets it accepted you could aggressive prefetching and do > the protocol lookup later with a callback to the driver. But > this has a problems too: > > - Even on modern CPUs you cannot do too many prefetches in > parallel because you're overwhelming the load store units. At > some points new prefetches just get ignored. On older CPUs > this problem is even worse. > > Jamal and Robert did some experiments with routing on this > and they ran also into this. > > If the NIC initiated the transfers the bandwidth of the CPU > would be much more evenly used because the transfers are > spaced out in time as the packets arrive. Software prefetch > will be always bursty. > > However I agree that probably some smaller software only > improvements could be still done in this area on Linux. > > -Andi > > From ak@muc.de Sun Feb 20 15:07:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 15:07:20 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1KN7Fa5017815 for ; Sun, 20 Feb 2005 15:07:16 -0800 Received: (qmail 65832 invoked by uid 3709); 20 Feb 2005 23:07:13 -0000 Date: 21 Feb 2005 00:07:13 +0100 Date: Mon, 21 Feb 2005 00:07:13 +0100 From: Andi Kleen To: Leonid Grossman Cc: "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050220230713.GA62354@muc.de> References: <200502202244.j1KMinDD013572@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502202244.j1KMinDD013572@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1849 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: 2056 Lines: 47 On Sun, Feb 20, 2005 at 02:43:59PM -0800, Leonid Grossman wrote: > This is an interesting idea, we'll play around... What exactly? The software only shadow table? > > BTW - does anybody know if it's possible to indicate multiple receive > packets? > > In other OS drivers we have an option to indicate a "packet train" that got > received during an interrupt, but I'm not sure if/how it's doable in Linux. You can always call netif_rx() multiple times from the interrupt. The function doesn't do the full packet processing, but just stuffs the packet into a CPU queue that is processed at a lower priority interrupt (softirq). Doesn't work for NAPI unfortunately though; netif_receive_skb always does the protocol stack. > We are adding Linux driver support for message-signaled interrupts and > header separation (just recently figured out how to indicate chained skb for I had an experimental patch to enable MSI (without -X) for your cards, but didn't push it out because i wasn't too happy with it. Most interesting would be to use per CPU TX completion interrupts using MSI-X and avoid bouncing packets around between CPUs. > a packet that has IP and TCP headers separated by the ASIC); > If a packet train indication works then the driver could prefetch the > descriptor ring segment and also a rx buffer segment that holds headers > stored back-to-back, before indicating the train. Me and Jamal tried that some time ago, but it did not help too much. Probably because the protocol process overhead was not big enough. However that was with NAPI, might be perhaps worth trying without it. Problem is that need to fill in skb->protocol/pkt_type before you can pass the packet up; you can perhaps derive it from the RX descriptor (card has a bit that says "this is IP" and "its unicast for my MAC"). But the RX descriptor access is already a cache miss that stalls you. To make the prefetching work well for this would probably require a callback to the driver so that you can do this later after your prefetch succeeded. -Andi From romieu@fr.zoreil.com Sun Feb 20 15:35:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 15:35:45 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KNZXXJ018825 for ; Sun, 20 Feb 2005 15:35:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1KNYDtX014785; Mon, 21 Feb 2005 00:34:13 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1KNY5Lc014784; Mon, 21 Feb 2005 00:34:05 +0100 Date: Mon, 21 Feb 2005 00:34:05 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up Message-ID: <20050220233405.GA14268@electric-eye.fr.zoreil.com> References: <200502161823.43562.jdmason@us.ibm.com> <200502191147.14845.jdmason@us.ibm.com> <20050219223012.GA3601@electric-eye.fr.zoreil.com> <200502201204.23468.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502201204.23468.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1850 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: 3109 Lines: 102 Jon Mason : [...] > Actually, I removed it and it causes the partition point to move, similiar to > opts2. I realize this isn't really an acceptable answer, so I will try to > determine what is causing this weird behavior. It is an acceptable answer: the behavior changes. [...] > True, but this problem existed before I made the jumbo frames changes. The AFAIKS, if the rx_copybreak fails, be it because the packet is too big or because the allocation failed, the current skb is sent to the upper layers. > static inline int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, > struct RxDesc *desc, struct rtl8169_private *tp) > { > u32 status = le32_to_cpu(desc->opts1); > > if ((pkt_size > rx_copybreak) && > ((status & FirstFrag) && (status & LastFrag))) > return -1; > > if (status & FirstFrag) { > struct sk_buff *skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); > u32 len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; > > if (skb) { > skb_reserve(skb, NET_IP_ALIGN); > memcpy(skb->data, sk_buff[0]->tail, len); > skb_put(skb, len); > } else { > printk(KERN_INFO "no rx skb allocated\n"); > if (pkt_size <= rx_copybreak) > return -1; > } > > tp->new_skb = skb; > } > > Is this acceptable? I'll think more until I can figure I got the whole picture (only copy the first frament ?). I would have expected something like the mess below: static int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, struct RxDesc *desc, struct rtl8169_private *tp) { u32 status = le32_to_cpu(desc->opts1); struct sk_buff *skb; int ret = -1; if ((pkt_size > rx_copybreak) && (status & FirstFrag) && (status & LastFrag)) { goto out; } if (pkt_size < rx_copybreak) { skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (!skb) goto out; skb_reserve(skb, NET_IP_ALIGN); } else if (status & FirstFrag) skb = tp->new_skb = sk_buff[0]; if ((pkt_size < rx_copybreak) || !(status & FirstFrag)) { memcpy(skb->data, sk_buff[0]->tail, pkt_size); rtl8169_return_to_asic(desc, tp->rx_buf_sz); *sk_buff = skb; ret = 0; } skb_put(skb, pkt_size); out: return ret; } At this point I'd expect "How do you handle rtl8169_rx_copy() return ?" (or "yuck"). [...] > If I am still not making sense, I can be more verbose. Enlight me with the code, just to be sure. [...] > Sorry, I guess I got a little over eager. I will attempt to avoid this > behavior in the future. Forgiveness please. No problem, really. [...] > I realize this is being a little creative, but it is much cleaner code this > way. Otherwise the driver will need a global counter to use as a offset of > the skb->tail and call skb_put after it is all over. Ok, ok, I did not get it in the original patch. -- Ueimor From hubert.tonneau@fullpliant.org Sun Feb 20 15:38:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 15:39:04 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1KNcspF019406 for ; Sun, 20 Feb 2005 15:38:55 -0800 From: Hubert Tonneau To: "David S. Miller" , Alexey Kuznetsov , Nivedita Singhvi Cc: Stephen Hemminger , romieu@fr.zoreil.com, kuznet@ms2.inr.ac.ru, niv@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: 2.6.10 TCP troubles -- suggested patch Date: Sun, 20 Feb 2005 23:06:20 GMT Message-ID: <052MDIL12@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 4621 Lines: 42 I've noticed something very interesting: if trying to send to a gigabit connected Mac OSX instead of 100 Mbps connected, then there is no drastic slowdown when switching Linux 2.6.9 to 2.6.10 > Any chance you could > send me just the following from your boxes: > (Before and after the transfer) > > - /proc/net/snmp > - /proc/net/netstat Here are the requested extra informations: 2.6.10-ac10 before: Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 47336 0 0 0 0 0 47197 127721 0 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 2 0 0 0 0 0 0 0 2 0 0 0 0 417 0 417 0 0 0 0 0 0 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 40 209 0 2 7 46158 126953 156 0 243 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 332 417 0 336 TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures TcpExt: 0 0 0 0 0 0 0 0 0 0 94 0 0 0 0 0 452 0 0 0 0 9499 215 241030 0 7583 377 16696 3330 123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 123 0 0 7 0 0 0 0 0 0 0 0 0 90 0 0 2 0 0 0 2.6.10-ac10 after sending to the 100 Mbps connected Mac OSX: Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 70100 0 0 0 0 0 69901 214176 0 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 2 0 0 0 0 0 0 0 2 0 0 0 0 421 0 421 0 0 0 0 0 0 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 49 263 0 2 9 68728 213354 284 0 315 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 382 421 0 386 TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures TcpExt: 0 0 0 0 0 0 0 0 0 0 105 0 0 0 0 0 804 0 0 0 0 12808 215 310763 0 11460 472 26236 5086 247 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 247 0 0 11 0 0 0 0 0 0 0 0 0 123 0 0 2 0 0 0 From webmaster@rapidforum.com Sun Feb 20 16:06:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 16:06:22 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1L06Gvg020436 for ; Sun, 20 Feb 2005 16:06:17 -0800 Received: (qmail 22778 invoked by uid 1004); 21 Feb 2005 00:06:16 -0000 Received: from p3ee04292.dip0.t-ipconnect.de (HELO ?62.224.66.146?) (62.224.66.146) by www.rapidforum.com with SMTP; 21 Feb 2005 00:06:16 -0000 Message-ID: <421925DB.2060602@rapidforum.com> Date: Mon, 21 Feb 2005 01:05:47 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Annoying bug with many sockets. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 317 Lines: 8 Hi. This is really annoying. With 3500 sockets onwards, linux 2.6.10 completely lags. This is a bug and I am not willing to buy new servers just because linux has a BUG. tcp_mem _rmem and _wmem have been set to 1024000 for testing but this doesnt help as well. so whats WRONG there... please? Best regards, Chris From niv@us.ibm.com Sun Feb 20 16:26:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 16:26:36 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L0QUnx024588 for ; Sun, 20 Feb 2005 16:26:32 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1L0QO0D291392 for ; Sun, 20 Feb 2005 19:26:24 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1L0QNPk082444 for ; Sun, 20 Feb 2005 17:26:23 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L0QNmE009937 for ; Sun, 20 Feb 2005 17:26:23 -0700 Received: from [9.47.22.79] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.79]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L0QNC4009929; Sun, 20 Feb 2005 17:26:23 -0700 Message-ID: <42192AAF.8020609@us.ibm.com> Date: Sun, 20 Feb 2005 16:26:23 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: netdev@oss.sgi.com Subject: Re: Annoying bug with many sockets. References: <421925DB.2060602@rapidforum.com> In-Reply-To: <421925DB.2060602@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1853 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: 1423 Lines: 47 Christian Schmid wrote: > Hi. > > This is really annoying. With 3500 sockets onwards, linux 2.6.10 > completely lags. This is a bug and I am not willing to buy new servers > just because linux has a BUG. tcp_mem _rmem and _wmem have been set to > 1024000 for testing but this doesnt help as well. so whats WRONG > there... please? > > Best regards, > Chris You have not actually said what the problem is - do new connections not get made? Or existing connections slow down? You are trying to run many simultaneous connections, so bumping up the individual socket buffer allocation will not necessarily help - you need to bump up the global TCP limit (tcp_mem[]) - it's a 3-tuple - if you have the memory in your system, bump it way up. netstat -tan will tell you if there is unread data in the queues.. Are you running into memory pressure? Or aborts? netstat -s might give you some info on what is happening. Bump up the port space (/proc/sys/net/ipv4/ip_local_port_range) available - typical default is 32K - 61000 (can lower min to 4K) Are they all receiving data or sending? Are they talking to different hosts? You can increase tcp_max_syn_backlog, core/netdev_max_backlog, for a start. But it would help if you looked at the stats and ifconfig to see who's dropping packets, how many retransmissions there are, memory failures, or the bottleneck is some other issue altogether... thanks, Nivedita From romieu@fr.zoreil.com Sun Feb 20 16:31:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 16:31:40 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L0VXS8025146 for ; Sun, 20 Feb 2005 16:31:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1L0SbsY015441; Mon, 21 Feb 2005 01:28:37 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1L0SRGd015440; Mon, 21 Feb 2005 01:28:27 +0100 Date: Mon, 21 Feb 2005 01:28:27 +0100 From: Francois Romieu To: Richard Dawe Cc: Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up Message-ID: <20050221002827.GB14268@electric-eye.fr.zoreil.com> References: <200502161823.43562.jdmason@us.ibm.com> <20050217232804.GA4992@electric-eye.fr.zoreil.com> <4218CE73.6010206@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4218CE73.6010206@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1854 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: 1397 Lines: 49 Richard Dawe : [...] > I started working on adding netif_msg checks to the printks. How far > have you got? I don't want to duplicate your work. None so far. Go wild. > Incidentally, is there a to-do list somewhere for the r8169 driver? (without priority) - validate suspend/resume/wol - fix the dac issues on x64 Weird. Pita. Status needs to be updated. - push jumbo frames beyond 7k see with Jon Mason - merge with the 8139cp driver always interrupted but I have not given up - fix the gcc 2.95.x miscompilations people upgrade their compiler and return to real life before it can be diagnosed. It should not be hard but I have not had the time to install a broken debian to reproduce it so far :o( - benchmark/improve the performances Executive summary by Lennert Buytenhek: it sucks. If someone could identify where the bottleneck is with hard numbers... - harvest the hopeless r8169 users on the web time consuming like hell but it really helps to figure if things are stable or not. - backport to 2.4 RSN. Pending queue is available here and will be pushed once 2.6.x is up-to-date. - ask Ben Greear if he still experiences keyboard issues with its laptop when he uses the r8169 driver Pending for 5 months... Ahem. > Maybe I can help out with some of the things. Figure what's wrong with M. Gardiol setup ? -- Ueimor From webmaster@rapidforum.com Sun Feb 20 16:36:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 16:36:07 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1L0a28H025707 for ; Sun, 20 Feb 2005 16:36:03 -0800 Received: (qmail 24444 invoked by uid 1004); 21 Feb 2005 00:36:02 -0000 Received: from p3ee04292.dip0.t-ipconnect.de (HELO ?62.224.66.146?) (62.224.66.146) by www.rapidforum.com with SMTP; 21 Feb 2005 00:36:02 -0000 Message-ID: <42192CD5.5090401@rapidforum.com> Date: Mon, 21 Feb 2005 01:35:33 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Nivedita Singhvi CC: netdev@oss.sgi.com Subject: Re: Annoying bug with many sockets. References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> In-Reply-To: <42192AAF.8020609@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 2428 Lines: 62 Nivedita Singhvi wrote: > Christian Schmid wrote: > >> Hi. >> >> This is really annoying. With 3500 sockets onwards, linux 2.6.10 >> completely lags. This is a bug and I am not willing to buy new servers >> just because linux has a BUG. tcp_mem _rmem and _wmem have been set to >> 1024000 for testing but this doesnt help as well. so whats WRONG >> there... please? >> >> Best regards, >> Chris > > > You have not actually said what the problem is - do > new connections not get made? Or existing connections > slow down? New connections get made without any problems. Just existing connections slow down painfully. > You are trying to run many simultaneous connections, so > bumping up the individual socket buffer allocation will > not necessarily help - you need to bump up the global > TCP limit (tcp_mem[]) - it's a 3-tuple - if you have > the memory in your system, bump it way up. netstat -tan > will tell you if there is unread data in the queues.. I already set it to 1024000 1025000 1026000 (just to be sure). Its a 8 GB system with 2/2 split, so 2 GB of low memory. > Are you running into memory pressure? Or aborts? > netstat -s might give you some info on what is happening. > > Bump up the port space (/proc/sys/net/ipv4/ip_local_port_range) > available - typical default is 32K - 61000 (can lower min to 4K) > > Are they all receiving data or sending? Are they talking to > different hosts? > > You can increase tcp_max_syn_backlog, core/netdev_max_backlog, > for a start. netdev_max_backlog has been raised from 300 to 3000 without any result. syn_backlog is normal but its no problem to create new connections. Just existing connections slow down suddenly. Like this: 3000 sockets = no slowdown at all (500 MBit in use) 3300 sockets = 10% slowdown 3600 sockets = 30% slowdown 4000 sockets = 60% slowdown (i aborted here, as it only uses 200 MBit for sending... catastrophy!) They are all receiving data. Its a download-service. receive-buffer is set to 24 KB and send-buffer set to 224 KB. I don't see a problem with port-space. I only have 3500 sockets when the problem appears but it appears suddenly. > But it would help if you looked at the stats and ifconfig > to see who's dropping packets, how many retransmissions there > are, memory failures, or the bottleneck is some other issue altogether... No way. Doing 30000 packets per second and your stats are 32 bit integers ;) Chris From alex@neterion.com Sun Feb 20 17:59:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 17:59:53 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L1xjra028263 for ; Sun, 20 Feb 2005 17:59:47 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1L1wrdG019652; Sun, 20 Feb 2005 20:58:53 -0500 (EST) Received: from aaizmanlt ([10.16.16.164]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1L1wcDD004318; Sun, 20 Feb 2005 20:58:38 -0500 (EST) Message-Id: <200502210158.j1L1wcDD004318@guinness.s2io.com> Reply-To: From: "Alex Aizman" To: "'Andi Kleen'" , "'Leonid Grossman'" Cc: "'rick jones'" , Subject: RE: Intel and TOE in the news Date: Sun, 20 Feb 2005 17:57:56 -0800 Organization: s2io MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050220230713.GA62354@muc.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUXoOq3jpiGyWGCQqKFfhRTwUUM9AAElz0g X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 3243 Lines: 87 > You can always call netif_rx() multiple times from the > interrupt. That's what we do, simply because interrupts are coalesced. > The function doesn't do the full packet > processing, but just stuffs the packet into a CPU queue that > is processed at a lower priority interrupt (softirq). There's the netif_rx's own per-packet overhead (including the call itself) that arguably could be optimized.. > Most interesting would be to use per CPU TX completion > interrupts using MSI-X and avoid bouncing packets around between CPUs. Our experimental Linux driver already supports MSI and MSI-X (the latter not tested). Once/if multi-MSI support in Linux becomes available it'd be practically possible to scale TCP connections with a number of CPUs. Alternative: wait until Xframe II adapter w/MSI-X.. Alex > -----Original Message----- > From: Andi Kleen [mailto:ak@muc.de] > Sent: Sunday, February 20, 2005 3:07 PM > To: Leonid Grossman > Cc: 'rick jones'; netdev@oss.sgi.com; 'Alex Aizman' > Subject: Re: Intel and TOE in the news > > On Sun, Feb 20, 2005 at 02:43:59PM -0800, Leonid Grossman wrote: > > This is an interesting idea, we'll play around... > > What exactly? The software only shadow table? > > > > > BTW - does anybody know if it's possible to indicate > multiple receive > > packets? > > > > In other OS drivers we have an option to indicate a "packet train" > > that got received during an interrupt, but I'm not sure > if/how it's doable in Linux. > > You can always call netif_rx() multiple times from the > interrupt. The function doesn't do the full packet > processing, but just stuffs the packet into a CPU queue that > is processed at a lower priority interrupt (softirq). > Doesn't work for NAPI unfortunately though; netif_receive_skb > always does the protocol stack. > > > We are adding Linux driver support for message-signaled > interrupts and > > header separation (just recently figured out how to > indicate chained > > skb for > > I had an experimental patch to enable MSI (without -X) for > your cards, but didn't push it out because i wasn't too happy with it. > > Most interesting would be to use per CPU TX completion > interrupts using MSI-X and avoid bouncing packets around between CPUs. > > > a packet that has IP and TCP headers separated by the ASIC); If a > > packet train indication works then the driver could prefetch the > > descriptor ring segment and also a rx buffer segment that holds > > headers stored back-to-back, before indicating the train. > > Me and Jamal tried that some time ago, but it did not help too much. > Probably because the protocol process overhead was not big enough. > However that was with NAPI, might be perhaps worth trying without it. > > Problem is that need to fill in skb->protocol/pkt_type before > you can pass the packet up; you can perhaps derive it from > the RX descriptor (card has a bit that says "this is IP" and > "its unicast for my MAC"). > But the RX descriptor access is already a cache miss that > stalls you. > > To make the prefetching work well for this would probably > require a callback to the driver so that you can do this > later after your prefetch succeeded. > > -Andi > > From jgarzik@pobox.com Sun Feb 20 18:07:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 18:07:27 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L27MLS028898 for ; Sun, 20 Feb 2005 18:07:23 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D32yl-0006Cs-P8; Mon, 21 Feb 2005 02:07:20 +0000 Message-ID: <42194236.40100@pobox.com> Date: Sun, 20 Feb 2005 21:06:46 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Malli Chilakala CC: netdev Subject: Re: [PATCH net-drivers-2.6 1/5] ixgb: use netif_poll_{enable|disable} References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1857 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: 256 Lines: 12 Malli Chilakala wrote: > 1 use netif_poll_{enable|disable} to synchronize between poll and i/f down/up applied patches 1-5. Please do not include patch numbers (e.g. "1 [...]") in the description; I have to hand-edit this out of each comment. Jeff From jgarzik@pobox.com Sun Feb 20 18:14:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 18:16:08 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L2Eees029537 for ; Sun, 20 Feb 2005 18:14:40 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D335n-0006KC-LE; Mon, 21 Feb 2005 02:14:36 +0000 Message-ID: <421943F8.3080807@pobox.com> Date: Sun, 20 Feb 2005 21:14:16 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Malli Chilakala CC: netdev Subject: Re: [PATCH net-drivers-2.6 1/10] e1000: Robert Olsson's fix and refinement to the poll routine References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1858 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: 299 Lines: 13 Malli Chilakala wrote: > 1 Robert Olsson's fix and refinement to the poll routine applied patches 1-10 to 2.6.x. Same comment as before: do not include patch number in email description, as this must be hand-edited out of each description after the automated patch merge step occurs. Jeff From jgarzik@pobox.com Sun Feb 20 18:31:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 18:31:17 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L2V9Zo030334 for ; Sun, 20 Feb 2005 18:31:09 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D33Lm-0006a0-E6; Mon, 21 Feb 2005 02:31:07 +0000 Message-ID: <421947DA.7030603@pobox.com> Date: Sun, 20 Feb 2005 21:30:50 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev Subject: [BK PATCHES] 2.6.x net driver fixes Content-Type: multipart/mixed; boundary="------------030308020401070601070604" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1859 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: 5095 Lines: 141 This is a multi-part message in MIME format. --------------030308020401070601070604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit see attached changelog and patch. --------------030308020401070601070604 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/natsemi.c | 4 +++- drivers/net/s2io.c | 5 +++++ drivers/net/wireless/strip.c | 4 ++-- 3 files changed, 10 insertions(+), 3 deletions(-) through these ChangeSets: (05/02/20 1.2078) [PATCH] natsemi long cable fix This is a minor modification to the previous patch submission that does not assume the default contents of the DSPCFG register are zero. When used with Revision D of the DP83815, the "Recommended Registers Configuration" from page 78 of the DP83815 data sheet is not entirely compatible with the driver's "short cable patch". When the DSPCFG register is written with the value suggested in the document, then do_cable_magic() can't read the DSP coefficient and determines that all cables attached to the DP83815D are 'short', regardless of actual length. Short cables (< 30m) cause do_cable_magic to enable additional attenuation to reduce CRC and idle errors. If the extra attenuation is unintentionally enabled for long cables (> 50m?), they will not operate properly. The National Semiconductor driver, 'dp83815.c' from http://www.national.com/appinfo/networks/files/linux_2_4.tar.gz was used as a basis for this modification. Signed-off-by: Jeff Garzik (05/02/20 1.2077) [PATCH] S2io: Multicast fix Attached is the patch to address the incorrect programming of individual multicast address into the NIC. Signed-off-by: Ravinandan Arakali Signed-off-by: Jeff Garzik (05/02/20 1.2076) [PATCH] strip.c build fix Someone added a new dev_set_mac_address() to netdevice.h Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik --------------030308020401070601070604 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/natsemi.c b/drivers/net/natsemi.c --- a/drivers/net/natsemi.c 2005-02-20 21:30:01 -05:00 +++ b/drivers/net/natsemi.c 2005-02-20 21:30:01 -05:00 @@ -441,6 +441,7 @@ #define DSPCFG_VAL 0x5040 #define SDCFG_VAL 0x008c /* set voltage thresholds for Signal Detect */ #define DSPCFG_LOCK 0x20 /* coefficient lock bit in DSPCFG */ +#define DSPCFG_COEF 0x1000 /* see coefficient (in TSTDAT) bit in DSPCFG */ #define TSTDAT_FIXED 0xe8 /* magic number for bad coefficients */ /* misc PCI space registers */ @@ -1243,7 +1244,8 @@ writew(1, ioaddr + PGSEL); writew(PMDCSR_VAL, ioaddr + PMDCSR); writew(TSTDAT_VAL, ioaddr + TSTDAT); - np->dspcfg = DSPCFG_VAL; + np->dspcfg = (np->srr <= SRR_DP83815_C)? + DSPCFG_VAL : (DSPCFG_COEF | readw(ioaddr + DSPCFG)); writew(np->dspcfg, ioaddr + DSPCFG); writew(SDCFG_VAL, ioaddr + SDCFG); writew(0, ioaddr + PGSEL); diff -Nru a/drivers/net/s2io.c b/drivers/net/s2io.c --- a/drivers/net/s2io.c 2005-02-20 21:30:01 -05:00 +++ b/drivers/net/s2io.c 2005-02-20 21:30:01 -05:00 @@ -3025,6 +3025,8 @@ for (i = 0; i < prev_cnt; i++) { writeq(RMAC_ADDR_DATA0_MEM_ADDR(dis_addr), &bar0->rmac_addr_data0_mem); + writeq(RMAC_ADDR_DATA1_MEM_MASK(0ULL), + &bar0->rmac_addr_data1_mem); val64 = RMAC_ADDR_CMD_MEM_WE | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD | RMAC_ADDR_CMD_MEM_OFFSET @@ -3049,8 +3051,11 @@ mac_addr |= mclist->dmi_addr[j]; mac_addr <<= 8; } + mac_addr >>= 8; writeq(RMAC_ADDR_DATA0_MEM_ADDR(mac_addr), &bar0->rmac_addr_data0_mem); + writeq(RMAC_ADDR_DATA1_MEM_MASK(0ULL), + &bar0->rmac_addr_data1_mem); val64 = RMAC_ADDR_CMD_MEM_WE | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD | diff -Nru a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c --- a/drivers/net/wireless/strip.c 2005-02-20 21:30:01 -05:00 +++ b/drivers/net/wireless/strip.c 2005-02-20 21:30:01 -05:00 @@ -2398,7 +2398,7 @@ return 0; } -static int dev_set_mac_address(struct net_device *dev, void *addr) +static int strip_set_mac_address(struct net_device *dev, void *addr) { struct strip *strip_info = (struct strip *) (dev->priv); struct sockaddr *sa = addr; @@ -2552,7 +2552,7 @@ dev->hard_start_xmit = strip_xmit; dev->hard_header = strip_header; dev->rebuild_header = strip_rebuild_header; - dev->set_mac_address = dev_set_mac_address; + dev->set_mac_address = strip_set_mac_address; dev->get_stats = strip_get_stats; dev->change_mtu = strip_change_mtu; } --------------030308020401070601070604-- From jgarzik@pobox.com Sun Feb 20 18:38:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 18:38:03 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L2bxqO030921 for ; Sun, 20 Feb 2005 18:37:59 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D33SO-0006fo-Rx; Mon, 21 Feb 2005 02:37:57 +0000 Message-ID: <42194972.8060303@pobox.com> Date: Sun, 20 Feb 2005 21:37:38 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex@neterion.com CC: "'Andi Kleen'" , "'Leonid Grossman'" , "'rick jones'" , netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <200502210158.j1L1wcDD004318@guinness.s2io.com> In-Reply-To: <200502210158.j1L1wcDD004318@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1860 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: 393 Lines: 13 Alex Aizman wrote: > Our experimental Linux driver already supports MSI and MSI-X (the latter not > tested). Once/if multi-MSI support in Linux becomes available it'd be > practically possible to scale TCP connections with a number of CPUs. > Alternative: wait until Xframe II adapter w/MSI-X.. The infiniband Linux driver is already using multi-MSI. You are behind the times :) Jeff From leonid.grossman@neterion.com Sun Feb 20 19:33:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 19:33:47 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L3XdDA032528 for ; Sun, 20 Feb 2005 19:33:42 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1L3WndG020044; Sun, 20 Feb 2005 22:32:49 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1L3WkDD014744; Sun, 20 Feb 2005 22:32:46 -0500 (EST) Message-Id: <200502210332.j1L3WkDD014744@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'Leonid Grossman'" Cc: "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Sun, 20 Feb 2005 19:31:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050220230713.GA62354@muc.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcUXoPFF9/ImwssrS2283LzCFQyI8AAIKEnw X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 3423 Lines: 92 > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Andi Kleen > Sent: Sunday, February 20, 2005 3:07 PM > To: Leonid Grossman > Cc: 'rick jones'; netdev@oss.sgi.com; 'Alex Aizman' > Subject: Re: Intel and TOE in the news > > On Sun, Feb 20, 2005 at 02:43:59PM -0800, Leonid Grossman wrote: > > This is an interesting idea, we'll play around... > > What exactly? The software only shadow table? > > > > > BTW - does anybody know if it's possible to indicate > multiple receive > > packets? > > > > In other OS drivers we have an option to indicate a "packet train" > > that got received during an interrupt, but I'm not sure > if/how it's doable in Linux. > > You can always call netif_rx() multiple times from the > interrupt. The function doesn't do the full packet > processing, but just stuffs the packet into a CPU queue that > is processed at a lower priority interrupt (softirq). > Doesn't work for NAPI unfortunately though; netif_receive_skb > always does the protocol stack. Yes, this is what we currently do; I was rather thinking about the option to indicate multiple packets in a single call (say as a linked list). Alternative (rather, complimentary) approach is to collapse consecutive packets from the same session in a single large frame; we are going to try this as well since the ASIC has hw assists for that. > > > We are adding Linux driver support for message-signaled > interrupts and > > header separation (just recently figured out how to > indicate chained > > skb for > > I had an experimental patch to enable MSI (without -X) for > your cards, but didn't push it out because i wasn't too happy with it. > We have single MSI working now. Jeff - thanks for the pointer to multiple MSI usage in IB, we will have a look (to catch up with the times :-). I guess MSIs are not that interesting in themselves - it's more what the driver can do with them to optimize tx/rx processing... > Most interesting would be to use per CPU TX completion > interrupts using MSI-X and avoid bouncing packets around between CPUs. Do you mean indicating rx packets to the same cpu that tx (for the same session) came from, or something else? > > > a packet that has IP and TCP headers separated by the ASIC); If a > > packet train indication works then the driver could prefetch the > > descriptor ring segment and also a rx buffer segment that holds > > headers stored back-to-back, before indicating the train. > > Me and Jamal tried that some time ago, but it did not help too much. > Probably because the protocol process overhead was not big enough. > However that was with NAPI, might be perhaps worth trying without it. > > Problem is that need to fill in skb->protocol/pkt_type before > you can pass the packet up; you can perhaps derive it from > the RX descriptor (card has a bit that says "this is IP" and > "its unicast for my MAC"). > But the RX descriptor access is already a cache miss that > stalls you. > > To make the prefetching work well for this would probably > require a callback to the driver so that you can do this > later after your prefetch succeeded. Instead of requiring a callback, a driver can prefetch descriptors and headers for the packets that are going to be processed on the next interrupt - by then, prefetch will likely succeed. Leonid > > -Andi > > > From jdmason@us.ibm.com Sun Feb 20 19:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 19:41:04 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L3ewjG000691 for ; Sun, 20 Feb 2005 19:40:58 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1L3eq5j283960 for ; Sun, 20 Feb 2005 22:40:52 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1L3eqPw072998 for ; Sun, 20 Feb 2005 20:40:52 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L3eqhu013239 for ; Sun, 20 Feb 2005 20:40:52 -0700 Received: from sig-9-65-12-11.mts.ibm.com (sig-9-65-12-11.mts.ibm.com [9.65.12.11]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L3epP7013234; Sun, 20 Feb 2005 20:40:51 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Sun, 20 Feb 2005 21:40:48 -0600 User-Agent: KMail/1.7.2 Cc: Richard Dawe , netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <4218CE73.6010206@phekda.gotadsl.co.uk> <20050221002827.GB14268@electric-eye.fr.zoreil.com> In-Reply-To: <20050221002827.GB14268@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: <200502202140.48403.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1568 Lines: 50 On Sunday 20 February 2005 06:28 pm, Francois Romieu wrote: > Richard Dawe : > [...] > > > I started working on adding netif_msg checks to the printks. How far > > have you got? I don't want to duplicate your work. > > None so far. Go wild. > > > Incidentally, is there a to-do list somewhere for the r8169 driver? > > (without priority) > > - validate suspend/resume/wol > > - fix the dac issues on x64 > Weird. Pita. Status needs to be updated. > > - push jumbo frames beyond 7k > see with Jon Mason > > - merge with the 8139cp driver > always interrupted but I have not given up > > - fix the gcc 2.95.x miscompilations > people upgrade their compiler and return to real life before it can be > diagnosed. It should not be hard but I have not had the time to install > a broken debian to reproduce it so far :o( > > - benchmark/improve the performances > Executive summary by Lennert Buytenhek: it sucks. If someone could > identify where the bottleneck is with hard numbers... > > - harvest the hopeless r8169 users on the web > time consuming like hell but it really helps to figure if things are > stable or not. > > - backport to 2.4 > RSN. Pending queue is available here and will be pushed once 2.6.x is > up-to-date. > > - ask Ben Greear if he still experiences keyboard issues with its laptop > when he uses the r8169 driver > Pending for 5 months... Ahem. > > > Maybe I can help out with some of the things. > > Figure what's wrong with M. Gardiol setup ? Fix ethtool statistics (amd64 only problem?) From jdmason@us.ibm.com Sun Feb 20 20:54:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 20:54:49 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L4sXMe006800 for ; Sun, 20 Feb 2005 20:54:40 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1L4sRua386086 for ; Sun, 20 Feb 2005 23:54:27 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1L4sRhq105332 for ; Sun, 20 Feb 2005 21:54:27 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L4sR3W007920 for ; Sun, 20 Feb 2005 21:54:27 -0700 Received: from sig-9-65-12-11.mts.ibm.com (sig-9-65-12-11.mts.ibm.com [9.65.12.11]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1L4sRrr007916; Sun, 20 Feb 2005 21:54:27 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/3] r8169: code clean-up Date: Sun, 20 Feb 2005 22:54:23 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200502161823.43562.jdmason@us.ibm.com> <200502201204.23468.jdmason@us.ibm.com> <20050220233405.GA14268@electric-eye.fr.zoreil.com> In-Reply-To: <20050220233405.GA14268@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: <200502202254.23511.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6751 Lines: 181 On Sunday 20 February 2005 05:34 pm, Francois Romieu wrote: [...] > > True, but this problem existed before I made the jumbo frames changes. The > > AFAIKS, if the rx_copybreak fails, be it because the packet is too big or > because the allocation failed, the current skb is sent to the upper layers. You are correct, I misunderstood the error path of the previous rx_copy routine. > > static inline int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, > > struct RxDesc *desc, struct rtl8169_private *tp) > > { > > u32 status = le32_to_cpu(desc->opts1); > > > > if ((pkt_size > rx_copybreak) && > > ((status & FirstFrag) && (status & LastFrag))) > > return -1; > > > > if (status & FirstFrag) { > > struct sk_buff *skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); > > u32 len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; > > > > if (skb) { > > skb_reserve(skb, NET_IP_ALIGN); > > memcpy(skb->data, sk_buff[0]->tail, len); > > skb_put(skb, len); > > } else { > > printk(KERN_INFO "no rx skb allocated\n"); > > if (pkt_size <= rx_copybreak) > > return -1; > > } > > > > tp->new_skb = skb; > > } > > > > Is this acceptable? > > I'll think more until I can figure I got the whole picture (only copy the > first frament ?). I would have expected something like the mess below: > > static int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, > struct RxDesc *desc, struct rtl8169_private *tp) > { > u32 status = le32_to_cpu(desc->opts1); > struct sk_buff *skb; > int ret = -1; > > if ((pkt_size > rx_copybreak) && (status & FirstFrag) && > (status & LastFrag)) { > goto out; > } > > if (pkt_size < rx_copybreak) { > skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); > if (!skb) > goto out; > skb_reserve(skb, NET_IP_ALIGN); > } else if (status & FirstFrag) > skb = tp->new_skb = sk_buff[0]; > > if ((pkt_size < rx_copybreak) || !(status & FirstFrag)) { > memcpy(skb->data, sk_buff[0]->tail, pkt_size); > rtl8169_return_to_asic(desc, tp->rx_buf_sz); > *sk_buff = skb; > ret = 0; > } > > skb_put(skb, pkt_size); > > out: > return ret; > } > > At this point I'd expect "How do you handle rtl8169_rx_copy() return ?" > (or "yuck"). My main problem with the above patch is that is assumes that there will be a maximum of 2 descriptors per jumbo frame (which isn't the case). This might have been caused by my incomplete patch given above. This is what I currently have: static inline int rtl8169_rx_copy(struct sk_buff **sk_buff, int pkt_size, struct RxDesc *desc, struct rtl8169_private *tp) { u32 status = le32_to_cpu(desc->opts1); if ((pkt_size > rx_copybreak) && ((status & FirstFrag) && (status & LastFrag))) return -1; if (status & FirstFrag) { u32 len = (pkt_size > rx_copybreak) ? tp->desc_part : pkt_size; struct sk_buff *skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (skb) { skb_reserve(skb, NET_IP_ALIGN); memcpy(skb->data, sk_buff[0]->tail, len); skb_put(skb, len); } else { printk(KERN_INFO "no rx skb allocated\n"); if (pkt_size <= rx_copybreak) return -1; } tp->new_skb = skb; } if (!(status & FirstFrag) && !(status & LastFrag) && tp->new_skb) { memcpy(tp->new_skb->tail, sk_buff[0]->tail, tp->desc_part); skb_put(tp->new_skb, tp->desc_part); } if (status & LastFrag) { if (pkt_size > rx_copybreak && tp->new_skb) { memcpy(tp->new_skb->tail, sk_buff[0]->tail, pkt_size - tp->new_skb->len); skb_put(tp->new_skb, pkt_size - tp->new_skb->len); } *sk_buff = tp->new_skb; } rtl8169_return_to_asic(desc, tp->rx_buf_sz); return 0; } > [...] > > If I am still not making sense, I can be more verbose. > > Enlight me with the code, just to be sure. Working (but still hackish) patch: --- drivers/net/r8169.c.0220 2005-02-20 22:45:07.000000000 -0600 +++ drivers/net/r8169.c 2005-02-20 22:43:27.000000000 -0600 @@ -1663,7 +1663,8 @@ static void rtl8169_free_rx_skb(struct r { struct pci_dev *pdev = tp->pci_dev; - pci_unmap_single(pdev, le64_to_cpu(desc->addr), tp->rx_buf_sz, + //pci_unmap_single(pdev, le64_to_cpu(desc->addr), tp->rx_buf_sz, + pci_unmap_single(pdev, le64_to_cpu(desc->addr), tp->desc_part+ETH_HLEN, PCI_DMA_FROMDEVICE); dev_kfree_skb(*sk_buff); *sk_buff = NULL; @@ -1694,14 +1695,14 @@ static int rtl8169_alloc_rx_skb(struct r dma_addr_t mapping; int ret = 0; - skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); + skb = dev_alloc_skb(tp->desc_part + ETH_HLEN + NET_IP_ALIGN); if (!skb) goto err_out; skb_reserve(skb, NET_IP_ALIGN); *sk_buff = skb; - mapping = pci_map_single(tp->pci_dev, skb->tail, rx_buf_sz, + mapping = pci_map_single(tp->pci_dev, skb->tail, tp->desc_part+ETH_HLEN, PCI_DMA_FROMDEVICE); rtl8169_give_to_asic(desc, mapping, rx_buf_sz); @@ -2225,7 +2226,7 @@ rtl8169_rx_interrupt(struct net_device * rtl8169_rx_csum(skb, desc); pci_dma_sync_single_for_cpu(tp->pci_dev, - le64_to_cpu(desc->addr), tp->rx_buf_sz, + le64_to_cpu(desc->addr), tp->desc_part+ETH_HLEN, PCI_DMA_FROMDEVICE); if (rtl8169_rx_copy(&skb, pkt_size, desc, tp)) { @@ -2235,7 +2236,7 @@ rtl8169_rx_interrupt(struct net_device * } pci_action(tp->pci_dev, le64_to_cpu(desc->addr), - tp->rx_buf_sz, PCI_DMA_FROMDEVICE); + tp->desc_part+ETH_HLEN, PCI_DMA_FROMDEVICE); if (skb && (status & LastFrag)) { skb->dev = dev; A more complete patch to follow shortly (as I want to try and fix my tabs problem). From akpm@osdl.org Sun Feb 20 22:03:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 22:03:35 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L63SuC009289 for ; Sun, 20 Feb 2005 22:03:28 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1L63Jqi007417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Feb 2005 22:03:20 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1L63HtD026133; Sun, 20 Feb 2005 22:03:19 -0800 Date: Sun, 20 Feb 2005 22:03:04 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: AndyLiebman@aol.com Subject: Fw: Frequent Oops on Shutdown 2.6.10 Message-Id: <20050220220304.1f2bd42f.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=ISO-8859-1 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1L63SuC009289 X-archive-position: 1864 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: 2980 Lines: 77 Begin forwarded message: Date: Sun, 20 Feb 2005 09:56:04 EST From: AndyLiebman@aol.com To: linux-kernel@vger.kernel.org Subject: Frequent Oops on Shutdown 2.6.10 Hi, I compiled the 2.6.10 kernel with HyperThreading optimization (I'm running a 3.06 Ghz single Xeon processor with HT enabled). More or less, I'm running Mandrake 10 Official, but with my own kernel. Can anybody help explain why I'm getting this Oops on shutdown? It doesn't happen all the time -- about 50 percent of the time. Never happens with the 2.6.6 kernel. I configured the 2.6.10 kernel with mostly the same settings -- saying "no" to everything new, except optimizing for P4/Xeon processor, enabling HT optimization, and NOT enabling lots of "ham radio" and "ISDN" stuff that seemed to be enabled in the Mandrake kernel. Some relevant things about the machine: Single Xeon 3.06 processor 2 GB ECC RAM 2x 3ware 9500S-8 SATA RAID Cards 16 SATA drives 2 built-in GigE ports on motherboard 2 Intel 1000 MT Server Adapters on each of the two 133 Mhz PCI-X slots Here's the output from the Oops *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: raid) appletalk xfs sd_mod sg sr_mod 3w_9xxx scsi_mod nfsd exportfs ipv6 af_packet raw ide_floppy ide_tape ide_cd cdrom e1000 uhci_hcd usbcore rtc ext3 jbd CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.10es-feb06) EIP is at remove_proc_entry+0x2a/0x166 eax: 00000000 ebx: f66a4e00 ecx: ffffffff edx: f6da1300 esi: f7cfb000 edi: 00000005 ebp: c2183eb4 esp: c2183e94 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c2182000 task=c214e520) Stack: c043402c c043402c 00000000 c2024980 00000005 f66a4e00 f7cfb000 00000000 c2183ec8 f8c4f051 00000005 f6da1300 f66a4e00 c2183ee8 f8c2cc7b f66a4e00 c2024980 00000002 00000000 f6da7e80 f6da6080 c2183f04 c0289967 f66a4e00 Call Trace: [] show_stack+0xaf/0xb7 [] show_registers+0x15f/0x1d2 [] die+0xfa/0x180 [] do_page_fault+0x464/0x646 [] error_code+0x2b/0x30 [] snmp6_unregister_dev+0x41/0x57 [ipv6] [] in6_dev_finish_destroy+0x35/0xb6 [ipv6] [] dst_destroy+0xa2/0xcd [] dst_run_gc+0x72/0xfb [] run_timer_softirq+0xc4/0x185 [] __do_softirq+0x65/0xd3 [] do_softirq+0x31/0x33 [] apic_timer_interrupt+0x1c/0x24 [] cpu_idle+0x31/0x3f [<00000000>] 0x0 [] 0xc2183fbc Code: e2 55 89 ef 83 ec 20 8b 55 0c 8b 4d 08 89 5d f4 85 d2 89 75 f8 89 7d fc 89 4d f0 0f 84 b0 00 00 00 8b 7d f0 31 c0 b9 ff ff ff ff ae f7 d1 49 8b 42 34 8d 5a 34 85 c0 89 ce 0f 84 84 00 00 00 <0>Kernel panic ___ not syncing: Fatal exception in interrupt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@linux-ipv6.org Sun Feb 20 23:21:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 23:21:31 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L7LNCj011734 for ; Sun, 20 Feb 2005 23:21:25 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6F29033CC2; Mon, 21 Feb 2005 16:22:41 +0900 (JST) Date: Mon, 21 Feb 2005 16:22:41 +0900 (JST) Message-Id: <20050221.162241.24618885.yoshfuji@linux-ipv6.org> To: AndyLiebman@aol.com, terryg@axian.com Cc: netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: Frequent Oops on Shutdown 2.6.10 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050220220304.1f2bd42f.akpm@osdl.org> References: <20050220220304.1f2bd42f.akpm@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1865 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: 3235 Lines: 128 Hello. In article <20050220220304.1f2bd42f.akpm@osdl.org> (at Sun, 20 Feb 2005 22:03:04 -0800), Andrew Morton says: > EIP is at remove_proc_entry+0x2a/0x166 : > [] snmp6_unregister_dev+0x41/0x57 [ipv6] > [] in6_dev_finish_destroy+0x35/0xb6 [ipv6] > [] dst_destroy+0xa2/0xcd Would you test this patch, please? Thanks. ------ [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/proc.c 1.25 vs edited ===== --- 1.25/net/ipv6/proc.c 2004-07-08 07:17:29 +09:00 +++ edited/net/ipv6/proc.c 2005-02-21 16:05:49 +09:00 @@ -31,7 +31,9 @@ #include #ifdef CONFIG_PROC_FS -static struct proc_dir_entry *proc_net_devsnmp6; +struct proc_dir_entry *proc_net_devsnmp6; +static DECLARE_MUTEX(proc_net_devsnmp6_sem); +static unsigned int proc_net_devsnmp6_users; static int fold_prot_inuse(struct proto *proto) { @@ -211,13 +213,26 @@ __alignof__(struct icmpv6_mib)) < 0) goto err_icmp; - if (!proc_net_devsnmp6) { - err = -ENOENT; - goto err_proc; + down(&proc_net_devsnmp6_sem); + if (!proc_net_devsnmp6_users) { + proc_net_devsnmp6 = proc_mkdir("dev_snmp6", proc_net); + if (!proc_net_devsnmp6) { + err = -ENOMEM; + printk(KERN_ERR "%s(): failed to create dev_snmp6.\n", + __FUNCTION__); + goto err_proc; + } } p = create_proc_entry(idev->dev->name, S_IRUGO, proc_net_devsnmp6); - if (!p) + if (!p) { + if (!proc_net_devsnmp6_users) + proc_net_remove("dev_snmp6"); goto err_proc; + } + + proc_net_devsnmp6_users++; + up(&proc_net_devsnmp6_sem); + p->data = idev; p->proc_fops = &snmp6_seq_fops; @@ -225,6 +240,7 @@ return 0; err_proc: + up(&proc_net_devsnmp6_sem); snmp6_mib_free((void **)idev->stats.icmpv6); err_icmp: return err; @@ -232,12 +248,23 @@ int snmp6_unregister_dev(struct inet6_dev *idev) { - if (!proc_net_devsnmp6) + down(&proc_net_devsnmp6_sem); + if (!proc_net_devsnmp6) { + up(&proc_net_devsnmp6_sem); return -ENOENT; - if (!idev || !idev->stats.proc_dir_entry) + } + if (!idev || !idev->stats.proc_dir_entry) { + up(&proc_net_devsnmp6_sem); return -EINVAL; + } remove_proc_entry(idev->stats.proc_dir_entry->name, proc_net_devsnmp6); + if (!--proc_net_devsnmp6_users) { + proc_net_remove("dev_snmp6"); + proc_net_devsnmp6 = NULL; + } + up(&proc_net_devsnmp6_sem); + snmp6_mib_free((void **)idev->stats.icmpv6); return 0; @@ -250,18 +277,12 @@ if (!proc_net_fops_create("snmp6", S_IRUGO, &snmp6_seq_fops)) goto proc_snmp6_fail; - proc_net_devsnmp6 = proc_mkdir("dev_snmp6", proc_net); - if (!proc_net_devsnmp6) - goto proc_dev_snmp6_fail; - if (!proc_net_fops_create("sockstat6", S_IRUGO, &sockstat6_seq_fops)) goto proc_sockstat6_fail; out: return rc; proc_sockstat6_fail: - proc_net_remove("dev_snmp6"); -proc_dev_snmp6_fail: proc_net_remove("snmp6"); proc_snmp6_fail: rc = -ENOMEM; @@ -271,7 +292,6 @@ void ipv6_misc_proc_exit(void) { proc_net_remove("sockstat6"); - proc_net_remove("dev_snmp6"); proc_net_remove("snmp6"); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sun Feb 20 23:28:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Feb 2005 23:28:36 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L7SWGi012401 for ; Sun, 20 Feb 2005 23:28:32 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B0CB433CC2; Mon, 21 Feb 2005 16:29:50 +0900 (JST) Date: Mon, 21 Feb 2005 16:29:49 +0900 (JST) Message-Id: <20050221.162949.65179228.yoshfuji@linux-ipv6.org> To: AndyLiebman@aol.com, terryg@axian.com Cc: netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: Frequent Oops on Shutdown 2.6.10 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050221.162241.24618885.yoshfuji@linux-ipv6.org> References: <20050220220304.1f2bd42f.akpm@osdl.org> <20050221.162241.24618885.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1866 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: 3563 Lines: 139 In article <20050221.162241.24618885.yoshfuji@linux-ipv6.org> (at Mon, 21 Feb 2005 16:22:41 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. > > Signed-off-by: Hideaki YOSHIFUJI > > ===== net/ipv6/proc.c 1.25 vs edited ===== > --- 1.25/net/ipv6/proc.c 2004-07-08 07:17:29 +09:00 > +++ edited/net/ipv6/proc.c 2005-02-21 16:05:49 +09:00 : > - if (!p) > + if (!p) { > + if (!proc_net_devsnmp6_users) > + proc_net_remove("dev_snmp6"); > goto err_proc; > + } Oops, sorry, I made a mistake here. Please try this instead. Thanks. ------ [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/proc.c 1.25 vs edited ===== --- 1.25/net/ipv6/proc.c 2004-07-08 07:17:29 +09:00 +++ edited/net/ipv6/proc.c 2005-02-21 16:23:57 +09:00 @@ -31,7 +31,9 @@ #include #ifdef CONFIG_PROC_FS -static struct proc_dir_entry *proc_net_devsnmp6; +struct proc_dir_entry *proc_net_devsnmp6; +static DECLARE_MUTEX(proc_net_devsnmp6_sem); +static unsigned int proc_net_devsnmp6_users; static int fold_prot_inuse(struct proto *proto) { @@ -211,13 +213,28 @@ __alignof__(struct icmpv6_mib)) < 0) goto err_icmp; - if (!proc_net_devsnmp6) { - err = -ENOENT; - goto err_proc; + down(&proc_net_devsnmp6_sem); + if (!proc_net_devsnmp6_users) { + proc_net_devsnmp6 = proc_mkdir("dev_snmp6", proc_net); + if (!proc_net_devsnmp6) { + err = -ENOMEM; + printk(KERN_ERR "%s(): failed to create dev_snmp6.\n", + __FUNCTION__); + goto err_proc; + } } p = create_proc_entry(idev->dev->name, S_IRUGO, proc_net_devsnmp6); - if (!p) + if (!p) { + if (!proc_net_devsnmp6_users) { + proc_net_remove("dev_snmp6"); + proc_net_devsnmp6 = NULL; + } goto err_proc; + } + + proc_net_devsnmp6_users++; + up(&proc_net_devsnmp6_sem); + p->data = idev; p->proc_fops = &snmp6_seq_fops; @@ -225,6 +242,7 @@ return 0; err_proc: + up(&proc_net_devsnmp6_sem); snmp6_mib_free((void **)idev->stats.icmpv6); err_icmp: return err; @@ -232,12 +250,23 @@ int snmp6_unregister_dev(struct inet6_dev *idev) { - if (!proc_net_devsnmp6) + down(&proc_net_devsnmp6_sem); + if (!proc_net_devsnmp6) { + up(&proc_net_devsnmp6_sem); return -ENOENT; - if (!idev || !idev->stats.proc_dir_entry) + } + if (!idev || !idev->stats.proc_dir_entry) { + up(&proc_net_devsnmp6_sem); return -EINVAL; + } remove_proc_entry(idev->stats.proc_dir_entry->name, proc_net_devsnmp6); + if (!--proc_net_devsnmp6_users) { + proc_net_remove("dev_snmp6"); + proc_net_devsnmp6 = NULL; + } + up(&proc_net_devsnmp6_sem); + snmp6_mib_free((void **)idev->stats.icmpv6); return 0; @@ -250,18 +279,12 @@ if (!proc_net_fops_create("snmp6", S_IRUGO, &snmp6_seq_fops)) goto proc_snmp6_fail; - proc_net_devsnmp6 = proc_mkdir("dev_snmp6", proc_net); - if (!proc_net_devsnmp6) - goto proc_dev_snmp6_fail; - if (!proc_net_fops_create("sockstat6", S_IRUGO, &sockstat6_seq_fops)) goto proc_sockstat6_fail; out: return rc; proc_sockstat6_fail: - proc_net_remove("dev_snmp6"); -proc_dev_snmp6_fail: proc_net_remove("snmp6"); proc_snmp6_fail: rc = -ENOMEM; @@ -271,7 +294,6 @@ void ipv6_misc_proc_exit(void) { proc_net_remove("sockstat6"); - proc_net_remove("dev_snmp6"); proc_net_remove("snmp6"); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From romieu@fr.zoreil.com Mon Feb 21 00:19:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 00:19:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L8Ja9G017716 for ; Mon, 21 Feb 2005 00:19:37 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1L8GOBA018891; Mon, 21 Feb 2005 09:16:24 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1L8GJer018890; Mon, 21 Feb 2005 09:16:19 +0100 Date: Mon, 21 Feb 2005 09:16:19 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] r8169: code clean-up Message-ID: <20050221081619.GA18754@electric-eye.fr.zoreil.com> References: <200502161823.43562.jdmason@us.ibm.com> <200502201204.23468.jdmason@us.ibm.com> <20050220233405.GA14268@electric-eye.fr.zoreil.com> <200502202254.23511.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502202254.23511.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1867 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: 236 Lines: 9 Jon Mason : [...] > My main problem with the above patch is that is assumes that there will > be a maximum of 2 descriptors per jumbo frame (which isn't the case). Where do you see such an assumption ? -- Ueimor From ahu@outpost.ds9a.nl Mon Feb 21 01:01:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 01:01:36 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L91O3T019775 for ; Mon, 21 Feb 2005 01:01:24 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 054EA4010; Mon, 21 Feb 2005 10:01:21 +0100 (CET) Date: Mon, 21 Feb 2005 10:01:21 +0100 From: bert hubert To: Christian Schmid Cc: Nivedita Singhvi , netdev@oss.sgi.com Subject: many outgoing tcp sockets are slower than a few Message-ID: <20050221090121.GA7478@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Christian Schmid , Nivedita Singhvi , netdev@oss.sgi.com References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42192CD5.5090401@rapidforum.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1444 Lines: 40 On Mon, Feb 21, 2005 at 01:35:33AM +0100, Christian Schmid wrote: > New connections get made without any problems. Just existing connections > slow down painfully. Incoming our outgoing data mostly? > 3000 sockets = no slowdown at all (500 MBit in use) > 3300 sockets = 10% slowdown > 3600 sockets = 30% slowdown > 4000 sockets = 60% slowdown (i aborted here, as it only uses 200 MBit for > sending... catastrophy!) > > They are all receiving data. Its a download-service. receive-buffer is set > to 24 KB and send-buffer set to 224 KB. I don't see a problem with > port-space. I only have 3500 sockets when the problem appears but it > appears suddenly. I'm a bit confused, it is a download service so you are probably *sending* data? > >But it would help if you looked at the stats and ifconfig > >to see who's dropping packets, how many retransmissions there > >are, memory failures, or the bottleneck is some other issue altogether... > > No way. Doing 30000 packets per second and your stats are 32 bit integers ;) So? You could be a bit more helpful. Sample over 5 seconds, you won't overflow that. Also, can you tcpdump a bit? Are you using iptables? The conntrack table might be slowing you down. I have a hunch this problem has to do with high-mem issues though. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From webmaster@rapidforum.com Mon Feb 21 02:36:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 02:36:59 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LAakpR003370 for ; Mon, 21 Feb 2005 02:36:47 -0800 Received: (qmail 8291 invoked by uid 1004); 21 Feb 2005 10:36:44 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 10:36:44 -0000 Message-ID: <4219B99E.1000603@rapidforum.com> Date: Mon, 21 Feb 2005 11:36:14 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: bert hubert CC: Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> In-Reply-To: <20050221090121.GA7478@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 3808 Lines: 96 bert hubert wrote: > On Mon, Feb 21, 2005 at 01:35:33AM +0100, Christian Schmid wrote: > > >>New connections get made without any problems. Just existing connections >>slow down painfully. > > > Incoming our outgoing data mostly? Outgoing data. I am using sendfile() to send the file on a non-blocking socket but the call blocks for 100 ms per socket if I get over 3000 sockets. Thats causing the massive slowdown in sum. I first thought its a disk-issue but I tried with pure-cache data as well and it still blocks. >>3000 sockets = no slowdown at all (500 MBit in use) >>3300 sockets = 10% slowdown >>3600 sockets = 30% slowdown >>4000 sockets = 60% slowdown (i aborted here, as it only uses 200 MBit for >>sending... catastrophy!) >> >>They are all receiving data. Its a download-service. receive-buffer is set >>to 24 KB and send-buffer set to 224 KB. I don't see a problem with >>port-space. I only have 3500 sockets when the problem appears but it >>appears suddenly. > > > I'm a bit confused, it is a download service so you are probably *sending* > data? Only sending. Receiving ACKs of course. >>>But it would help if you looked at the stats and ifconfig >>>to see who's dropping packets, how many retransmissions there >>>are, memory failures, or the bottleneck is some other issue altogether... >> >>No way. Doing 30000 packets per second and your stats are 32 bit integers ;) > So? You could be a bit more helpful. Sample over 5 seconds, you won't > overflow that. 5 seconds, here you go: eth0 Link encap:Ethernet HWaddr 00:30:48:27:84:28 inet addr:80.237.244.12 Bcast:80.237.244.63 Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2861390424 errors:5991038 dropped:5991056 overruns:38681 frame:4294967287 TX packets:2906616171 errors:4294967279 dropped:0 overruns:0 carrier:4294967278 collisions:4294967289 txqueuelen:1000 RX bytes:1613084024 (1538.3 Mb) TX bytes:2528808392 (2411.6 Mb) Base address:0x4000 Memory:fc000000-fc020000 eth0 Link encap:Ethernet HWaddr 00:30:48:27:84:28 inet addr:80.237.244.12 Bcast:80.237.244.63 Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2861511619 errors:5991038 dropped:5991056 overruns:38681 frame:4294967287 TX packets:2906804392 errors:4294967279 dropped:0 overruns:0 carrier:4294967278 collisions:4294967289 txqueuelen:1000 RX bytes:1625289307 (1549.9 Mb) TX bytes:2802520805 (2672.6 Mb) Base address:0x4000 Memory:fc000000-fc020000 > Also, can you tcpdump a bit? Are you using iptables? The conntrack table > might be slowing you down. Hmmm tcpdump what exactly? I am using iptables and the conntrack-problem has been solved in the past already by disabling conn-tracking. The table overran and it dropped packets massively. I disabled conn-tracking and the problem was gone. This is a different problem though. > I have a hunch this problem has to do with high-mem issues though. Well, 6 GB of high-mem, 2 GB of low-mem... at least there is not too less memory. MemTotal: 8314392 kB MemFree: 13936 kB Buffers: 28732 kB Cached: 7926792 kB SwapCached: 0 kB Active: 3129028 kB Inactive: 5031240 kB HighTotal: 6421952 kB HighFree: 640 kB LowTotal: 1892440 kB LowFree: 13296 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 54160 kB Writeback: 0 kB Mapped: 210108 kB Slab: 128176 kB CommitLimit: 4157196 kB Committed_AS: 674072 kB PageTables: 1604 kB VmallocTotal: 114680 kB VmallocUsed: 1160 kB VmallocChunk: 113416 kB Best regards, Chris From ak@muc.de Mon Feb 21 03:37:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 03:38:03 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LBbvsd007306 for ; Mon, 21 Feb 2005 03:37:57 -0800 Received: (qmail 88472 invoked by uid 3709); 21 Feb 2005 11:37:56 -0000 Date: 21 Feb 2005 12:37:56 +0100 Date: Mon, 21 Feb 2005 12:37:56 +0100 From: Andi Kleen To: Alex Aizman Cc: "'Leonid Grossman'" , "'rick jones'" , netdev@oss.sgi.com Subject: Re: Intel and TOE in the news Message-ID: <20050221113756.GA87576@muc.de> References: <20050220230713.GA62354@muc.de> <200502210158.j1L1wcDD004318@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502210158.j1L1wcDD004318@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1870 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: 1215 Lines: 32 On Sun, Feb 20, 2005 at 05:57:56PM -0800, Alex Aizman wrote: > > That's what we do, simply because interrupts are coalesced. > > > The function doesn't do the full packet > > processing, but just stuffs the packet into a CPU queue that > > is processed at a lower priority interrupt (softirq). > > There's the netif_rx's own per-packet overhead (including the call itself) > that arguably could be optimized.. netif_rx should be pretty cheap. It could be probably optimized more (e.g. no local_irq_save if you know you're comming from a interrupt or somehow avoiding the atomic reference count increase on the device), but I suspect there are other areas that could be improved first. > > Most interesting would be to use per CPU TX completion > > interrupts using MSI-X and avoid bouncing packets around between CPUs. > > Our experimental Linux driver already supports MSI and MSI-X (the latter not > tested). Once/if multi-MSI support in Linux becomes available it'd be > practically possible to scale TCP connections with a number of CPUs. It's already available, although the API is still a bit clumpsy. > Alternative: wait until Xframe II adapter w/MSI-X.. How does that help with MSI? -Andi From ak@muc.de Mon Feb 21 03:50:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 03:50:20 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LBo7Nw007996 for ; Mon, 21 Feb 2005 03:50:16 -0800 Received: (qmail 92019 invoked by uid 3709); 21 Feb 2005 11:50:06 -0000 Date: 21 Feb 2005 12:50:06 +0100 Date: Mon, 21 Feb 2005 12:50:06 +0100 From: Andi Kleen To: Leonid Grossman Cc: "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221115006.GB87576@muc.de> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502210332.j1L3WkDD014744@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1871 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: 1875 Lines: 41 On Sun, Feb 20, 2005 at 07:31:55PM -0800, Leonid Grossman wrote: > Yes, this is what we currently do; I was rather thinking about the option to > indicate multiple packets in a single call (say as a linked list). For the non NAPI case the packet is just put into a queue anyways. If you want to process packets as lists then just the consumer of the queue would need to be changed. I agree that it would be a good idea to lower locking overhead. That would only help much though if all the packets in a list belong to the same stream, otherwise you need multiple locks anyways for different sockets and it would be useless. For NAPI there would need to be some higher level changes for this. The main problem is that someone has to go through all the protocol layers and make sure they can process lists. Also it needs careful handling in netfilter. > > Most interesting would be to use per CPU TX completion > > interrupts using MSI-X and avoid bouncing packets around between CPUs. > > Do you mean indicating rx packets to the same cpu that tx (for the same > session) came from, or something else? Just freeing TX packets on the same CPU as they were submitted. This way the skb will always stay in the per CPU slab cache. Should be straight forward: you hash the CPU number to the 8 transmit queues in dev_queue_xmit, then give each queue an own TX MSI and set the irq affinity of its interrupt to its CPUs. If you have more than 8 CPUs there will be still some bouncing, but e.g. on a NUMA system you could keep it at least node local or near in the machine topology (2.6 has the necessary topology information in the kernel for this now; just distance information has to be still gotten from ACPI) Should be all possible to do from the driver without stack changes. Using it usefully in RX is probably much harder and would need stack changes. -Andi From buytenh@wantstofly.org Mon Feb 21 04:02:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 04:02:35 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LC2OXL009227 for ; Mon, 21 Feb 2005 04:02:25 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id C68F32B0ED; Mon, 21 Feb 2005 13:02:23 +0100 (MET) Date: Mon, 21 Feb 2005 13:02:23 +0100 From: Lennert Buytenhek To: Christian Schmid Cc: bert hubert , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few Message-ID: <20050221120223.GA30348@xi.wantstofly.org> References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4219B99E.1000603@rapidforum.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 572 Lines: 14 On Mon, Feb 21, 2005 at 11:36:14AM +0100, Christian Schmid wrote: > Outgoing data. I am using sendfile() to send the file on a non-blocking > socket but the call blocks for 100 ms per socket if I get over 3000 > sockets. Thats causing the massive slowdown in sum. I first thought its a > disk-issue but I tried with pure-cache data as well and it still blocks. O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() really isn't, as it still does the disk read (if any) synchronously. How are you making sure that you're sending "pure-cache data"? --L From ahu@outpost.ds9a.nl Mon Feb 21 04:25:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 04:25:51 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LCPisJ013724 for ; Mon, 21 Feb 2005 04:25:44 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A39A74010; Mon, 21 Feb 2005 13:25:41 +0100 (CET) Date: Mon, 21 Feb 2005 13:25:41 +0100 From: bert hubert To: Lennert Buytenhek Cc: Christian Schmid , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few Message-ID: <20050221122540.GA13973@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Lennert Buytenhek , Christian Schmid , Nivedita Singhvi , netdev@oss.sgi.com References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221120223.GA30348@xi.wantstofly.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 357 Lines: 8 On Mon, Feb 21, 2005 at 01:02:23PM +0100, Lennert Buytenhek wrote: > O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() It is? So it returns EAGAIN if the data to be sent is not in the page cache? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From buytenh@wantstofly.org Mon Feb 21 04:36:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 04:36:59 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LCasqa015501 for ; Mon, 21 Feb 2005 04:36:55 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id ADCD22B0ED; Mon, 21 Feb 2005 13:36:53 +0100 (MET) Date: Mon, 21 Feb 2005 13:36:53 +0100 From: Lennert Buytenhek To: bert hubert , Christian Schmid , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few Message-ID: <20050221123653.GA30508@xi.wantstofly.org> References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> <20050221122540.GA13973@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221122540.GA13973@outpost.ds9a.nl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 387 Lines: 13 On Mon, Feb 21, 2005 at 01:25:41PM +0100, bert hubert wrote: > > O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() > > It is? So it returns EAGAIN if the data to be sent is not in the > page cache? No, it just blocks. It only returns EAGAIN if the data is in the page cache but the socket TX queue doesn't have enough space. (At least, when I last tried it.) --L From tgraf@suug.ch Mon Feb 21 05:28:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 05:28:33 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LDSQmj020016 for ; Mon, 21 Feb 2005 05:28:27 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 1F01B82; Mon, 21 Feb 2005 14:28:02 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8EB8B1C0EA; Mon, 21 Feb 2005 14:28:44 +0100 (CET) Date: Mon, 21 Feb 2005 14:28:44 +0100 From: Thomas Graf To: Andi Kleen Cc: Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221132844.GU31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221115006.GB87576@muc.de> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 706 Lines: 12 * Andi Kleen <20050221115006.GB87576@muc.de> 2005-02-21 12:50 > The main problem is that someone has to go through all the protocol layers > and make sure they can process lists. Also it needs careful handling > in netfilter. Special handling is also required for the ingress qdisc. The classifiers or tc_classify() must be changed to iterate over the lists and unlink the skbs if one of them is to be dropped. The mirred action must probably split the list after cloning the skbs. Given the lists are session based all session based qdiscs could benefit from this and enqueue/dequeue the lists rather than single skbs. Other qdiscs would have to split the lists but could return a new list upon dequeue. From P@draigBrady.com Mon Feb 21 05:59:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 05:59:29 -0800 (PST) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LDxJHr022042 for ; Mon, 21 Feb 2005 05:59:20 -0800 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id j1LDxCwS070150; Mon, 21 Feb 2005 13:59:13 GMT (envelope-from P@draigBrady.com) Message-ID: <4219E930.9080802@draigBrady.com> Date: Mon, 21 Feb 2005 13:59:12 +0000 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: Jeff Garzik CC: Netdev Subject: Re: Intel and TOE in the news References: <4216B62D.6000502@pobox.com> In-Reply-To: <4216B62D.6000502@pobox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1876 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: 266 Lines: 10 Jeff Garzik wrote: > > http://www.theregister.co.uk/2005/02/18/intel_tcpip_attack/ I wonder is this ETA in conjunction with multicore CPUs? http://www.hoti.org/archive/Hoti11_program/papers/hoti11_11_regnier_g.pdf -- Pádraig Brady - http://www.pixelbeat.org -- From baruch@ev-en.org Mon Feb 21 05:59:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 05:59:43 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LDxUQ4022052 for ; Mon, 21 Feb 2005 05:59:30 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 4138411A637; Mon, 21 Feb 2005 15:59:24 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id A7C6A11A596; Mon, 21 Feb 2005 15:59:20 +0200 (IST) Message-ID: <4219E937.6030108@ev-en.org> Date: Mon, 21 Feb 2005 13:59:19 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid Cc: bert hubert , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> In-Reply-To: <4219B99E.1000603@rapidforum.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1190 Lines: 31 Christian Schmid wrote: > bert hubert wrote: > >> On Mon, Feb 21, 2005 at 01:35:33AM +0100, Christian Schmid wrote: > Outgoing data. I am using sendfile() to send the file on a non-blocking > socket but the call blocks for 100 ms per socket if I get over 3000 > sockets. Thats causing the massive slowdown in sum. I first thought its > a disk-issue but I tried with pure-cache data as well and it still blocks. > >>> 3000 sockets = no slowdown at all (500 MBit in use) >>> 3300 sockets = 10% slowdown >>> 3600 sockets = 30% slowdown >>> 4000 sockets = 60% slowdown (i aborted here, as it only uses 200 MBit >>> for sending... catastrophy!) >>> [snip] >> I'm a bit confused, it is a download service so you are probably >> *sending* >> data? > > Only sending. Receiving ACKs of course. I've been doing some work to improve ACK performance, you can find some patches for Linux 2.6.6 at http://hamilton.ie/net/ I've only tested these patches for a single (or few) very fast connections, but I'd expect the problem might manifest itself for a very large number of connections as well. Though then you might hit other bottlenecks (memory access for different structures). Baruch From ahu@outpost.ds9a.nl Mon Feb 21 06:00:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:00:40 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LE0W6O022657 for ; Mon, 21 Feb 2005 06:00:33 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 91D404010; Mon, 21 Feb 2005 15:00:31 +0100 (CET) Date: Mon, 21 Feb 2005 15:00:31 +0100 From: bert hubert To: netdev@oss.sgi.com Subject: [Yee-Ting.Li@nuim.ie: BicTCP Implementation Bug] Message-ID: <20050221140031.GA15766@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 2007 Lines: 54 ----- Forwarded message from Yee-Ting Li ----- Date: Mon, 21 Feb 2005 13:47:29 +0000 From: Yee-Ting Li Subject: BicTCP Implementation Bug To: linux-net@vger.kernel.org, end2end-interest@postel.org, linux-kernel@vger.kernel.org Cc: Douglas Leith , Richard Hughes-Jones , Baruch Even , Les Cottrell , davem@davemloft.net, rhee@ncsu.edu X-Mailer: Apple Mail (2.619.2) X-Mailing-List: linux-kernel@vger.kernel.org Hi, We have discovered a serious implementation bug in BicTCP on the Linux kernels. Note that because BicTCP is ON by default, this affects all users of kernel versions 2.6.8 and above. For further details please see: http://www.hamilton.ie/net/bic-fix/Linux%20BicTCP.pdf and the patch is: Index: linux-2.6.10/include/net/tcp.h =================================================================== --- linux-2.6.10.orig/include/net/tcp.h Fri Dec 24 21:34:00 2004 +++ linux-2.6.10/include/net/tcp.h Thu Feb 17 14:13:14 2005 @@ -1280,8 +1280,7 @@ if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) tp->bictcp.last_max_cwnd - = (tp->snd_cwnd * (2*BICTCP_1_OVER_BETA-1)) - / (BICTCP_1_OVER_BETA/2); + = tp->snd_cwnd - ( tp->snd_cwnd / (BICTCP_1_OVER_BETA*2) ); else tp->bictcp.last_max_cwnd = tp->snd_cwnd; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ----- End forwarded message ----- -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From hadi@cyberus.ca Mon Feb 21 06:02:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:02:07 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LE22Q3023390 for ; Mon, 21 Feb 2005 06:02:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D3E8N-0004sH-Mw for netdev@oss.sgi.com; Mon, 21 Feb 2005 09:01:59 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3E8F-0006Sg-Sd; Mon, 21 Feb 2005 09:01:52 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Eugene Surovegin Cc: Andi Kleen , "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050220164607.GA27891@gate.ebshome.net> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> <20050219114624.373af63f.davem@davemloft.net> <20050220164607.GA27891@gate.ebshome.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108994508.1090.155.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 09:01:49 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1879 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: 1070 Lines: 27 On Sun, 2005-02-20 at 11:46, Eugene Surovegin wrote: > On Sat, Feb 19, 2005 at 09:27:31PM +0100, Andi Kleen wrote: > > > > > > It would be nice if the NIC could asynchronously trigger prefetches in > > the CPU. Currently a lot of the packet processing cost goes > > to waiting for read cache misses. > > Just FYI :), Freescale 85xx TSECs can prefetch buffers into L2 cache. > IIRC they call it buffer "stashing" and gianfar driver has a config > option to enable such behavior. > > But in embedded world you usually don't see flashy PR releases for > such features :). yes ;-> Big bad Intel is now going to do this, the rest of the world better listen. I have a modified sb1250 driver that i converted to NAPI that does this (in kernel driver doesnt do either NAPI or stash packets into cache). Reminds me i have to find that driver and submit. In any case, the problem could be x86; about every MIPS board i have seen (I heard PMC-sierra as well) can do this. To be fair to Big Bad Intel, they may have made a PR or two ;-> cheers, jamal From hadi@cyberus.ca Mon Feb 21 06:03:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:03:55 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LE3orM024111 for ; Mon, 21 Feb 2005 06:03:50 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D3EA6-0004mT-Jx for netdev@oss.sgi.com; Mon, 21 Feb 2005 09:03:46 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3EA4-0006o6-Ew; Mon, 21 Feb 2005 09:03:44 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <20050221132844.GU31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108994621.1089.158.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 09:03:42 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1880 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: 972 Lines: 25 Everything in the stack would have to be re-written not just that one piece. The question is: Is it worth it? My experimentation shows, only in a few speacilized cases. cheers, jamal On Mon, 2005-02-21 at 08:28, Thomas Graf wrote: > * Andi Kleen <20050221115006.GB87576@muc.de> 2005-02-21 12:50 > > The main problem is that someone has to go through all the protocol layers > > and make sure they can process lists. Also it needs careful handling > > in netfilter. > > Special handling is also required for the ingress qdisc. The classifiers > or tc_classify() must be changed to iterate over the lists and unlink > the skbs if one of them is to be dropped. The mirred action must probably > split the list after cloning the skbs. Given the lists are session based > all session based qdiscs could benefit from this and enqueue/dequeue the > lists rather than single skbs. Other qdiscs would have to split the lists > but could return a new list upon dequeue. > > From hadi@cyberus.ca Mon Feb 21 06:10:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:10:18 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LEADbW024763 for ; Mon, 21 Feb 2005 06:10:14 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D3EGH-00043D-Nw for netdev@oss.sgi.com; Mon, 21 Feb 2005 09:10:09 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3EGF-0007in-Qg; Mon, 21 Feb 2005 09:10:08 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: P@draigBrady.com Cc: Jeff Garzik , Netdev In-Reply-To: <4219E930.9080802@draigBrady.com> References: <4216B62D.6000502@pobox.com> <4219E930.9080802@draigBrady.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108995005.1091.165.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 09:10:05 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1881 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: 887 Lines: 22 On Mon, 2005-02-21 at 08:59, P@draigBrady.com wrote: > Jeff Garzik wrote: > > > > http://www.theregister.co.uk/2005/02/18/intel_tcpip_attack/ > > I wonder is this ETA in conjunction with multicore CPUs? > http://www.hoti.org/archive/Hoti11_program/papers/hoti11_11_regnier_g.pdf I have a feeling ETA is one of the things behind theregister announce. If you ask my opinion, its not a very smart idea. Now they have to write a speacial stack just to sit in this one XEON processor they have while the other(s) run Linux. They will not get 3x what Linux can today for a simple app as L3 packet forwarding for example. And when it gets to actually providing the features linux provides, they will be either at the same speed or even worse depending on where they started. Broadcom btw is preaching the same angle. What intel needs to do is kill its chipset division ;-> cheers, jamal From Robert.Olsson@data.slu.se Mon Feb 21 06:13:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:14:00 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LEDtYE025337 for ; Mon, 21 Feb 2005 06:13:56 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j1LEDmsT007393; Mon, 21 Feb 2005 15:13:49 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id F1EBCEE2A4; Mon, 21 Feb 2005 15:13:48 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16921.60572.951532.31861@robur.slu.se> Date: Mon, 21 Feb 2005 15:13:48 +0100 To: "Randy.Dunlap" Cc: Francois Romieu , robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage In-Reply-To: <42166E3F.2050304@osdl.org> References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> <42166E3F.2050304@osdl.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1882 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: 3209 Lines: 111 Randy.Dunlap writes: > I don't see any simultaneous uses of the 2 buffers, so here's the > union version of the patch (attached this time), although it only > saves 4 bytes... so maybe the compiler had already realized that > usage. Either one accomplishes a large stack reduction, but the Hello! Here is version with just one buffer. How did you calculate the saving? --ro --- net/core/pktgen.c.050221 2005-02-21 14:02:40.000000000 +0100 +++ net/core/pktgen.c 2005-02-21 15:02:44.000000000 +0100 @@ -151,7 +151,7 @@ #include -#define VERSION "pktgen v2.57: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -811,6 +811,7 @@ struct pktgen_dev *pkt_dev = (struct pktgen_dev*)(data); char* pg_result = NULL; int tmp = 0; + char buf[128]; pg_result = &(pkt_dev->result[0]); @@ -1071,7 +1072,6 @@ return count; } if (!strcmp(name, "dst_min") || !strcmp(name, "dst")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_min) - 1); if (len < 0) { return len; } @@ -1091,7 +1091,6 @@ return count; } if (!strcmp(name, "dst_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_max) - 1); if (len < 0) { return len; } @@ -1112,9 +1111,7 @@ return count; } if (!strcmp(name, "dst6")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1136,9 +1133,7 @@ return count; } if (!strcmp(name, "dst6_min")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1159,9 +1154,7 @@ return count; } if (!strcmp(name, "dst6_max")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1181,9 +1174,7 @@ return count; } if (!strcmp(name, "src6")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1205,7 +1196,6 @@ return count; } if (!strcmp(name, "src_min")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_min) - 1); if (len < 0) { return len; } if (copy_from_user(buf, &user_buffer[i], len)) @@ -1224,7 +1214,6 @@ return count; } if (!strcmp(name, "src_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_max) - 1); if (len < 0) { return len; } if (copy_from_user(buf, &user_buffer[i], len)) From tgraf@suug.ch Mon Feb 21 06:16:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:18:20 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LEGtgu025876 for ; Mon, 21 Feb 2005 06:16:56 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 596EA82; Mon, 21 Feb 2005 15:16:32 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8C28C1C0EA; Mon, 21 Feb 2005 15:17:14 +0100 (CET) Date: Mon, 21 Feb 2005 15:17:14 +0100 From: Thomas Graf To: jamal Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221141714.GV31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108994621.1089.158.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 885 Lines: 16 * jamal <1108994621.1089.158.camel@jzny.localdomain> 2005-02-21 09:03 > > Everything in the stack would have to be re-written not just that one > piece. > The question is: Is it worth it? My experimentation shows, only in a few > speacilized cases. Assuming we can deliver a chain of skbs to enqueue (session based or not), the locking times should decrease. I'm not sure whether it's worth to rewrite the whole stack (I wouldn't have any use for it) or just establish a fast path. We could for example allow the ingress qdisc to redirect packets directly to a egress qdisc and have "dynamic" fast forwarding. We can add an action looking up the route and rewriting the packet as needed and enqueue it to the right qdisc immediately. The redirect action is already on that way, now if we can reduce the locking overhead a bit more the fast forwarding routing t-put should increase. From hadi@cyberus.ca Mon Feb 21 06:31:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:31:41 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LEVaw9026727 for ; Mon, 21 Feb 2005 06:31:37 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D3Eay-000241-S9 for netdev@oss.sgi.com; Mon, 21 Feb 2005 09:31:32 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3Drx-0003QD-JX; Mon, 21 Feb 2005 08:45:01 -0500 Subject: RE: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: "'Andi Kleen'" , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <200502202244.j1KMinDD013572@guinness.s2io.com> References: <200502202244.j1KMinDD013572@guinness.s2io.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108993498.1089.149.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 08:44:58 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1884 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: 1067 Lines: 26 On Sun, 2005-02-20 at 17:43, Leonid Grossman wrote: > Andi, > This is an interesting idea, we'll play around... > > BTW - does anybody know if it's possible to indicate multiple receive > packets? > > In other OS drivers we have an option to indicate a "packet train" that got > received during an interrupt, Explain what you mean by "packet train". If you mean a burst of random packets that just happened to arrive back to back, then it is not useful. NAPI already does a sufficently great job at processing these by pulling them off the DMA ring and processing to completion. OTOH, if you mean a train of packets terminating at exactly the same location i.e related to the same flow, then this would be useful. I suspect the later would require extreme intelligence that may not be suited for your NIC. This leaves you with only nicecities of spliting a packet into header/data which may allow for nice gather-scatter techniques. Remains to be seen (in other words, proof is in the pudding, make it - experiment and show that it tastes good). cheers, jamal From hadi@cyberus.ca Mon Feb 21 06:32:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 06:32:06 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LEW2Gh026830 for ; Mon, 21 Feb 2005 06:32:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D3EbO-0002Nd-U4 for netdev@oss.sgi.com; Mon, 21 Feb 2005 09:31:58 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3EbM-0002sU-BI; Mon, 21 Feb 2005 09:31:56 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <20050221141714.GV31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1108996313.1090.178.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 09:31:53 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1885 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: 1607 Lines: 34 I have done the experiments and even posted the patches on netdev last year to batch on enqueue. Despite Andis assertion that theres value in amortizing the locks, the benefits are highly missing on a generic level unfortunately. Locking overhead is like the 50th item on things you have to worry about - so i wouldnt even start worrying about this. Infact performance goes down when you batch in some cases depending on the hardware used. My investigation shows that if you have a fast CPU and a fast bus, theres always only one packet in flight within the stack. Batching by definition requires more than one packet. cheers, jamal On Mon, 2005-02-21 at 09:17, Thomas Graf wrote: > * jamal <1108994621.1089.158.camel@jzny.localdomain> 2005-02-21 09:03 > > > > Everything in the stack would have to be re-written not just that one > > piece. > > The question is: Is it worth it? My experimentation shows, only in a few > > speacilized cases. > > Assuming we can deliver a chain of skbs to enqueue (session based or not), > the locking times should decrease. I'm not sure whether it's worth to > rewrite the whole stack (I wouldn't have any use for it) or just establish > a fast path. We could for example allow the ingress qdisc to redirect > packets directly to a egress qdisc and have "dynamic" fast forwarding. > We can add an action looking up the route and rewriting the packet as > needed and enqueue it to the right qdisc immediately. The redirect action > is already on that way, now if we can reduce the locking overhead a bit > more the fast forwarding routing t-put should increase. > From tgraf@suug.ch Mon Feb 21 07:34:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 07:34:31 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LFYQq7029328 for ; Mon, 21 Feb 2005 07:34:27 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 26BDC82; Mon, 21 Feb 2005 16:34:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 678E51C0EA; Mon, 21 Feb 2005 16:34:43 +0100 (CET) Date: Mon, 21 Feb 2005 16:34:43 +0100 From: Thomas Graf To: jamal Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221153443.GW31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108996313.1090.178.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1260 Lines: 26 * jamal <1108996313.1090.178.camel@jzny.localdomain> 2005-02-21 09:31 > > I have done the experiments and even posted the patches on netdev last > year to batch on enqueue. Right, I slightly remember. I have a head like a sieve. Can you remmeber the subject of the post? I can't find it in the archive. > Despite Andis assertion that theres value in amortizing the locks, the > benefits are highly missing on a generic level unfortunately. > Locking overhead is like the 50th item on things you have to worry about > - so i wouldnt even start worrying about this. OK. > Infact performance goes down when you batch in some cases depending on > the hardware used. My investigation shows that if you have a fast CPU > and a fast bus, theres always only one packet in flight within the > stack. Batching by definition requires more than one packet. Make sense but we probably have multiple packets in the stack if qdiscs are involved. What bottlenecks remain in that case? One is probably transmission not being able to keep up because receiving is using too much resources The transmitter dropping packets making the bottleneck even worse. Can we reduce the dropping by pushing multiple skbs to the nic by for example have dequeue return a batch of skbs? From Robert.Olsson@data.slu.se Mon Feb 21 07:38:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 07:38:12 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LFc8HM029997 for ; Mon, 21 Feb 2005 07:38:09 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j1LFc1iq026049; Mon, 21 Feb 2005 16:38:01 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 4B83AEE2A4; Mon, 21 Feb 2005 16:38:01 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16922.89.271972.745365@robur.slu.se> Date: Mon, 21 Feb 2005 16:38:01 +0100 To: hadi@cyberus.ca Cc: Thomas Graf , Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news In-Reply-To: <1108996313.1090.178.camel@jzny.localdomain> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1887 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: 523 Lines: 15 jamal writes: > Infact performance goes down when you batch in some cases depending on > the hardware used. My investigation shows that if you have a fast CPU > and a fast bus, theres always only one packet in flight within the > stack. Batching by definition requires more than one packet. Hello! Yes when queue length/batch increases you're risking to load the L2 twice for the same skb. Which is the most expensive operation.... Forwarding profiles show most functions where cache misses occur. --ro From hadi@cyberus.ca Mon Feb 21 07:48:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 07:49:00 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LFmtEK030925 for ; Mon, 21 Feb 2005 07:48:56 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D3Fnk-0003ll-81 for netdev@oss.sgi.com; Mon, 21 Feb 2005 08:48:48 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3Fnk-0000HF-8O; Mon, 21 Feb 2005 10:48:48 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <20050221153443.GW31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109000925.1076.3.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 10:48:45 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1888 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: 1208 Lines: 32 On Mon, 2005-02-21 at 10:34, Thomas Graf wrote: > * jamal <1108996313.1090.178.camel@jzny.localdomain> 2005-02-21 09:31 > > > > I have done the experiments and even posted the patches on netdev last > > year to batch on enqueue. > > Right, I slightly remember. I have a head like a sieve. Can you > remmeber the subject of the post? I can't find it in the archive. > I cant remember - patches are on another machine; the last time i posted was with some folks from .it who were trying to improve routing perfomance. > > Infact performance goes down when you batch in some cases depending on > > the hardware used. My investigation shows that if you have a fast CPU > > and a fast bus, theres always only one packet in flight within the > > stack. Batching by definition requires more than one packet. > > Make sense but we probably have multiple packets in the stack if qdiscs are > involved. No - thats the problem. Theres always no more than one packet i.e only packet in flight except in the case of some hardware - which i pointed out as problematic in my SUCON presentation. Maybe i should write a paper about this - i spent christmas collecting a lot of data using relayfs; cheers, jamal From hadi@cyberus.ca Mon Feb 21 07:50:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 07:51:03 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LFowvH031450 for ; Mon, 21 Feb 2005 07:50:59 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D3Fpp-0004mZ-5N for netdev@oss.sgi.com; Mon, 21 Feb 2005 10:50:57 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3Fpl-0000ed-S8; Mon, 21 Feb 2005 10:50:53 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Robert Olsson Cc: Thomas Graf , Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <16922.89.271972.745365@robur.slu.se> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <16922.89.271972.745365@robur.slu.se> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109001050.1076.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 10:50:51 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1889 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: 446 Lines: 14 On Mon, 2005-02-21 at 10:38, Robert Olsson wrote: > Yes when queue length/batch increases you're risking to load the L2 > twice for the same skb. Which is the most expensive operation.... You are probably onto something here. I have to rerun with varying batch sizes to see if this is true (although i did i think try with even 2 and still saw performance degradation). I will be revisiting these patches in about a month. cheers, jamal From rddunlap@osdl.org Mon Feb 21 08:13:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 08:13:06 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LGD1c0032582 for ; Mon, 21 Feb 2005 08:13:01 -0800 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1LGCWqi022941 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Feb 2005 08:12:32 -0800 Message-ID: <421A0880.5070205@osdl.org> Date: Mon, 21 Feb 2005 08:12:48 -0800 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: Francois Romieu , robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> <42166E3F.2050304@osdl.org> <16921.60572.951532.31861@robur.slu.se> In-Reply-To: <16921.60572.951532.31861@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1890 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: 3692 Lines: 124 Robert Olsson wrote: > Randy.Dunlap writes: > > > I don't see any simultaneous uses of the 2 buffers, so here's the > > union version of the patch (attached this time), although it only > > saves 4 bytes... so maybe the compiler had already realized that > > usage. Either one accomplishes a large stack reduction, but the > > Hello! > > Here is version with just one buffer. Yep, even better: few changes + using sizeof. > How did you calculate the saving? objdump the .o file before and after changes. Look at how much temp space is allocated by "sub const,%esp" (on x86). E.g.: 9e8: 81 ec 24 01 00 00 sub $0x124,%esp > --ro > > > > --- net/core/pktgen.c.050221 2005-02-21 14:02:40.000000000 +0100 > +++ net/core/pktgen.c 2005-02-21 15:02:44.000000000 +0100 > @@ -151,7 +151,7 @@ > #include > > > -#define VERSION "pktgen v2.57: Packet Generator for packet performance testing.\n" > +#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" > > /* #define PG_DEBUG(a) a */ > #define PG_DEBUG(a) > @@ -811,6 +811,7 @@ > struct pktgen_dev *pkt_dev = (struct pktgen_dev*)(data); > char* pg_result = NULL; > int tmp = 0; > + char buf[128]; > > pg_result = &(pkt_dev->result[0]); > > @@ -1071,7 +1072,6 @@ > return count; > } > if (!strcmp(name, "dst_min") || !strcmp(name, "dst")) { > - char buf[IP_NAME_SZ]; > len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_min) - 1); > if (len < 0) { return len; } > > @@ -1091,7 +1091,6 @@ > return count; > } > if (!strcmp(name, "dst_max")) { > - char buf[IP_NAME_SZ]; > len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_max) - 1); > if (len < 0) { return len; } > > @@ -1112,9 +1111,7 @@ > return count; > } > if (!strcmp(name, "dst6")) { > - char buf[128]; > - > - len = strn_len(&user_buffer[i], 128 - 1); > + len = strn_len(&user_buffer[i], sizeof(buf) - 1); > if (len < 0) return len; > > pkt_dev->flags |= F_IPV6; > @@ -1136,9 +1133,7 @@ > return count; > } > if (!strcmp(name, "dst6_min")) { > - char buf[128]; > - > - len = strn_len(&user_buffer[i], 128 - 1); > + len = strn_len(&user_buffer[i], sizeof(buf) - 1); > if (len < 0) return len; > > pkt_dev->flags |= F_IPV6; > @@ -1159,9 +1154,7 @@ > return count; > } > if (!strcmp(name, "dst6_max")) { > - char buf[128]; > - > - len = strn_len(&user_buffer[i], 128 - 1); > + len = strn_len(&user_buffer[i], sizeof(buf) - 1); > if (len < 0) return len; > > pkt_dev->flags |= F_IPV6; > @@ -1181,9 +1174,7 @@ > return count; > } > if (!strcmp(name, "src6")) { > - char buf[128]; > - > - len = strn_len(&user_buffer[i], 128 - 1); > + len = strn_len(&user_buffer[i], sizeof(buf) - 1); > if (len < 0) return len; > > pkt_dev->flags |= F_IPV6; > @@ -1205,7 +1196,6 @@ > return count; > } > if (!strcmp(name, "src_min")) { > - char buf[IP_NAME_SZ]; > len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_min) - 1); > if (len < 0) { return len; } > if (copy_from_user(buf, &user_buffer[i], len)) > @@ -1224,7 +1214,6 @@ > return count; > } > if (!strcmp(name, "src_max")) { > - char buf[IP_NAME_SZ]; > len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_max) - 1); > if (len < 0) { return len; } > if (copy_from_user(buf, &user_buffer[i], len)) -- ~Randy From rddunlap@osdl.org Mon Feb 21 08:27:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 08:27:17 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LGRDHK004351 for ; Mon, 21 Feb 2005 08:27:13 -0800 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1LGR3qi023869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Feb 2005 08:27:04 -0800 Message-ID: <421A0BE8.6050603@osdl.org> Date: Mon, 21 Feb 2005 08:27:20 -0800 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: robert.olsson@its.uu.se, netdev Subject: Re: [PATCH] pktgen: reduce stack usage References: <20050218134219.3f079110.rddunlap@osdl.org> <4216AAE4.1080804@candelatech.com> In-Reply-To: <4216AAE4.1080804@candelatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1891 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: 679 Lines: 26 Ben Greear wrote: > Randy.Dunlap wrote: > >> (resend) >> Any comments this time? >> >> pktgen: proc_if_write: reduce stack usage (on i386) >> from 776 to 296 bytes by combining/reusing locals. > > Since these methods are not in the fast path, and the stack > usage is not near 4k, does this really matter? It's not critical or near causing a stack overflow AFAICT. And ideally gcc would recognize this kind of usage and not allocate multiple stack entries for it. syscall: sys_write (tiny stack usage) -> vfs_write (tiny) -> proc_file_write (tiny) -> proc_if_write (pktgen: large) > I'm asking more to be educated than to dismiss the changes.... -- ~Randy From tgraf@suug.ch Mon Feb 21 08:39:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 08:39:51 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LGdkql005000 for ; Mon, 21 Feb 2005 08:39:47 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 5B39F82; Mon, 21 Feb 2005 17:39:23 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4A6F01C0EA; Mon, 21 Feb 2005 17:40:06 +0100 (CET) Date: Mon, 21 Feb 2005 17:40:06 +0100 From: Thomas Graf To: jamal Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221164006.GY31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109000925.1076.3.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1116 Lines: 23 * jamal <1109000925.1076.3.camel@jzny.localdomain> 2005-02-21 10:48 > On Mon, 2005-02-21 at 10:34, Thomas Graf wrote: > > Make sense but we probably have multiple packets in the stack if qdiscs are > > involved. > > No - thats the problem. Theres always no more than one packet i.e only > packet in flight except in the case of some hardware - which i pointed > out as problematic in my SUCON presentation. I read your slides again but I guess I'm missing the information you provided in your speech. One of the disadvantages of organizing a conference is that one can't listen to the speeches. ;-> > Maybe i should write a paper about this - i spent christmas collecting a > lot of data using relayfs; Would be nice, or at least provide the data. I haven't done any data collection execpt some basic data to check ematch performance depening on the size of the evalation tree, i.e. the number of ematches attached to a classifier to find out wehther further optimizations are needed. So basically you're telling me that it doesn't make a difference for a full qdisc to dequeue in single steps or in batches? From leonid.grossman@neterion.com Mon Feb 21 08:54:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 08:55:09 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LGsw4t008187 for ; Mon, 21 Feb 2005 08:54:59 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1LGrCdG023674; Mon, 21 Feb 2005 11:53:12 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1LGr3DD025897; Mon, 21 Feb 2005 11:53:04 -0500 (EST) Message-Id: <200502211653.j1LGr3DD025897@guinness.s2io.com> From: "Leonid Grossman" To: Cc: "'Andi Kleen'" , "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Mon, 21 Feb 2005 08:52:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUYIhIBxqdPCu9OSwuoZheayC9c4wADvc3Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <1108993498.1089.149.camel@jzny.localdomain> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1887 Lines: 50 > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of jamal > Sent: Monday, February 21, 2005 5:45 AM > To: Leonid Grossman > Cc: 'Andi Kleen'; 'rick jones'; netdev@oss.sgi.com; 'Alex Aizman' > Subject: RE: Intel and TOE in the news > > > In other OS drivers we have an option to indicate a "packet train" > > that got received during an interrupt, > > Explain what you mean by "packet train". If you mean a burst > of random packets that just happened to arrive back to back, > then it is not useful. NAPI already does a sufficently great > job at processing these by pulling them off the DMA ring and > processing to completion. Yes, the question was with regards to the burst of random packets. I agree that this may be not too useful and arguably doesn't warrant the significant stack change. The reason I asked is that one of our engineers was under impression (from reading Linux TCP/IP Stack book) that the feature is already supported. WRT to the burst of packets related to the same flow - we are hoping to be able to collapse the burst into a single oversized frame and pass it to the stack, this way no or very minimal changes to the stack will be needed. There is enough intelligence on the NIC to do that efficiently, we just need to try and see how well this works. Leonid > OTOH, if you mean a train of packets terminating at exactly > the same location i.e related to the same flow, then this > would be useful. > I suspect the later would require extreme intelligence that > may not be suited for your NIC. > This leaves you with only nicecities of spliting a packet > into header/data which may allow for nice gather-scatter > techniques. Remains to be seen (in other words, proof is in > the pudding, make it - experiment and show that it tastes good). > > cheers, > jamal > > > From hadi@cyberus.ca Mon Feb 21 09:03:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 09:03:20 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LH3EDW008952 for ; Mon, 21 Feb 2005 09:03:15 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D3Gxf-00021H-Ce for netdev@oss.sgi.com; Mon, 21 Feb 2005 10:03:07 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3Gxg-00059A-6I; Mon, 21 Feb 2005 12:03:08 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <20050221164006.GY31837@postel.suug.ch> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> <20050221164006.GY31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109005385.1074.68.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 12:03:05 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1894 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: 1797 Lines: 41 On Mon, 2005-02-21 at 11:40, Thomas Graf wrote: > * jamal <1109000925.1076.3.camel@jzny.localdomain> 2005-02-21 10:48 > > On Mon, 2005-02-21 at 10:34, Thomas Graf wrote: > > > Make sense but we probably have multiple packets in the stack if qdiscs are > > > involved. > > > > No - thats the problem. Theres always no more than one packet i.e only > > packet in flight except in the case of some hardware - which i pointed > > out as problematic in my SUCON presentation. > > I read your slides again but I guess I'm missing the information you > provided in your speech. One of the disadvantages of organizing a > conference is that one can't listen to the speeches. ;-> > Most of this came after SUCON actually after the BSD folks claimed to be doing 1Mpps forwarding (only to find out they used CSA later). Look at the case where we have 32 bit bus in those slides; in that scenario we do see an improvement with batching (but really for the wrong reasons). The next piece of hardware we see infact a degradation in perfomance. > So basically you're telling me that it doesn't make a difference for a > full qdisc to dequeue in single steps or in batches? I said in some cases it does make sense (as in the case of 32 bit bus above) in some it doesnt (as in the case of most xeon boards, fast CPU, fast PCI-X). Any solution should be where things work all the time or most of the time and are not very hardware specific. If we can hit 95% of the cases, then it would make sense to do submit such the patch. Otherwise it was a good exercise for me, but useless in general. I do plan to work on trying out some heuristics like discovering a few things (such as CPU speed, runtime congestion etc) before activating the batching code. Wont have time for at least 1 month. cheers, jamal From hadi@cyberus.ca Mon Feb 21 09:11:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 09:11:32 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LHBSug009582 for ; Mon, 21 Feb 2005 09:11:28 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D3H5i-0002aR-Sx for netdev@oss.sgi.com; Mon, 21 Feb 2005 12:11:26 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3H5f-0007Kd-Dh; Mon, 21 Feb 2005 12:11:23 -0500 Subject: RE: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: "'Andi Kleen'" , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" In-Reply-To: <200502211653.j1LGr3DD025897@guinness.s2io.com> References: <200502211653.j1LGr3DD025897@guinness.s2io.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109005880.1076.77.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 12:11:20 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1895 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: 803 Lines: 18 On Mon, 2005-02-21 at 11:52, Leonid Grossman wrote: > > WRT to the burst of packets related to the same flow - we are hoping to be > able to collapse the burst into a single oversized frame and pass it to the > stack, this way no or very minimal changes to the stack will be needed. > There is enough intelligence on the NIC to do that efficiently, we just need > to try and see how well this works. Indeed, would be nice to see what you come up with. I think there may be value in sending one huge chunk packet which itself is actually a collection of several independet packets when you have a huge amount of small packets. The benefit being you amortize the cost of DMA setup. But then you may need to be able to break them down in the driver; is this what you are talking about? cheers, jamal From webmaster@rapidforum.com Mon Feb 21 09:17:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 09:17:51 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LHHkxF010143 for ; Mon, 21 Feb 2005 09:17:47 -0800 Received: (qmail 2899 invoked by uid 1004); 21 Feb 2005 17:17:45 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 17:17:45 -0000 Message-ID: <421A179C.1030505@rapidforum.com> Date: Mon, 21 Feb 2005 18:17:16 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Lennert Buytenhek CC: bert hubert , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> In-Reply-To: <20050221120223.GA30348@xi.wantstofly.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 907 Lines: 24 Lennert Buytenhek wrote: > On Mon, Feb 21, 2005 at 11:36:14AM +0100, Christian Schmid wrote: > > >>Outgoing data. I am using sendfile() to send the file on a non-blocking >>socket but the call blocks for 100 ms per socket if I get over 3000 >>sockets. Thats causing the massive slowdown in sum. I first thought its a >>disk-issue but I tried with pure-cache data as well and it still blocks. > > > O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() > really isn't, as it still does the disk read (if any) synchronously. > > How are you making sure that you're sending "pure-cache data"? Because thats the first I excluded. I changed the program by replacing sendfile with a caching-routine plus syswrite. And it was really interesting that the syswrite was the one which needs most of the real-time, not the caching-routine. syswrite blocked 100 ms per socket. > > > --L > > From ahu@outpost.ds9a.nl Mon Feb 21 09:25:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 09:25:05 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LHOxhh010733 for ; Mon, 21 Feb 2005 09:25:00 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id EB6473FEA; Mon, 21 Feb 2005 18:24:58 +0100 (CET) Date: Mon, 21 Feb 2005 18:24:58 +0100 From: bert hubert To: Christian Schmid Cc: Lennert Buytenhek , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few Message-ID: <20050221172458.GA21715@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Christian Schmid , Lennert Buytenhek , Nivedita Singhvi , netdev@oss.sgi.com References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> <421A179C.1030505@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A179C.1030505@rapidforum.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 848 Lines: 21 On Mon, Feb 21, 2005 at 06:17:16PM +0100, Christian Schmid wrote: > Because thats the first I excluded. I changed the program by replacing > sendfile with a caching-routine plus syswrite. And it was really > interesting that the syswrite was the one which needs most of the > real-time, not the caching-routine. syswrite blocked 100 ms per socket. Do you poll/select for socket readiness before doing write() with EAGAIN? (shouldn't matter all that much, but could narrow down debugging) 100ms is a bit of an odd number - how big is your write (in bytes)? Do you have 3500 threads or processes, or one big one? What does 'id' say in vmstat 1 typically, both below and above 3500 sockets? Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From buytenh@wantstofly.org Mon Feb 21 09:29:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 09:29:48 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LHTiFl011276 for ; Mon, 21 Feb 2005 09:29:45 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 367CD2B0ED; Mon, 21 Feb 2005 18:29:43 +0100 (MET) Date: Mon, 21 Feb 2005 18:29:43 +0100 From: Lennert Buytenhek To: Christian Schmid Cc: bert hubert , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few Message-ID: <20050221172943.GA31814@xi.wantstofly.org> References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> <421A179C.1030505@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A179C.1030505@rapidforum.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 939 Lines: 23 On Mon, Feb 21, 2005 at 06:17:16PM +0100, Christian Schmid wrote: > >>Outgoing data. I am using sendfile() to send the file on a non-blocking > >>socket but the call blocks for 100 ms per socket if I get over 3000 > >>sockets. Thats causing the massive slowdown in sum. I first thought its a > >>disk-issue but I tried with pure-cache data as well and it still blocks. > > > >O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() > >really isn't, as it still does the disk read (if any) synchronously. > > > >How are you making sure that you're sending "pure-cache data"? > > Because thats the first I excluded. I changed the program by replacing > sendfile with a caching-routine plus syswrite. And it was really > interesting that the syswrite was the one which needs most of the > real-time, not the caching-routine. syswrite blocked 100 ms per socket. 'syswrite'. Is your application written in C or perl? --L From leonid.grossman@neterion.com Mon Feb 21 10:05:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 10:05:11 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LI55bM012521 for ; Mon, 21 Feb 2005 10:05:05 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1LI3hdG024015; Mon, 21 Feb 2005 13:03:43 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1LI3cDD009072; Mon, 21 Feb 2005 13:03:39 -0500 (EST) Message-Id: <200502211803.j1LI3cDD009072@guinness.s2io.com> From: "Leonid Grossman" To: , "'Leonid Grossman'" Cc: "'Andi Kleen'" , "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Mon, 21 Feb 2005 10:02:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUYOF5YFHYEWd5EQZKoacSrXHbwoQABaHjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <1109005880.1076.77.camel@jzny.localdomain> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1532 Lines: 43 > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Monday, February 21, 2005 9:11 AM > To: Leonid Grossman > Cc: 'Andi Kleen'; 'rick jones'; netdev@oss.sgi.com; 'Alex Aizman' > Subject: RE: Intel and TOE in the news > > On Mon, 2005-02-21 at 11:52, Leonid Grossman wrote: > > > > WRT to the burst of packets related to the same flow - we > are hoping > > to be able to collapse the burst into a single oversized frame and > > pass it to the stack, this way no or very minimal changes > to the stack will be needed. > > There is enough intelligence on the NIC to do that efficiently, we > > just need to try and see how well this works. > > Indeed, would be nice to see what you come up with. I think > there may be value in sending one huge chunk packet which > itself is actually a collection of several independet packets > when you have a huge amount of small packets. The benefit > being you amortize the cost of DMA setup. > But then you may need to be able to break them down in the > driver; is this what you are talking about? Pretty much. Actually the ASIC separates the headers so the driver doesn't need to break packets down. The driver just chains the payload (for several packets from a same-flow burst) and builds the header for this single oversized frame. Kind of inversed TSO, but on receive side. We are going to post an experimental driver code in 2-3 weeks, along with this "Large Receive Offload" algorithm, for review. Cheers, Leonid > > cheers, > jamal > > From webmaster@rapidforum.com Mon Feb 21 11:12:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 11:12:05 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LJC0nc014299 for ; Mon, 21 Feb 2005 11:12:01 -0800 Received: (qmail 13265 invoked by uid 1004); 21 Feb 2005 19:12:00 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 19:12:00 -0000 Message-ID: <421A3262.4080007@rapidforum.com> Date: Mon, 21 Feb 2005 20:11:30 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Lennert Buytenhek CC: bert hubert , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> <421A179C.1030505@rapidforum.com> <20050221172943.GA31814@xi.wantstofly.org> In-Reply-To: <20050221172943.GA31814@xi.wantstofly.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1201 Lines: 30 Lennert Buytenhek wrote: > On Mon, Feb 21, 2005 at 06:17:16PM +0100, Christian Schmid wrote: > > >>>>Outgoing data. I am using sendfile() to send the file on a non-blocking >>>>socket but the call blocks for 100 ms per socket if I get over 3000 >>>>sockets. Thats causing the massive slowdown in sum. I first thought its a >>>>disk-issue but I tried with pure-cache data as well and it still blocks. >>> >>>O_NONBLOCK send() is really nonblocking, but O_NONBLOCK sendfile() >>>really isn't, as it still does the disk read (if any) synchronously. >>> >>>How are you making sure that you're sending "pure-cache data"? >> >>Because thats the first I excluded. I changed the program by replacing >>sendfile with a caching-routine plus syswrite. And it was really >>interesting that the syswrite was the one which needs most of the >>real-time, not the caching-routine. syswrite blocked 100 ms per socket. > > > 'syswrite'. > > Is your application written in C or perl? Perl. But this is not the source because as stated in another mail, I tried with 6 processes when it slows down at 500 connections each and with 2 processes where it only starts to slowdown at 2000 processes each. Chris From webmaster@rapidforum.com Mon Feb 21 11:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 11:11:18 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LJB6P5014108 for ; Mon, 21 Feb 2005 11:11:07 -0800 Received: (qmail 13217 invoked by uid 1004); 21 Feb 2005 19:11:06 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 19:11:06 -0000 Message-ID: <421A322C.6020302@rapidforum.com> Date: Mon, 21 Feb 2005 20:10:36 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: bert hubert CC: Lennert Buytenhek , Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: many outgoing tcp sockets are slower than a few References: <421925DB.2060602@rapidforum.com> <42192AAF.8020609@us.ibm.com> <42192CD5.5090401@rapidforum.com> <20050221090121.GA7478@outpost.ds9a.nl> <4219B99E.1000603@rapidforum.com> <20050221120223.GA30348@xi.wantstofly.org> <421A179C.1030505@rapidforum.com> <20050221172458.GA21715@outpost.ds9a.nl> In-Reply-To: <20050221172458.GA21715@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1997 Lines: 39 bert hubert wrote: > On Mon, Feb 21, 2005 at 06:17:16PM +0100, Christian Schmid wrote: > > >>Because thats the first I excluded. I changed the program by replacing >>sendfile with a caching-routine plus syswrite. And it was really >>interesting that the syswrite was the one which needs most of the >>real-time, not the caching-routine. syswrite blocked 100 ms per socket. > > > Do you poll/select for socket readiness before doing write() with EAGAIN? > (shouldn't matter all that much, but could narrow down debugging) Yes. Using the IO::Poll in Perl. > 100ms is a bit of an odd number - how big is your write (in bytes)? Its an estimation. Its a non-blocking write with sendfile() so it writes around 90 KB if the buffer is set to 128 KB. It writes not the full because POLLOUT comes active before all is empty on the queue. > Do you have 3500 threads or processes, or one big one? Tried several types. 2 processes with 2000 connections each and 6 processes with 500 connections each. Both versions slow down if the system-wide socket-count goes over 3500. > What does 'id' say in vmstat 1 typically, both below and above 3500 sockets? (s02) [19:51:33] root:~# vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 2 0 8196 27192 7994020 0 0 2383 275 1540 650 16 19 41 24 0 3 0 12888 27172 7989144 0 0 36872 0 6542 2501 14 20 37 28 1 2 0 8004 27248 7993828 0 0 34988 448 6876 2270 13 19 38 31 0 2 0 17928 27280 7984208 0 0 30660 0 6571 2999 15 20 36 30 3 2 0 9480 27316 7991108 0 0 37168 0 6349 2476 16 22 33 29 2 1 0 9244 27360 7992492 0 0 37616 0 6397 2934 16 23 33 28 0 2 0 8988 27332 7991840 0 0 36628 0 6187 3010 17 21 34 28 3 1 0 9400 27484 7989648 0 0 35556 5708 6072 2696 18 28 27 27 From alex@neterion.com Mon Feb 21 11:34:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 11:35:01 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LJYs80015503 for ; Mon, 21 Feb 2005 11:34:56 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1LJY9dG024498; Mon, 21 Feb 2005 14:34:09 -0500 (EST) Received: from OFFICEONEATHOME ([10.16.16.162]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1LJY4DD026345; Mon, 21 Feb 2005 14:34:05 -0500 (EST) From: "Alex Aizman" To: "'Jeff Garzik'" , "'Andi Kleen'" , "'Leonid Grossman'" , "'rick jones'" , Subject: RE: Intel and TOE in the news Date: Mon, 21 Feb 2005 11:34:08 -0800 Message-ID: <000001c5184c$5599c890$0100a8c0@OFFICEONEATHOME> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <42194972.8060303@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 1387 Lines: 40 > > Alternative: wait until Xframe II adapter w/MSI-X.. > > How does that help with MSI? Does not help with MSI, helps to scale. Btw, there's one alternative to MSI/MSI-X idea that in theory should help to scale with CPUs. In a month or so I might get time to try it out. > The infiniband Linux driver is already using multi-MSI. You > are behind the times :) That's just great. Where, which kernel? 2.6.11-rc4 MSI-HOWTO still says "Due to the non-contiguous fashion in vector assignment of the existing Linux kernel, this version does not support multiple messages regardless of a device function is capable of supporting more than one vector." 2.6.11-rc4 MTHCA driver still does request_irq() just once for MSI (note: MSI, not MSI-X). > Despite Andis assertion that theres value in amortizing the > locks, the benefits are highly missing on a generic level > unfortunately. Locking overhead is like the 50th item on > things you have to worry about > - so i wouldnt even start worrying about this. That's probably true. Not 50th, 5th but still. > Yes when queue length/batch increases you're risking to load the L2 > twice for the same skb. Which is the most expensive operation.... > Forwarding profiles show most functions where cache misses occur. I wonder if alloc_skb_from_cache() will help to relieve the pressure on memory at multi-Gbps receives. Alex From webmaster@rapidforum.com Mon Feb 21 12:04:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:04:46 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LK4f7p016384 for ; Mon, 21 Feb 2005 12:04:42 -0800 Received: (qmail 17571 invoked by uid 1004); 21 Feb 2005 20:04:39 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 20:04:39 -0000 Message-ID: <421A3EB8.4050607@rapidforum.com> Date: Mon, 21 Feb 2005 21:04:08 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: ARGH MORE BUGS!!! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1006 Lines: 17 Hi. Another bug hit me today HARD! I have been experiencing with lowering the socket-buffer to see if the behaviour of a slowdown reappears at the same position. Result: With a 128 KB send-buffer, the slowdown appears at around 3000 sockets. With 64 KB, it didnt appear up to 4500 sockets where a small slow-down appeared but I think this was a disk-issue. So its definetly something with TCP-memory. But now I hit another BUG: After I have managed to create 4500 sockets, 10 minutes later an interesting phenomenon appeared: It locks for 5 seconds every 60 seconds. I first thought this was something in my program but I can do what I want, I wasn't able to fix this. Even a restart of my program didnt help. It even appears with 400 connections. Then I despairedly just restarted the system and: It was gone. So what is THIS? Sorry if I am a bit angry. I know you are doing a really good job. Maybe I can donate some money somewhere but PLEASE!!!!! help me fix this bugs.... Thank you. Chris From pekkas@netcore.fi Mon Feb 21 12:09:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:09:58 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LK9oX1016949 for ; Mon, 21 Feb 2005 12:09:50 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1LK9fs02126; Mon, 21 Feb 2005 22:09:41 +0200 Date: Mon, 21 Feb 2005 22:09:41 +0200 (EET) From: Pekka Savola To: radvd-announce-l@litech.org cc: netdev@oss.sgi.com Subject: Radvd 0.7.3 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 666 Lines: 22 Hi, After 2.5 years of waiting and silent bugfixing, a new radvd maintenance version is out: 0.7.3. :) Get it at: http://www.litech.org/radvd/ The most notable changes are: - A large number of fixes and cleanups - Support Router Preferences and More Specific routes - Add "IgnoreIfMissing" interface flag, to be used with interfaces which may become available only later on Please report issues, if any, to the radvd-devel-l@litech.org mailing list. Thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mcmanus@ducksong.com Mon Feb 21 12:12:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:12:37 -0800 (PST) Received: from datapower.ducksong.com (ip67-93-141-190.z141-93-67.customer.algx.net [67.93.141.190]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKCWRq017463 for ; Mon, 21 Feb 2005 12:12:33 -0800 Received: from [127.0.0.1] (mcmanus.datapower.com [127.0.0.1]) by datapower.ducksong.com (8.12.10/8.12.10) with ESMTP id j1LKCKZL025753; Mon, 21 Feb 2005 15:12:20 -0500 Subject: Re: Intel and TOE in the news From: patrick mcmanus To: hadi@cyberus.ca Cc: "netdev@oss.sgi.com" In-Reply-To: <1109005385.1074.68.camel@jzny.localdomain> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> <20050221164006.GY31837@postel.suug.ch> <1109005385.1074.68.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1109016740.25476.2.camel@mcmanus.datapower.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 21 Feb 2005 15:12:20 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcmanus@ducksong.com Precedence: bulk X-list: netdev Content-Length: 249 Lines: 11 On Mon, 2005-02-21 at 12:03, jamal wrote: > after the BSD folks claimed to be > doing 1Mpps forwarding (only to find out they used CSA later). ^^^^^^^^^^^^^^^^^^^^^^^^ I can't grok this. Can you elucidate? Thanks, Pat From garzik@havoc.gtf.org Mon Feb 21 12:17:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:17:09 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKH30N017999 for ; Mon, 21 Feb 2005 12:17:05 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 24BDDA879D; Mon, 21 Feb 2005 15:12:50 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18085-07; Mon, 21 Feb 2005 15:12:48 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 0A4DDA8790; Mon, 21 Feb 2005 15:12:46 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 60DFC1C0A83F; Mon, 21 Feb 2005 15:16:55 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j1LKGsO4021493; Mon, 21 Feb 2005 15:16:54 -0500 Date: Mon, 21 Feb 2005 15:16:54 -0500 From: Jeff Garzik To: Pekka Savola Cc: radvd-announce-l@litech.org, netdev@oss.sgi.com Subject: Re: Radvd 0.7.3 released Message-ID: <20050221201654.GA16436@havoc.gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 1906 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: 373 Lines: 15 On Mon, Feb 21, 2005 at 10:09:41PM +0200, Pekka Savola wrote: > Hi, > > After 2.5 years of waiting and silent bugfixing, a new radvd > maintenance version is out: 0.7.3. :) Should we read anything into the version number? I've been using radvd in production for a while... what is left before version 1.0? Should I continue to trust it, since it is < 1.0 ? Jeff From matthias.christian@tiscali.de Mon Feb 21 12:19:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:19:24 -0800 (PST) Received: from webmail.tiscali.de (relay1.tiscali.de [62.26.116.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKJJOK021874 for ; Mon, 21 Feb 2005 12:19:20 -0800 Received: from [169.254.101.1] (213.54.102.12) by webmail.tiscali.de (7.0.036.1) (authenticated as matthias.christian@tiscali.de) id 41B8BE3500373EC4; Mon, 21 Feb 2005 21:19:17 +0100 Message-ID: <421A4244.9090908@tiscali.de> Date: Mon, 21 Feb 2005 21:19:16 +0100 From: Matthias-Christian Ott User-Agent: Mozilla Thunderbird 1.0 (X11/20050108) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> In-Reply-To: <421A3EB8.4050607@rapidforum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthias.christian@tiscali.de Precedence: bulk X-list: netdev Content-Length: 1441 Lines: 34 Christian Schmid wrote: > Hi. > > Another bug hit me today HARD! I have been experiencing with lowering > the socket-buffer to see if the behaviour of a slowdown reappears at > the same position. Result: With a 128 KB send-buffer, the slowdown > appears at around 3000 sockets. With 64 KB, it didnt appear up to 4500 > sockets where a small slow-down appeared but I think this was a > disk-issue. So its definetly something with TCP-memory. > > But now I hit another BUG: After I have managed to create 4500 > sockets, 10 minutes later an interesting phenomenon appeared: It locks > for 5 seconds every 60 seconds. I first thought this was something in > my program but I can do what I want, I wasn't able to fix this. Even a > restart of my program didnt help. It even appears with 400 > connections. Then I despairedly just restarted the system and: It was > gone. So what is THIS? > > Sorry if I am a bit angry. I know you are doing a really good job. > Maybe I can donate some money somewhere but PLEASE!!!!! help me fix > this bugs.... Thank you. > > Chris > > Hi! I'm not a Perl Coder or Socket Specialist, but did try an implementation of your program in C (maybe it's a perl "bug"?)? And as mentioned in the other Thread, try to use send () instead of sendfile (). Anyway it's strange. Try to contact some of the Maintainers and Developers of this part of the IP v4 implementation in Linux. Matthias-Christian Ott From pekkas@netcore.fi Mon Feb 21 12:20:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:20:41 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKKaqY022239 for ; Mon, 21 Feb 2005 12:20:37 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1LKKPl02520; Mon, 21 Feb 2005 22:20:26 +0200 Date: Mon, 21 Feb 2005 22:20:25 +0200 (EET) From: Pekka Savola To: Jeff Garzik cc: radvd-devel-l@litech.org, netdev@oss.sgi.com Subject: Re: Radvd 0.7.3 released In-Reply-To: <20050221201654.GA16436@havoc.gtf.org> Message-ID: References: <20050221201654.GA16436@havoc.gtf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1003 Lines: 26 On Mon, 21 Feb 2005, Jeff Garzik wrote: > On Mon, Feb 21, 2005 at 10:09:41PM +0200, Pekka Savola wrote: >> Hi, >> >> After 2.5 years of waiting and silent bugfixing, a new radvd >> maintenance version is out: 0.7.3. :) > > Should we read anything into the version number? Not much.. old habits maybe, because the earlier versions had low numbers and we didn't start bumping them up enough :) > I've been using radvd in production for a while... what is left before > version 1.0? Should I continue to trust it, since it is < 1.0 ? Folks have been running it in a stable manner for 3-4 years, so it should be close to "1.0 grade". When an internet-draft (more specific routes & router preferences) becomes RFC and there will be official codepoints, the version number probably gets bumped up a bit more. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From webmaster@rapidforum.com Mon Feb 21 12:26:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:26:10 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LKQ4VW022990 for ; Mon, 21 Feb 2005 12:26:05 -0800 Received: (qmail 19070 invoked by uid 1004); 21 Feb 2005 20:26:04 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 20:26:04 -0000 Message-ID: <421A43BE.6080604@rapidforum.com> Date: Mon, 21 Feb 2005 21:25:34 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Matthias-Christian Ott CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <421A4244.9090908@tiscali.de> In-Reply-To: <421A4244.9090908@tiscali.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1599 Lines: 39 netdev@oss.sgi.com has been found in MAINTAINERS in the ipv4/ipv6 section ;) Matthias-Christian Ott wrote: > Christian Schmid wrote: > >> Hi. >> >> Another bug hit me today HARD! I have been experiencing with lowering >> the socket-buffer to see if the behaviour of a slowdown reappears at >> the same position. Result: With a 128 KB send-buffer, the slowdown >> appears at around 3000 sockets. With 64 KB, it didnt appear up to 4500 >> sockets where a small slow-down appeared but I think this was a >> disk-issue. So its definetly something with TCP-memory. >> >> But now I hit another BUG: After I have managed to create 4500 >> sockets, 10 minutes later an interesting phenomenon appeared: It locks >> for 5 seconds every 60 seconds. I first thought this was something in >> my program but I can do what I want, I wasn't able to fix this. Even a >> restart of my program didnt help. It even appears with 400 >> connections. Then I despairedly just restarted the system and: It was >> gone. So what is THIS? >> >> Sorry if I am a bit angry. I know you are doing a really good job. >> Maybe I can donate some money somewhere but PLEASE!!!!! help me fix >> this bugs.... Thank you. >> >> Chris >> >> > Hi! > I'm not a Perl Coder or Socket Specialist, but did try an implementation > of your program in C (maybe it's a perl "bug"?)? And as mentioned in the > other Thread, try to use send () instead of sendfile (). Anyway it's > strange. Try to contact some of the Maintainers and Developers of this > part of the IP v4 implementation in Linux. > > Matthias-Christian Ott > > From romieu@fr.zoreil.com Mon Feb 21 12:31:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:31:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKVeQI023561 for ; Mon, 21 Feb 2005 12:31:41 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LKSxjj027174; Mon, 21 Feb 2005 21:28:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LKSs9S027173; Mon, 21 Feb 2005 21:28:54 +0100 Date: Mon, 21 Feb 2005 21:28:54 +0100 From: Francois Romieu To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! Message-ID: <20050221202854.GA26248@electric-eye.fr.zoreil.com> References: <421A3EB8.4050607@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A3EB8.4050607@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1910 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: 587 Lines: 13 Christian Schmid : [...] > But now I hit another BUG: After I have managed to create 4500 sockets, 10 > minutes later an interesting phenomenon appeared: It locks for 5 seconds > every 60 seconds. I first thought this was something in my program but I > can do what I want, I wasn't able to fix this. Even a restart of my program > didnt help. It even appears with 400 connections. Then I despairedly just > restarted the system and: It was gone. So what is THIS? What about monitoring /proc/slabinfo and vmstat output (with heavy renicing) ? -- Ueimor From webmaster@rapidforum.com Mon Feb 21 12:34:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:34:56 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LKYnDb024085 for ; Mon, 21 Feb 2005 12:34:50 -0800 Received: (qmail 19721 invoked by uid 1004); 21 Feb 2005 20:34:49 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 20:34:49 -0000 Message-ID: <421A45CA.80001@rapidforum.com> Date: Mon, 21 Feb 2005 21:34:18 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221202854.GA26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 14297 Lines: 270 (s02) [21:05:13] root:~# cat /proc/slabinfo slabinfo - version: 2.1 # name : tunables : slabdata ip_fib_alias 14 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 ip_fib_hash 14 119 32 119 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_inode_cache 0 0 512 7 1 : tunables 54 27 8 : slabdata 0 0 0 unix_sock 15 28 512 7 1 : tunables 54 27 8 : slabdata 4 4 0 ipt_hashlimit 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 tcp_tw_bucket 3474 4464 128 31 1 : tunables 120 60 8 : slabdata 144 144 480 tcp_bind_bucket 11 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 tcp_open_request 310 427 64 61 1 : tunables 120 60 8 : slabdata 7 7 0 inet_peer_cache 430 488 64 61 1 : tunables 120 60 8 : slabdata 8 8 0 secpath_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 ip_dst_cache 10434 25410 256 15 1 : tunables 120 60 8 : slabdata 1694 1694 0 arp_cache 3 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 raw_sock 5 7 512 7 1 : tunables 54 27 8 : slabdata 1 1 0 udp_sock 0 0 512 7 1 : tunables 54 27 8 : slabdata 0 0 0 tcp_sock 3218 3374 1152 7 2 : tunables 24 12 8 : slabdata 482 482 12 flow_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 dm-snapshot-in 128 140 56 70 1 : tunables 120 60 8 : slabdata 2 2 0 dm-snapshot-ex 0 0 24 156 1 : tunables 120 60 8 : slabdata 0 0 0 dm-crypt_io 0 0 76 52 1 : tunables 120 60 8 : slabdata 0 0 0 dm_tio 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 dm_io 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 scsi_cmd_cache 261 390 384 10 1 : tunables 54 27 8 : slabdata 39 39 184 cfq_ioc_pool 0 0 24 156 1 : tunables 120 60 8 : slabdata 0 0 0 cfq_pool 0 0 104 38 1 : tunables 120 60 8 : slabdata 0 0 0 crq_pool 0 0 56 70 1 : tunables 120 60 8 : slabdata 0 0 0 deadline_drq 0 0 52 75 1 : tunables 120 60 8 : slabdata 0 0 0 as_arq 665 793 64 61 1 : tunables 120 60 8 : slabdata 13 13 420 mqueue_inode_cache 1 7 512 7 1 : tunables 54 27 8 : slabdata 1 1 0 udf_inode_cache 0 0 368 11 1 : tunables 54 27 8 : slabdata 0 0 0 nfs_write_data 36 42 512 7 1 : tunables 54 27 8 : slabdata 6 6 0 nfs_read_data 32 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 nfs_inode_cache 0 0 572 7 1 : tunables 54 27 8 : slabdata 0 0 0 nfs_page 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 isofs_inode_cache 0 0 340 11 1 : tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache 0 0 372 10 1 : tunables 54 27 8 : slabdata 0 0 0 fat_cache 0 0 20 185 1 : tunables 120 60 8 : slabdata 0 0 0 ext2_inode_cache 2687 4446 424 9 1 : tunables 54 27 8 : slabdata 494 494 10 journal_handle 0 0 20 185 1 : tunables 120 60 8 : slabdata 0 0 0 journal_head 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_table 0 0 12 290 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_record 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache 0 0 500 8 1 : tunables 54 27 8 : slabdata 0 0 0 ext3_xattr 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 reiser_inode_cache 483 840 392 10 1 : tunables 54 27 8 : slabdata 84 84 0 dnotify_cache 0 0 20 185 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 36 107 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 kioctx 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 kiocb 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 fasync_cache 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache 85 117 408 9 1 : tunables 54 27 8 : slabdata 13 13 0 posix_timers_cache 0 0 104 38 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 5 61 64 61 1 : tunables 120 60 8 : slabdata 1 1 0 sgpool-128 52 57 2560 3 2 : tunables 24 12 8 : slabdata 19 19 0 sgpool-64 35 42 1280 3 1 : tunables 24 12 8 : slabdata 14 14 0 sgpool-32 292 294 640 6 1 : tunables 54 27 8 : slabdata 49 49 173 sgpool-16 247 280 384 10 1 : tunables 54 27 8 : slabdata 28 28 114 sgpool-8 321 345 256 15 1 : tunables 120 60 8 : slabdata 23 23 104 blkdev_ioc 71 135 28 135 1 : tunables 120 60 8 : slabdata 1 1 0 blkdev_queue 29 40 372 10 1 : tunables 54 27 8 : slabdata 4 4 0 blkdev_requests 662 783 148 27 1 : tunables 120 60 8 : slabdata 29 29 420 biovec-(256) 256 256 3072 2 2 : tunables 24 12 8 : slabdata 128 128 0 biovec-128 256 260 1536 5 2 : tunables 24 12 8 : slabdata 52 52 0 biovec-64 503 580 768 5 1 : tunables 54 27 8 : slabdata 116 116 158 biovec-16 478 495 256 15 1 : tunables 120 60 8 : slabdata 33 33 104 biovec-4 402 488 64 61 1 : tunables 120 60 8 : slabdata 8 8 44 biovec-1 857 4068 16 226 1 : tunables 120 60 8 : slabdata 18 18 404 bio 791 1829 128 31 1 : tunables 120 60 8 : slabdata 59 59 300 file_lock_cache 20 43 92 43 1 : tunables 120 60 8 : slabdata 1 1 0 sock_inode_cache 3190 3360 384 10 1 : tunables 54 27 8 : slabdata 336 336 54 skbuff_head_cache 98736 109950 256 15 1 : tunables 120 60 8 : slabdata 7330 7330 420 sock 7 20 384 10 1 : tunables 54 27 8 : slabdata 2 2 0 proc_inode_cache 19 48 328 12 1 : tunables 54 27 8 : slabdata 4 4 0 sigqueue 149 216 148 27 1 : tunables 120 60 8 : slabdata 8 8 0 radix_tree_node 55690 56182 276 14 1 : tunables 54 27 8 : slabdata 4013 4013 27 bdev_cache 33 42 512 7 1 : tunables 54 27 8 : slabdata 6 6 0 mnt_cache 20 31 128 31 1 : tunables 120 60 8 : slabdata 1 1 0 inode_cache 1099 1104 312 12 1 : tunables 54 27 8 : slabdata 92 92 0 dentry_cache 7375 10388 140 28 1 : tunables 120 60 8 : slabdata 371 371 0 filp 6532 6945 256 15 1 : tunables 120 60 8 : slabdata 463 463 0 names_cache 40 40 4096 1 1 : tunables 24 12 8 : slabdata 40 40 12 idr_layer_cache 77 116 136 29 1 : tunables 120 60 8 : slabdata 4 4 0 buffer_head 68550 68550 52 75 1 : tunables 120 60 8 : slabdata 914 914 0 mm_struct 61 72 640 6 1 : tunables 54 27 8 : slabdata 12 12 0 vm_area_struct 1980 2745 88 45 1 : tunables 120 60 8 : slabdata 61 61 120 fs_cache 46 183 64 61 1 : tunables 120 60 8 : slabdata 3 3 0 files_cache 46 63 512 7 1 : tunables 54 27 8 : slabdata 9 9 0 signal_cache 115 150 256 15 1 : tunables 120 60 8 : slabdata 10 10 0 sighand_cache 90 95 1408 5 2 : tunables 24 12 8 : slabdata 19 19 0 task_struct 106 108 1280 3 1 : tunables 24 12 8 : slabdata 36 36 0 anon_vma 499 870 12 290 1 : tunables 120 60 8 : slabdata 3 3 0 pgd 90 238 32 119 1 : tunables 120 60 8 : slabdata 2 2 0 pmd 62 62 4096 1 1 : tunables 24 12 8 : slabdata 62 62 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 8 8 8192 1 2 : tunables 8 4 0 : slabdata 8 8 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 2509 2509 4096 1 1 : tunables 24 12 8 : slabdata 2509 2509 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 290 326 2048 2 1 : tunables 24 12 8 : slabdata 160 163 60 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 308 324 1024 4 1 : tunables 54 27 8 : slabdata 81 81 27 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 95390 97064 512 8 1 : tunables 54 27 8 : slabdata 12133 12133 216 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 272 300 256 15 1 : tunables 120 60 8 : slabdata 20 20 0 size-128(DMA) 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 1601 1674 128 31 1 : tunables 120 60 8 : slabdata 54 54 0 size-64(DMA) 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 18303 23058 64 61 1 : tunables 120 60 8 : slabdata 378 378 60 size-32(DMA) 0 0 32 119 1 : tunables 120 60 8 : slabdata 0 0 0 size-32 7614 10591 32 119 1 : tunables 120 60 8 : slabdata 89 89 0 kmem_cache 135 135 256 15 1 : tunables 120 60 8 : slabdata 9 9 0 Francois Romieu wrote: > Christian Schmid : > [...] > >>But now I hit another BUG: After I have managed to create 4500 sockets, 10 >>minutes later an interesting phenomenon appeared: It locks for 5 seconds >>every 60 seconds. I first thought this was something in my program but I >>can do what I want, I wasn't able to fix this. Even a restart of my program >>didnt help. It even appears with 400 connections. Then I despairedly just >>restarted the system and: It was gone. So what is THIS? > > > What about monitoring /proc/slabinfo and vmstat output (with heavy renicing) ? > > -- > Ueimor > > From jgarzik@pobox.com Mon Feb 21 12:35:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:35:11 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKZ5Y0024177 for ; Mon, 21 Feb 2005 12:35:05 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D3KGk-0005w2-M7; Mon, 21 Feb 2005 20:35:02 +0000 Message-ID: <421A45DD.3020805@pobox.com> Date: Mon, 21 Feb 2005 15:34:37 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Aizman CC: "'Andi Kleen'" , "'Leonid Grossman'" , "'rick jones'" , netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <000001c5184c$5599c890$0100a8c0@OFFICEONEATHOME> In-Reply-To: <000001c5184c$5599c890$0100a8c0@OFFICEONEATHOME> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1912 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: 295 Lines: 13 Alex Aizman wrote: > 2.6.11-rc4 MTHCA driver still does request_irq() just once for MSI > (note: MSI, not MSI-X). I doubt that will change. request_irq() is passed a "cookie" that enables your interrupt handler. This cookie can be associated with more than one interrupt vector. Jeff From romieu@fr.zoreil.com Mon Feb 21 12:59:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 12:59:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LKxehx025444 for ; Mon, 21 Feb 2005 12:59:41 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LKuGfC027582; Mon, 21 Feb 2005 21:56:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LKu638027580; Mon, 21 Feb 2005 21:56:07 +0100 Date: Mon, 21 Feb 2005 21:56:06 +0100 From: Francois Romieu To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! Message-ID: <20050221205606.GB26248@electric-eye.fr.zoreil.com> References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A45CA.80001@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1913 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: 428 Lines: 22 Christian Schmid : [...] Let's calm down, please. # cat>/tmp/momo< /tmp/\$i i=$[ $i + 1 ] sleep 1 done EOD # nice -n -19 vmstat 1 > /tmp/v & nice -n -19 sh /tmp/momo Wait a few minutes or more until the 5s pauses happen several times and post the result somewhere. I doubt I'll fix it but it should give nifty graphics. -- Ueimor From hadi@cyberus.ca Mon Feb 21 13:12:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 13:12:57 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LLCpKW026114 for ; Mon, 21 Feb 2005 13:12:52 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D3KrI-0002N1-F7 for netdev@oss.sgi.com; Mon, 21 Feb 2005 16:12:48 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D3KrG-0007mJ-GQ; Mon, 21 Feb 2005 16:12:46 -0500 Subject: Re: Intel and TOE in the news From: jamal Reply-To: hadi@cyberus.ca To: patrick mcmanus Cc: "netdev@oss.sgi.com" In-Reply-To: <1109016740.25476.2.camel@mcmanus.datapower.com> References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> <20050221164006.GY31837@postel.suug.ch> <1109005385.1074.68.camel@jzny.localdomain> <1109016740.25476.2.camel@mcmanus.datapower.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109020362.1077.134.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2005 16:12:42 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1914 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: 766 Lines: 23 On Mon, 2005-02-21 at 15:12, patrick mcmanus wrote: > On Mon, 2005-02-21 at 12:03, jamal wrote: > > after the BSD folks claimed to be > > doing 1Mpps forwarding (only to find out they used CSA later). > ^^^^^^^^^^^^^^^^^^^^^^^^ > > I can't grok this. Can you elucidate? > Credit should go to Harald Welte for pointing this out to me a while back. CSA is essentially a direct link to the Northbridge System Controller (or MCH); there are some speacilized motherboards that have this feature. So imagine a e1000 with no PCI-X bridge directly connected to the MCH. The funny thing is it was supposed to be a cost-reduction concept (no more PCI-X brifge). Refer to my earlier comment about intel and its chipset division. cheers, jamal From webmaster@rapidforum.com Mon Feb 21 13:18:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 13:18:24 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LLIHBg026678 for ; Mon, 21 Feb 2005 13:18:18 -0800 Received: (qmail 23178 invoked by uid 1004); 21 Feb 2005 21:18:16 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 21:18:16 -0000 Message-ID: <421A4FFA.7090003@rapidforum.com> Date: Mon, 21 Feb 2005 22:17:46 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221205606.GB26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 808 Lines: 32 Its attached, since these are several files. your script didnt work. I used this one: # nice -n -19 vmstat 1 > /tmp/v & nice -n -19 perl -e 'for(1..1000){sleep(1);system("cat /proc/slabinfo > /tmp/sl$_")}' I started it after one break-cyclus and stopped it immedately after the next break-cyclus ended. Francois Romieu wrote: > Christian Schmid : > [...] > > Let's calm down, please. > > # cat>/tmp/momo< i=0 > while : ; do > cat /proc/slabinfo > /tmp/\$i > i=$[ $i + 1 ] > sleep 1 > done > EOD > # nice -n -19 vmstat 1 > /tmp/v & nice -n -19 sh /tmp/momo > > Wait a few minutes or more until the 5s pauses happen several times > and post the result somewhere. > > I doubt I'll fix it but it should give nifty graphics. > > -- > Ueimor > > From webmaster@rapidforum.com Mon Feb 21 13:19:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 13:19:06 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LLIwjf026985 for ; Mon, 21 Feb 2005 13:18:58 -0800 Received: (qmail 23317 invoked by uid 1004); 21 Feb 2005 21:18:57 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 21:18:57 -0000 Message-ID: <421A5023.3000708@rapidforum.com> Date: Mon, 21 Feb 2005 22:18:27 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221205606.GB26248@electric-eye.fr.zoreil.com> Content-Type: multipart/mixed; boundary="------------010504000402070106040404" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 32585 Lines: 478 This is a multi-part message in MIME format. --------------010504000402070106040404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OOPS forgot the file.... *grin* Its attached, since these are several files. your script didnt work. I used this one: # nice -n -19 vmstat 1 > /tmp/v & nice -n -19 perl -e 'for(1..1000){sleep(1);system("cat /proc/slabinfo > /tmp/sl$_")}' I started it after one break-cyclus and stopped it immedately after the next break-cyclus ended. Francois Romieu wrote: > Christian Schmid : > [...] > > Let's calm down, please. > > # cat>/tmp/momo< i=0 > while : ; do > cat /proc/slabinfo > /tmp/\$i > i=$[ $i + 1 ] > sleep 1 > done > EOD > # nice -n -19 vmstat 1 > /tmp/v & nice -n -19 sh /tmp/momo > > Wait a few minutes or more until the 5s pauses happen several times > and post the result somewhere. > > I doubt I'll fix it but it should give nifty graphics. > > -- > Ueimor > > --------------010504000402070106040404 Content-Type: application/x-compressed; name="log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="log.tgz" H4sIALdPGkIAA+3d3ZKkOJom4Diuq5DZnswe1C76BcbGxmzN9nSvIS0qM7Irp/KvM7Kqu+fq V9InAnCHCISEcIdXNlOq6vDgc4EQktAT+vztb//7YeNUVaqqtba5T5e5/3deicooVRtj/3de SWUemN76i7n05/PPxx+MPfz49u3na5976+d3mj7b6//XxjHs9XTXdub6c8G57K+/NO7zWqoH Vm38vXw6+fX//uPb+2f2a5++PH359uNf/X+7nz3/4/E7/duvv376Fv7X5389/3z6Ev7n99// dNkvzJ7K3xhjz//4/sFmH388Pdnstz8/fmTs/eP7391/PX9y//jG3A8++X+6f//01f2r/S5/ PrPnf7FPH9g/Hn9hkrn/c6my/99KYTOhq6phdauVbpruR/4fteH2n9L+lGvp/gdTtYwbxlum BBPyFyYujieNP15T0fHsZ/vjyUY0KnzW6Nb+qxRCuePZbyGVjfOL++jgeHXjfkFobj9jj1fb Gj06Xvi+/njcHU8LznjN7D+l9Mez318MjtfW9r+EapQvrxFqdDxtWv9h0TAjuSuasEd1x5P2 S9iv6M8ffzkeV6py38/eZe54qhFSjL5fq17KKxp3PNnYk9cwYU9ebf/Ln7/R92vc9VCt8efP HX94vFa5y6Xc/6obeyXsl2ord/JE6w/Z+u83OF5TuxNkj2dPoz2ekGZ4fe3Fqs3L93OhRGM/ 776fPX984no0Rgt/fY0/ntR8VN5a1yJ8Vrf++nIj/fGU+4rhevTnTwmujT9/7nrYa63lqL7Y 01V1x+NS209ydzF8ZRGu1lyU156w1l9f2br6UhlZj45n//vl+2l35Xhrj2rPnL1stsjC+PL2 xxO1q3j2eMb+Xt1K24wOj2fjKHeuWvshI4WrCby250/4S2Js8Xx5+/PHZVWH8rrrq5QZHU+1 nP7b/jodTyol/cGUq5OiuTgeaw19v4bqS2X/bXw96Hy6+syFOzOmqf39Zots/6l9/euvR3d9 la2t/vpe3G+65i/1Rdbu1Nd1ZZuG7n7jl/WlFVRe48urpRiVV9r7+eX+FbVviWrZ1T/tr8fo /rDnT/j6bHx5XfW5qH++/NxWYiN048tL96/yl7j230/19c9WF3//Gl9feK3H94ei+m1sVTFK uPK2yrZ/KlQZeXl9XR32928d2j/7NB4dzx0plLeS7ngNp/bKFbY73uD+bTndv1T/tGiacftn +vbU9ghdSy3r7vyJ7v4dtgdtuL61b0+lEqPjtVx195ttD9z95k5MaE/peOP2qhV0v7l2030/ d12G348Prq9/0ihd+frHw/m78aflxd3Bqba0dHcoPj57lXB3h212XG3xz4XB3TFVW9q6otaZ 09nT49aqrlV/9oyvzZUa3L3msrY0VXc8Q7VvVJuFfd691BbpP1nbyxa+X+PvjvHdprXy5W2k O54yvB3dbTrczf54ja99Fd1tlb97m8vaYh+PvjXQVPvsw2xc+xrxUl57a7vvF3oHvDue/ajp v18VanMdWr92VPuE4r7xsX0ce1+6u5fXLmDrb5DG3vxX58/fTvZ42n8/wUe9IfswcHcHt6eR 2Q628MdW9narfJlrpszV47Lxl001dIGVGD/OG0EX3DWO3LU09njSNS+2e2XvY9ecjiuMvRD+ Jmroca7HX9A+LMzL7dtU2nU37Amix5HrXqnL7lpjqHkO3QPbrxgeT8nw+PDH8yVpbSfQNX/U 3F91XxrfabLHo+6V7aiMLrAU7vtK35kT9Diy589eEPf9Wn+8i8dlS819SxekkuPHRyv78ra+ ubKjXftb7niq6h7nfXPPje9Pucel767VctycUu+Ljmfq1n3VUF7hvp873qj7J7Wm7qTyzZ99 4pjLCt3dcJqqlruT3MXVvkcpLxoYbmusP57WwncnQ/enux686h+/xj0upW3AuxuEus/j7qkx oXtFj0tdjxose7ZsOHtTC/Xy+Kjb0MC47qm6bBBq34K44yl/PDXqbqjKt/H0/aR7vElXq6n7 LKuu+ze4vjx0xxV1J914dXi8mvsGQtlvpNvGDywa7r+ff2JePS65Cveb8g2gqisxeb/5x6+/ PzS1Vu5iNNfDBfvtqUEQVP94U4+797q/Hpy6G+H8Sd/daC66u4K7/qLrNtL15RcNvvLDhdZd FWOrgqsvrj2gBt/1AG/9cTnubLTUJVaSOi9Sjq9G2w3elOtsGDfYkm0YHNnBhxvMXDx+w+BI NmHwMbo7pG5l17k3lW9datv7Csez51BdtAZ2cES12T2r3fGMGHeepe4HM77hqtzgt+1ag6vO UBNaA9lQ6ycvugdV1T/OfWulK8768Uzra0s1uHsFtfaSBgsXnTUupXsc27bCDj6MP5Wa6rE9 pHaDocvjufaXjqfoeBeDfVvzwmdr3mj3b/b82PvMNtDG/pNfHU80rx/v5Z+1Hbf5K03HszeT /Ul1eTwtaDDdHU+PWvvhP+0oxZ9326i449mP84nj1Xpc3vnj2ZrkWyVlXjteW1P3Rfmn+dzx 7DPNXgh60NfaH89+XFyfP2HvbjVoraQeDWb893H/sNHseML/yFTd8WT3/YZPc02DQe1be1tr xt01bvrulatStr12t5kfb7l/aS7uD9uCU/0zvvsn7eN3NPitG9/6uz6dvfW4/4XKPzr8+ON6 sNpQHyd0r4ztXo1ae91/v9p2TJhrXyvfu9K+d0CD1eH9G4YUNPi1I+FR66xqd/twN5fC6pq7 1l65p4f2D2Dpn26j72fbkzBY9e2BlPWoNyTb1t8f0v2U+6eRca2z8E2Ctr2lq8FRFSYPaHKt 4aPJMCUGT0v7KHXldd1xmhxqXe9v76lMpBXJzf8/f+abxnh9/t8+Z+v+/Y92n+OVHYo+YP6/ QHr+/Pjbp68fv7Ff2V9PP54/ffv670z8L/7L/2BfH788sUH6j8f3Pz/99fTu22//9fyf7D++ /vml+1eXffrvJ/q37/Yo9pj2P74//u3p+eU//539/PPr42+fn57Zf/z2+PP97++//fn1p/3Y 509fPrn8+ffHH08fPtoo3364j7tf+/D48/ElsPsfusjdv9MvPf71+Onzf/7y6fu7j59+e/f4 +dPjc/+9uW+DhaDegm/j6N/58DvZlrGiR5Zrqofh6ddGWdWF+v3x+Xd2GcqOE/x/uf5d+PeU UD++v3/n+rj2RA4vR9NntiPi/0tch2K+E0bT3teh1CijUD8fn/8YBepCcd/HokkU+vfUUn36 +u3D07uu504/GGRhtr6eKJV7/rhh1WSoapz98ufXT/989/zt/R+jQlER3HuhhFBmlLlq8dPX CV+n+1ijb+QH3f5FVdQJvCzVz/ff3/38h60Z7/946kJJP83jpreogvseiowMZdvhQWY7VT6U bSQ+jIMxqg957ysX6tv3p6/vfjz9/c+nZ4olua+BocO+9gQ2o8xeq69PP999f3r6MayBshIb hHp+ev/98efv46o+vqTrrtV1tfjnxx9f3n14/nkRa/ixtbfwZSjbBl4G4lq7IgjdtOtD8drX o5D5UI8/vl+ePH/4EDSlVFcN0+M/rhuLUNlDC7G2tbgM9eeH71OhtmgD3X11GcoONFuf+daC h5dTNZ3YpQ8R1TaDzDYDv3z8/O0fExdri8r+4cuvz18fvz///u3nrzTF83Jw1r0b8tWirmJD iVE2DvX0z8lS+dMUXokmlur9j3/ZJ8mnb3MnkPmZOD3xwI8N9e7nOMr1x1a27BOhJiJtEur5 /fOnd++/fBjVQuErux02+4/RVDqfqBav3ldSDzKu61/ef/y7Ldb7d9+/ffs8V6pM1cKFughz +TGagJZNcqgfb4Zae19dVYunxw+f7aP43Ycff58N5ep5nfy8enx+9zgK4o9d+2rRhu7gugd+ +OXwIGrUL19s5+XPp+sObmj6Mz9FPr7Vk6Z1NHyiWHFPka8fn9/948enn/ZqvXzGHd1neXvS LtQPWzdGkViYMqf7b20oPcoo1FtDkTrPY9iFcsNiNk5bjA8+PX+bKteoWvhHZHq1+Pj4880a 6E9gdHs7GWqiIzhub20W3giknMCnf/4Ul8US9M5fSeW/b3jFMTHEf61UqpGDzH7yl//69ueP r4+f7dDx64fP0532XKV6CWXvrbkT6GcTmuQa+OPpr29/PL376X55LhQtI0h+ioRQP57ef/vx YS5Uns6FrRZyoraPWosqHOsqVFxl96H++fjz5w82TNtcq0/PdiR8US4tfH2rJd3D7ap7uJbD zD3yv377+enjv14bDWe7h/96+vrz+7fPn999/8ffZ0K5xxevJpr2taGevn+aDpVr2POH7XH+ 7McgU6FyjfFdqN+uIm1Sqo+Pz//6+v6qdd/iHn7+/cvTl6ubuKU6wKlpp7dpkU27W80zyGyo 79+eP/3TDrK+PP14nnsO5+q2//npw9TDMfRsqcO4sndx2el8/psbH/waxtpdoj46ZULTsfyZ WD6fwKjJeclUFyosBuySbPvMfos+VMT899XFCqFCLzMkIagI4Z02TStMVMFX6wX1F0LGefty As0wFA9Vm2KsHKPSS4gu60s1ulLu/brPZEpzQcsaQsab6pffPv/x4ekvNyIexjL08zB4dlUm /HtKDQyh/EBrcLGoWqikTufla5EQKkxJh5cjmp5OYQ0dp8UFsU+RbjwTGIf65bdP3/56ev/r v9kL8j/7QoVl9ppe6NNYJPxjaWXvZsXEy6R0CDW+hbtQ/vvysKBSx4UK81Jd1oca38JK0yiO 5hBqWvw7US1eu1a8e+NGWSVfSjW6r1QdXiCkVPbRtbIf6kKN2yWlt3iB0JVqFKrxz9xu2fTK ZyNvBpkSPhS7SlTLhTEJ75VYXYdjdaE+fvr89O7zt/d/jJ9aYTqBWmXf51QTLXvk88pFuXjg B67TqZ11za2kx3bI3GDu+Q/3ttYPsEIsLjR3K19VJev1NbCVbs1ml7nK/MvEywN/ov0/RcpD 5Gr+2y3lvB72hItEr5/9er3QJqQ0t8+f/nbRqrP+iRGydc3t1dTPj8cPrnf24+npnSua/5mu 3NnSdTjPtAg3NDBLS6Uq35kMmRug/fKbe4Rc9c5kOIFZ586+fJ2aJAnLt8Jtu7LTfrUO4nra x0EH93Menix+kX18tWjVMPMzxV9//rgYNda1O4Rt95vBOx8R2ZGWNR9krmW3DdN3dpEMTRGH bOVDRNGjIGT2k7+4VTbPV1crvLvyma1E5uWcR/Ruh8ega/Xhx7vPj/8av/AOrXJY7Mf9A19E r1m56jH59SqjSSZlfJezto0hfaNVs/ot/XLIhLKV/cu7558//nw/WG7hfpua4zqlz87FMLOl +uvLu8cfT4+jeLxuW38IRY2Kr4gqtm/RDc5eqsXH6zrhfk4XJkwcruxbyFFGT+HraEYOsrUN UzvKfMvu5h4vmgtFF0andM54NcwolJtNHcfiVdVnPAzxY3u3ohpm7t364/MfV3WQ08EpWztA DW9WZL8O4uu3r+/++tK/EKFr5EM1dTgH66ZUL6vF978N54e7RG2kCL2dlSvcrvoWXyZD1X22 tg0cHoNRtfjvp1+55HYQ9W//9//9n26M9TKTQj/qQsmLakEd8rAM/M1Jpj7UsFibhTLaDteG hRp8zP+sC2Wb4RyhhoXaLpS0/a9mplT+Z10of/HTQ82UKnMobu9ZNVMq/7OXUCpLqJlSZQ7V 8HZ0V40+1gSOSw1IjlCjQg2HzKtDXa3bc6Fc2zNbqrUN03SpuqOFJCs/NSkr39yuCzU+hvsQ hXJrhmdLtXpB8WSpuqO9FIvemkqp1ofiph5krs9Olb0SarZU7ofu3+OGcnOl6o72Uqowoeqz taFoMUqXdaFs92tcqPHbxu4M5SiV5oPbigveOpMotAhdpRWhuDaav2T2M9yEaqHNK6XK9QKr CzW8VO5vC/hrVaWEuuoHUrUQzSulyvWurAs1LJS9F1SfrQ2l1TB7eeBf3FUX3yjTkpUQanSl eOOmXkSjmnp9KEXNRMgGD/xXS7WydzvTtxiWijld5w6uwwTaulBhcokyNx/4h3uteTmSG8+c rb2vLodye7slpDyJ/J/YNEac/9Pk/8QDg//bPrm7HP4vft4b/i+9VPB/Cd2KQv7PTbHv7v9o kUrOd+pmzv9tQg3P5P9a+L/78X9+QVFO/6cF/F+GUsH/3YP/axT8X2qo4/k/26zC/8H/zZ5A +L/EUPB/CaWC/0sMBf8XWSz4vy6D/4P/g/9jbyyvHPk/t1xl0v9Rb5Oy1f5vRspt7f9YK4r5 P1GX8n+eRE36vzqsLYf/u5pPGJoyN3CE/4u6VvB/ef1fpW7A/4UXc/QIvTP/1/BJ/2dqk9v/ OSWyv/+jEwz/94b/s09h+L+4Uu3l/7iA/zuA/wvwB/7v6lrJUQb/d//+j9rIIv6PamAZ/zew EKv936SngP+D/5sLNVMq+L+FKA/+L5//c3vR+cwPmdeFGh/DDdWO6P9qAf+XpVQX/k9prd30 RZgWXOf//G5wIXO91xb+L0uprv1fRdmh/F8rs/s/U+3u/2QL/4d0A4n8n9w0Rpz/M+T/1AOD /9s+ubsc/i9+3hv+L71U8H8J3YpC/s/9Vefd/R99lSL7/8H/pfk//1de4P8Whdrf/2mW2f+p Cv4vQ6ng/+7B/2H/P/g//1vY/4/B/y09gfB/iaEO5v9EDf+XKRT8H/zf+AzC/6WHOon/4xUN p+D/lniKaf9HX6WE/5MB1CX5v3Cxjuz/+lJt7f/csmX4v7hSwf/l9H/2IDP+T2X3f/KI/i/U QHaV4P/mauAi/yeF61xk3v8P/m8r/+f6Ftj/bzLUMv/X+F2ZS/g/4y5S3v3/2Iz/a/xSjpz+ z+1uDf8XFeoM/s+tT4X/iysV/B/831SXE/7PZ/B/S0PNlAr+byHKg//L6P+4Hz4IoRL83+gY vX05lv/rVCP8X17/17qOtn1QqWp1KG6Um8sPGcP+f/B/Mf5P6PaI/q+C/0O6hUT+T20aI87/ 1eT/zAOD/9s+ubsc/i9+3hv+L71U8H8J3YpS/k/s7/+E3gLlwf8lhpr0fzWH/7sf/ydYZv9n FPxfhlLB/8H/XZYK/i8xFPxfbKjLMwj/l+EEwv8lhoL/SygV/F9iKPi/yGLB/3UZ/B/8H/wf e2N55UL/N+h0wv+NSnVz/i+snIP/e92UuYEj/F/UtVq6/19+/8fm/F+zxQuE4/k/aWb9H53Q Q/k/zbPv/+fW+8D/xZxABv/H4P8mbuHd/B/D/n9J/s/9cWL4v8hrJUcZ/B/8H3v5bvB/8H9L Qw0LtV0o+D/4v5lQo0INh8xH8X/c925tF6OqV4caH8M9S47o/zrRA/+X1f/ZS1S5B5Vp6U+4 rfJ/tscvXjIG/wf/F+P/pKwP6P+U4fB/SDeQyP/pTWNE+T9dkf/jDwz+b/vk7nL4v/h5b/i/ 9FLB/yV0Kwr5P9dZ2tv/SeqNwv8tqBbwf5GlOrX/8zPP2P9vwTsK+L/0UPB/8H9X1eJw/s8t ooP/iw0F/5d5fAD/l3gC4f8SQ8H/XYW6N/9X+SoK/xcVCv7vTv0fFQf+b4mngP+Lqhcj/8d5 O+P/6OD36f/cTPGM/6MiwP+9bsqw/1+q/+s35dvc/5kj+j9Vve7/NHXiEv0fjX7m9/+7Z/+n 1aT/a1yDx5Xgev27ilb5ExgyWsW0t//rmlv4v3GoC/9nv/WZ/B/3Nftw/q8u6P9En632f2KY 7e//Gqlz+z9f2Sf9H7Wzh/N/1IyX8H/hBJfwf6EVKuD/GK37LuP/QqgC/o960GX8H10k+D/4 v2GhtgsF/wf/NxNqVKjhkPkw/q+t/B/SaP1IZKX/Gx2jty/H8n/Y/y/9beOU/zO6dvMWlaYx 1Tr/p91fjQqZu2TiBvwf1cCD+T9d++xY/q+W2f1f/8Dfbf8/mX3/PxcK/g8pMpH/M5vGiPN/ nPyffGDwf9snd5fD/8XPe8P/pZcK/i+hW1HK/7Eb8H80coD/W1Atdvd/Nfzf/fi/imX2f1rA /2UoFfzfPfi/RsH/pYY6nv/D/n9rSgX/l3l8AP+XeAJL+T+t4P8yhYL/g/8bn0H4v/RQJ/F/ rKF2HP5viafY3f8Npm/vzf/N7/+X3/+Jev/9/8LYF/4P/m+Q7nv/v4L+z9zM/n85/V9zJv9X Vzq3/7uN/f+aQQb/N+f/Trb/HzXH9+r/zC34P91nq/2fHmb7+7/a30lZ/Z+a3f8vmJv79H8M /g/7//nP35r/o0OU8X803qZsbRs4PAZj8H8M/u+NUDOlgv9biPLg/zL6P+M7EjYzq0ONj8H8 hOrx/B/2/0t/2zjl/2xTXrmOUmgmVvo/d4VDxmhGemf/F+Af/N/E3O3x/Z97UXE8/2crM/wf Umwi/1dvGiPO/wnyf/qBwf9tn9xdDv8XP+8N/5deKvi/hG7FtP9rDun/6CLB/y2oFnv7P78o Af5vUajd/Z+fxs/q/4yC/8tQKvi/e/B/2P8P/s//Fvb/Y/B/S08g/F9iKPi/hFLB/yWGgv+L LBb8X5fB/922/6MbFv5viaeY9H86LF9w7cRq/6eGWR9qev8/n632f5cLfA+4/98t+L+wcg7+ D/5vkO57/z825/909hcI8oj7/0lzSP/X8En/Z5o6t/9z631293/0RUO21v9dzsfA/0WewNvz f9Jn9+n/GPwf/B97Oa/wf/B/r6/7nvZ/YVrdZ6v9Xz3M4P+i20D4P8rg/5aGmikV/N9ClAf/ l9H/CT/e5lKsbwPHx3A9oiP6P+z/l/62cdL/2QGW938qyf/Jl8wfFP4vS6mu/J+Hf/B/U8Pu m/N/Mrf/c2Nh+D+kyET+r9k0Rpz/k+T/6gcG/7d9cnc5/F/8vDf8X3qp4P8SuhWT/k+p3P5P iRvwf9Qbhf9bUC12938t/N+J/R/2/4P/mw11NP/Xavi/1FDH83/Y/29NqeD/Mo8P4P8STyD8 X2Io+L+rUPB/8H/wf9Oh9vd/dLbg/5Z4imn/RzPJaf6PTh38H/zfqzUQ/o/F3Fen8H8F9/+D /0vc/0+cyf/Vrd//T/I6wf9pz0pCdhv7/x3R/6naPT2y+j/Bzan8H1UE+L+JhYh7+T8u9vZ/ poX/W+b/zA34PyMHGfwf/F84Nl0k+D/4v2GhtgsF/wf/NxNqVKjhkPkw/s/QIShbu//f8Bh9 qGP5v0bB/2Up1YX/s7XGuL9bJKRYG4rXtStOyGgsDP+Xo1Tn8H8tz+3/Bg/8A/k/oeD/kKIT +b920xhx/s9+jttf4A8M/m/75O5y+L/4eW/4v/RSwf8ldCvO5P9oNjPnO3UD/7eN/2s1/N/9 +L+aZfZ/ooH/y1Aq+L978H+mgf9LDXU8/4f9/9aUCv4v8/gA/i/xBJbyf6KG/8sUCv4P/m98 BuH/0kOdxP91iwPh/5Z4Cvi/qHpxAv/n5lRn/F9YWw7/dzWfAP+H/f/eeoFQzv+FGsiuUvB/ 4QQm+j+6N4+5/59WU/7Pdib839HXiq+vga3xFipk8H8rmtuF/s/13vLu/+daC/i/qFLdnP9r veoK2Wr/JwcZO5P/06rVuf2fr+yH83/uD2nA/8WV6tT+zy/6gf+bCAX/Rxn839JQM6WC/1uI 8uD/Mvq/2vd+Q7bS/42O4fuB8H/XoeD/Jv1f06radpRUKM4q/9dU7i1iyBj834b+r6LsSP5P cZ3d/5nd/V9rdG7/50aN8H9IkYn8H9+U2sX5P+39nxYPDP5v++Tucvi/+Hlv+L/0UsH/JXQr Cvk/9552d/9HFwn+b0G12Nn/mcpNwQvdJPyhW14L3Wc+FPxfZKip1mLC//kFRfB/C95RwP+l h4L/g/+7qhbwf1ex4P/g/+D/ZkPB/yWUCv4vMRT8X2Sx4P+6DP7vlv0fa6kdh/9b4imm/B+n 5oJXLuJa/zcaYtmbc87/tX222v9dXiz4v6tQy/0fn93/T8P/wf+dxf/JoLMK+D8/laVEt7Jv nf9rB5l72TPp/1r/UBRVwCIrlxaFUxKGTifyf/aebbz/k23C/n+mlX1Gq5j29n869C0o1EH8 XyM4/N/C+2pv/1dz+L9F/s9dq339n654Of8XRjsH83+0KreM/6MTXML/0SRqCf/H6C11Gf9H j9wS/o/GX0X8H31R+D8G/zcs1Hah4P/g/2ZCjQo1HDIfxv+1vjcRspX+b3SMPhT8H/zfRKnG /k+0Qjj/J5uU/f9a2v+vvSgV/F9u/+cXfx/N/3kiJ5qwyfVK/0e/3GVid/+n6uz7/yn4P6T4 FPwf3zJGnP8z5P/UA4P/2z65uxz+L37eG/4vvVTwfwndilL+rzqk/2Pwfxv5P9fHhv9bFOqA /k9V8H8ZSgX/B/93WSr4v8RQhfyfaOD/4P/mTyD8X2Kog/m/IcqD/4P/uwi1r//zZYD/iwoF /wf/1y+jg/9jUcsrT+D/WCvg/yJDXdXA4/k/N3CE/4u6Vhf+r5LF/J+Z83/0wi/nCwSuS/k/ t6fc9P5/mvxfOGkrlxbRNTH0V5LOtP+fbKXJ7f9uYv8/RdfqWP6vdQ8R+L/JUDfn/+rc/o+L Q/q//ff/0/7ghfxf+Dn831r/R2/Lyvg/KkIR/0d1oIT/q8JsQgH/V/tylPB/VL0L+T/ZZ6v9 nxxm8H8M/u+NUDOlgv9biPLg/zL6Pxrac6nWt4HjY/h5iwP6P9XA/2Up1cX+f3VjvP+raaC/ 0v+5ljNkDPv/bej//ED7YP7PL5PI6v/k/vv/KZF9/z83Hwj/hxSZgv8TW8aI8381+T/zwOD/ tk/uLof/i5/3hv9LLxX8X0K3opD/E+oG/B8tUoH/W1Atdvd/pmXwf8tC7e///LpD+L8F7yjg /9JDwf/B/11VC/i/q1jwf/B/8H+zoQ7m/7D/H/zfK6Hg/1IuFvxfeqjT+D+6YeH/lniKQv7P LeyY9n9hBSL831Wpbs//0c/h/143Zdj/D/5vZ/8nivm/c+3/11ZVbv/H4f+28n9uYJ7X/9mn MPxfXKng/7L6P7b//n8b+D8D/wf/5z9aDTP4vyP4P91nq/2fHmbwfwz+741QM6WC/1uI8uD/ Mvq/qiJMpte3geNjuE/C/02EyuD/QqnoS68MRS/yumx//9cIpb3/42JtKAf/1EvG4P/g/3b2 f7ew/1/F4f+QbiAF/ye3jBHl/0xF/o8/MPi/7ZO7y+H/4ue94f/SSwX/l9CtKOT/3GvG3f0f zWbC/y2oFnv7Py7g/+D/4P/SSgX/dw/+T3H4v9RQx/N/bhkn/F9sKPi/zOMD+L/EE1jK/2kF /5cpFPwf/N/4DML/pYeC/1te2eH/GPzf1GLsof/jvD2g//Mkatr/UXWD/3vdlKkK/m8j/0ft A/zfRGsx9H/SYP+/yNbiwv81fNr/tdn3/3NKBP4v5gROhJryf7pyZwv7/02Ggv+D/1vSYyrj /9zihGn/p+hmKOH//KAnp//zg+FJ/2fowhTxf6H/4j+2sf+ja1nA/xH8K+P/wrT6wfxfWMNf xP/Vfbba/9XDDP6Pwf+9EWqmVPB/C1Ee/F8+/8ea8CJJJrSBo2P0oY7l/2qxv/8Lf8RLioRQ 4/1q3dztvv6vVXaAypU0NL5a6//4S+ZOTQP/l6VU8H936/9kXcP/Id1ACv5PbRkjzv9x8n/y gcH/bZ/cXQ7/Fz/vDf+XXir4v4RuRSn/J27A/9VboDz4v8RQ0/6vgf+7H/8nGPzfdCj4vy6D /5vzf9j/D/7P/9bI/7llnPB/saHg/zKPD+D/Ek9gKf83RHnwf/B/F6F29X9Uv+H/okLB/92n /2vCSlj4v5X+r7vHPVBY7f/4MBOz/i/0BKU/0kr/x4dZOf93tv3/aOQN/zdR2YemTDYN/F/c tTqF/xtcq1Eo+L+b839+cduE/7OVPLf/Uzex/1/YJYpCHcX/uZsW+/9Nhlrm/3zNvlP/xwz8 3734P1/Zp/0ffZWj+b/wJ5mp9mzr/8Ko0X9sW/9HA+4y+//RcQ/m/2ixdhn/R6amiP+jn6f5 v8ExGIP/Y/B/b4SaKRX830KUB/+X0f8ZavmNX6C1MtToGL2UO5b/kwb+L0upLvyfau34yvk/ mrtZ6f/c5FHI2E3s/ydoteLR/J+fy4f/mxh2j/yfm3rc2/8pNxLJ6v/skxz+Dyk2Bf+nt4wR 5/8E+T/9wOD/tk/uLof/i5/3hv9LLxX8X0K3opD/U8f0fwb+bxv/55kN/N+iUAf0f6KB/8tQ Kvg/+L/LUsH/JYbC/n+xoS7PIPxfhhMI/5cY6mD+T9Twf5lCwf/B/43PIPxfeij4v+WVHf6P wf9NLcbey/9ptf/+f/B/8H9H83/siP7Pvewp5P+UOKL/883thP8z7l0G/N90qFvzf9y9A8zr /2y1OJP/u+f9/+b9n//tkK32f2qQsVP5PyPbcv4vXEv4v7X+r/tG/mPb+j9qA+H/Jrqcp/Z/ TZ+t9n/NMIP/Y/B/b4SaKRX830KUB/+X0f81iqpbndAGjo7Rh4L/g/+bKNWF/7OjYOX9nxRr Qzn4p14yBv8H/7ez//MzZ3vv/5fd/7lQ8H9IkSn4P7NljDj/J8n/1Q8M/m/75O5y+L/4eW/4 v/RSwf8ldCvO5P/CVymy/5/aINSJ/J+s4P/ux//5meec/s8O7uH/0ksF/3cP/k9x+L/UUMfz f6KB/4P/mz+B8H+JoQ7m/7SC/8sUCv4vs/8LLSz8H/zfbKjj+D9angf/t8RTTPs/+nkR/yf7 7N78H+ftqfb/q+H/Fvk/Af93N/6v4P5/ptz+f0q95v94293pSf6PKvst7P9nWpbZ/7nmdsL/ CZHd/7lqAf8XcwInQk35P9W6q5PV/7ltIc/k/3wX+k79HxeH9H9c7O3/al1w/7+C/s8TuUL+ j1qhEv5Ph5bdf2xj/0dFKOL/Qj/R92639X8V3UTwf/B/8H/wfxfVAv4P/u+6VBf+z/ZrZZ+t CzU+Rh/qWP6v29EL/i+v/+NunzLn/6g4a/2ffMkY/N92/s/DP/i/iWH3zfm/tob/Q7qBFPxf vWWMOP+nvP8z/IHB/22f3F0O/xc/7w3/l14q+L+EbkUh/+fe08L/JYaC/4sJBf/XZ/B/8H9T oeD/bsD/Yf8/+D//W9j/j8H/LT2B8H+JoQ7m/7D/H/zfK6Hg/1IuFvxfeij4v+WVHf6Pwf9N Lcbea/8/2ey//x/8H/wf/N8d+D9livm/m9j/L7//m9n/TxiF/f/S/B9Vmy5b6f8uZ5km9/+r 3NnKu/+fHePD/8WVarf9/xj83yb+r2k0/N8i/2fg/+D//Ofh/+D/loaC/4P/mws1Uyr4vzfW 7e28/19LU5PU5VwZanQM3w88oP+rBfxfllJd+j/T+P3/dJPi/9wVDhmD/4P/29v/id39n+bw f0i3kIL/a7aMEef/NPk/+cDg/7ZP7i6H/4uf94b/Sy8V/F9Ct6KU/6v293/hDXfmd+rwf4mh pv2fgf+7H/9Xscz+TzTwfxlKBf93D/4P+//B//nfwv5/DP5v6QmE/0sMBf+XUCr4v8RQp/J/ 0ldt+L+oUPB/9+n/aAgL/7ek0znt/8Kq3NpPSq/0fyI8FUNPcNb/mT5b7f8uF/jC/12FyuL/ wtpy+L+r+QT4v4z+zx7kiP6PHdL/VepE/s+0VW7/517M7e7/ZPc2zf/HUfyfu2nz+j+jT+X/ Kv/cvU//x2f3//Ndpaz+T57K/7U8u/8z5/J/1GMq4v9UeFj7j23r/0RB/xfG2753u7H/o+oG /wf/B/8H/3dRLeD/4P+uS3Xl/2jqsfXNxFr/NzyG/bE6ov/rSgX/l9f/6caOTJ3/oynctf6v fslc77WF/8tSKvi/+/V/Qmb3fwb+Dyk6Bf/Xbhkjzv/V5P/MA4P/2z65uxz+L37eG/4vvVTw fwndikL+T6g5/0fTtnfq/xj83zb+Twn4v0T/V28QqpT/w/5/8H+zoY7m/7D/H/yf/y3s/8fg /5aeQPi/xFAH839awf9lCgX/l9n/GX+64P+iQsH/wf/1y+jg/1jc8sqw9uHA/o/z9kz+b/wC Gv5v1v818H934//YIf1fdQP+Lyyouk//55bsXfs/JUT2/f9ccwv/F3MC2X7+r+Gn8n9UEeD/ rqd+4P+O5v8aP42X0//x5gb8n5GD7Cj+j+BfGf8XptXh/+D/4P/g/y6qBfwf/N91qS79X027 8DZVvT7U6BhuYuKI/g/7/6W/bZzwf4rXvLaZqs3qULY36yY9QuZOTQP/l6VU8H/r/J8bXx3P /7l5C/g/pMhE/k9sSu2i/J/9d+f/dPXA4P+2T+4uh/+Ln/eG/0svFfxfQreikP9znaXd/R8t vYH/W1At4P8iSwX/h/3/FryjgP9LDwX/B/93VS3g/65iwf/B/8H/zYY6mP/D/n/wf6+E2tX/ 0YIz+L+oUPB/d+r/wkpY+L+1/q9u+my1/zPDjIs5/9f22Wr/d3mx4P+uQi33f+4F9LT/Czcs /N8b/s9Wdvi/qGs19n9cVsX8n1Iz/q8u5v9aX7NVZbo/vbbm2cibQeb+Mvak/2v9z3ktE94r df6PMkXM5hz+Txpjcvs/1cD/3Y3/s09h+L+4UsH/ZfV/7lqdyP+FZ+LR/F/4OTUa2/q/cIIl xd3S/9GAu8z+f1Sz4f/W+j9NY+Ei/k/22Wr/J4cZ/B+D/3sj1Eyp4P8Wojz4v5z+T+o+W+v/ hsdwnzyi/8P+f+lvGyf3/6uF9P6PxlRr/R9/ydyyYQP/l6VU5/B/xg1Bjrb/nzQ8t/9z84Hw f0iRKfg/vmWMOP/Hyf+JBwb/t31ydzn8X/y8N/xfeqng/xK6FaX8n9jf/0kF/3c3/q+B/4P/ g/9LKxX83z34P8Xh/1JDwf9dx4L/g/+D/5sNBf+XUCr4v8RQ8H+RxYL/6zL4P/g/+D/2xvLK 4/s/1gr4v8hQVzUQ/o/F3Fen8H+VhP+LDLXM/zWa/F9FJ23l0iI9yA7q/7Sa9H+qErn9n2tu 4f9iTiBb6v/cQsW8/s+O8eH/4kq1m/9rbsH/mT5b7f/MMLuB/f9Mndv/uTWP8H+R10qOMvg/ +D/28t3g/+D/loYaFmq7UPB/8H8zoUaFGg6ZD+P/NL3YMTIh1OgY7Cb8Hw9SLp//O+b+f1rt 7f9kI73/M02K/3PrC0PmR/Dwf1lKBf93v/7Pv1mH/0PaOwX/J7aMEef/BPk/9cDg/7ZP7i6H /4uf94b/Sy8V/F9Ct6KQ/3N/Ym/a/9EpK7L/X+i3FfF/coNQJ/J/WsH/Jfo/uUGoaf/nHw7w f0veUcD/pYeC/4P/u6oWh/N/qoL/g/+bP4Hwf4mh4P8SSgX/lxjqVP5P+foN/xcVCv7vPv1f mDSD/1viKQr5P7dc5Xj+rzYz/o9Wet6p/2tm/R9VN/i/102ZkvB/97//n8ru/+SM/2v8VJZt JcI0+Dr/Vw8yaW7B/1GpD+X/alEdc/8/qvzH8n/cNbB5/Z+tFqfyf5qyY/k/f79m9X9cw//F hbrwf2LW/1FrcjD/R8t8ivg/Hfov/mMb+z86W0fzf/TILeH/aAxXxP+FhWYl/F+YTEjyf8Nj MAb/x+D/3gg1Uyr4v4UoD/4vp//zA1SmfSd4rf8bHsP3Aw/o/0x1RP+3//5/xihO/m91KAf/ 9EvmDqrh/7KU6iT+r5LseP5PupFIVv9nn+Twf0ixKfg/uWWMOP8nyf+ZBwb/t31ydzn8X/y8 N/xfeqng/xK6FYX8n3vNCP+XGOpE/s9U8H8n9n9Mwf9lKBX8H/zfZang/xJDYf+/2FCXZxD+ L8MJhP9LDAX/l1Aq+L/EUPB/kcWC/+sy+L9b9n+8ouEU/N8ST4H9/6Lqxcj/uX3KSvk/zm9g /z/4vyWmzH5d+L+4a7Wb/7NNdjH/x1Up/+de9sD/XYWK8H8Nn/R/Whxz/z/6ovB/l6HOvv/f Pfs/Af93N/5vfv8/+D/4vyv/R/DvcPv/HdP/Yf8/+D/4P/i/2VCjQg2HzIfxf4Z4m/FrFFaG Gh2jl3LH8n/SwP9lKdWF/1ONLY7zfzRgWev/5EvmTk0D/5elVPB/8H99Bv+HtCIF/6e2jBHn /5T3f6Z6YPB/2yd3l8P/xc97w/+llwr+L6FbUcr/iTn/R9WihP+TnAbtRfyf2CDUmfyfgf9L 9H9bIJFp/+dXfcD/LXlHAf+XHgr+D/7vqloczv+JBv4P/m/+BML/JYY6mP/TCv4vUyj4P/i/ 8RmE/0sPdRr/R8WB/1viKSb9nyno/8IKRPi/q1KN/J9bQ7Kz/wsvqOH/JuYTRv6Pw/+l+T97 X5Xa/68v1ZH8nyjm/2Q16//ohN6n/5vZ/08ak9v/daW6vlgF/Z/utl/woeD/5vzfyfb/82fr Xv1fwf3/3Iwg/F9MqKX+L5ibg/m/7ufUaGzq/8JyW8pWNkxTKG/C/9EkE/zfRJfz1P5P9dlq /6eGGfwfg/97I9RMqeD/FqI8+L+M/q/W/ri1V/grQ42O4RrwI/o/7P+X/rZxyv9JWSvv/9Tq UA7+VS8Zu5H9/7o5qIRQ8H8vGfzf/v5PGPg/pOgU/J/eMkac/zPk/+QDg//bPrm7HP4vft4b /i+9VPB/Cd2KQv7Pvaed8X/0sRL+r9uKEP7vzWqxt/+rBfxfov+rMoSqLkLN7P/nFxRl9X8V /F+GUsH/wf9dlgr+LzHUpP8zbfb9/2yPCf4vNhT8X+bxAfxf4gks5f8aDv+XKRT8X2b/R78O /xcVCv7vLv0fa8JKWPi/1f6Pfu676qv9nx5ms/4voBdFa8tX+r+RlIP/S/N/bhHOtP8Lj6dj +b9goXL6v6qC/4u7Vrvt/zco1WW7FELdo//jM/v/cVHn9n98dv8/fs/+zzW31/6v0vb/Mvs/ Z1/O5P80dcXu0/8ZfS7/J312l/7PdWOm/Z//bfi/RT2mCf9Xq5L+b/CXSFb7v8ux3O7+L7SB Jfxft4EiTWht6/+oaSjg/xi9pS7j/+iRW8L/0fKYEv6PV+X83/ABsLYNvHqIwP8x+L/XQs2U Cv5vIcqD/8vn/zjNRdu+2fp+4PgY7GWnvB39n2jCkDnJ/4U/B0OPxkbB/2Up1dj/VbK1PSau FK/N2lC2N+vmh0NmP8PN7v4vwL+j+T8/nQX/NzHsHvk/N8++t//zf3Y+q/9z8xbwf0iRKfg/ s2WMOP9Xk//TDwz+b/vk7nL4v/h5b/i/9FLB/yV0Kwr5P6Fm/R/VhxL+T22B8uD/EkNN+78G /u9+/J9m8H/ToeD/ugz+b87/mQb+LzXU7v5PZvd/Bv4P/m/+BML/JYY6mP/D/n/wf6+Egv9L uVjwf+mhTuL/eEXDKfi/JZ4C/i+qXsD/Hc3/GZXd/xn4v7vxf+aI/i/UQHaVWp7b/6lm1v/R s/NQ/k9qhf3/7mb/P/cnwfL6P9cGnsj/+Z70vfo/Bv+3if8zRsL/LfJ/Ytb/UStUxP+FoRxN aG3q/wIXKuL/qCNxsP3/Dur/TJ+t9n9mmMH/Mfi/N0LNlAr+byHKg//L6P8qelBVfunKSv83 OsZR/V9XKvi/zP7PbdrHlW39xNpQvG6r9iXzXYj9/V9YqZO0clTwYQb/t5H/88sk8u7/1xzR /7lRI/wfUmQK/q/eMkaM/zPuf+fuL+Y9MPi/7ZO7y+H/4ue94f/SSwX/l9CtKOT/3B+j29v/ CXoJVMT/UZ8a/m/JCnP4v7jWIs7/ZW0DZ/yfZJn9HxfwfxlKBf8H/3dZKvi/xFCF/J+qFPwf /N/sCYT/Swx1MP8navi/TKHg/+D/xmcQ/i891Gn8HxUH/m+Jp5j0f0F4pPm/8FR8w/8NO52r /V+4WLfj/0LVzuj/+lLt5//CEnP4v9dNmRs4wv9FXaux/7MHgf+LDLXM/zU6t/+TZs7/hTUm R/J/vGrFIf1fwEXH8n/+Jsrq/9yaxzP5P04vlO7T/x1z/z93rXb2fzr7/n/+T+1N+78wEjmW /wsEpYT/64ZyNKG1qf8TxfxfN8Q/mP+jp0cZ/0fLA+D/4P+GhdouFPwf/N9MqFGhhkPmo/i/ 7sVLXa/3f+NjuE/ejP8TOfwf1YJa7O//eJgIyOf/uNzZ//GqbbnboFmK1aG4rXnVS8bYi2qE /4P/myjVpf+TRrLM/k8c0f8p+D+k+BT8X7NljDj/x8n/yQcG/7d9cnc5/F/8vDf8X3qp4P8S uhWl/J/Y3/+FRSrwfwuqxd7+r1Hwf/fj/wSD/5sOBf/XZfB/8H8TH4P/g/+jBP8H/wf/t9r/ DVEe/B/830WoXf1f478p/F9UKPg/+L9+GR38H4tbXkmnrp/7OdP+f/n9X7n9/9xMMfxfXKng /7D/35svEPpQB/J/brnKjP+jUt+n/9Nqcv+/VmTf/881t2fyf007zFb6v3qUzfk/Vx+w/99k KPi/Mv5v0F1c7f+GXU4G/3c//q+B/4P/85+H/4P/WxoK/g/+by7UTKng/95Yt7e3/6MnFGVr /d/wGO5DR/R/poL/y1Kqi/3/mqZx8xa2R9qsDcXr2nXwQsYY/B/8X4z/E27yL6v/k9Uh/V8D /4cUnYL/a7eMEef/BPk//cDg/7ZP7i6H/4uf94b/Sy8V/F9Ct6KQ/1O3sP8fLb3J/E4d/i8x 1KT/87u8w/8tCrW//6sY/N90KPi/LoP/m/N/isP/pYY6nv8TDfwf/N/8CYT/Swx1MP+H/f/g /14JBf+XcrHg/9JDncb/hdlb+L+1/s/QC0n/HjrV/8mLUJf7/wXoBf+3tFT7+b+wcg7+D/5v kLD/35n9n1Cz/i9MJ9AD4M7839z+f01F/i+hBrbGn4uQ0ZpH+L+4arGX/9PqXP7Pv7+7U//H Dun/uNjd/4ns/s8tTjig/8P+f/B/dI1uzv+FsXAR/9f02Wr/1wwz+D8G//dGqJlSwf8tRHnw fxn9X1O1fbYy1OgYboh/RP/XKPi/LKW63P9P2gEsV1yoBP9ntHnJ7Ge4gf/LUqor/+fh39H8 nx/twP9NhYL/Q0pN5P/kptQuzv9J7/+UeWDwf9snd5fD/8XPe8P/pZcK/i+hW1HK/93A/n9C b4Hy4P8SQ037PwP/d2L/594nwf8llwr+D/7vslTwf4mhsP9fbKjLMwj/l+EEwv8lhjqY/2PY /y/5KQL/l3wC4f9yhYL/g//rl9HB/7G45ZVymMH/3c/+f82s/6MiwP+9bsqkgv9L2//P3lfw f3GhRv7Pvewp5P+kOZH/q1ppyP+ZpP3/eJ/B/61obrH/39H8XyOz+7+C+/8Z+D/4P//V4P/g /ya6nPB/8H9LQ8H/wf/NhZopFfzfG+v29vZ/tAKOsrX+b3iMPtSx/B/2/0t/2zi5/18rW9dR MjRgWef/tCtOyPwlg//LUqqT+D/X5czq/9ws5/H8n5tQhf9DikzB//EtY8T5P0X7/1UPDP5v ++Tucvi/+Hlv+L/0UsH/JXQrCvk/163Y3f/RtG4Z/8c3CHUe/1dXAv7vbvyffzhh/78l7yjg /9JDHc3/tRr+LzXUAf2fauD/4P9mTyD8X2Io+L+EUsH/JYaC/4ssFvxfl8H/3bb/o+EU/N8S TzHt/8JqjCT/F0yZvAh16f/C6uZ79H9un7Iz7f9HkAL+b2I+Af4vp/+TFfxfZKgb9H/hxRw9 ADb1f75UBfyfqNzyy7z+z3Hr/f0fXaRj+T/pBgN5/V/DT+X/fH/2cP7PPwzh/xb1mCb9Hy/n /8IJhv9b7f/CCaQJLfi/eP9HoUr4PxrDlfF/dJHg/+D/hoXaLhT8H/zfTKhRoYZD5sP4v8Cu TJOw/9/oGL4fCP93HQr+b8r/iar2f7eo6rpK6/yf5i8ZoykS+L8MpYL/W+n/miP6Pzd3C/+H FJmC/xNbxojzf5r8n3hg8H/bJ3eXw//Fz3vD/6WXCv4voVtRyv9VN+D/aIEJ/N+CagH/F1mq U/s/X+dy+j+h4P8ylAr+7x78H/b/g//zvzXyf7KB/4P/mz+B8H+JoeD/EkoF/5cYCv4vsljw f10G/3fL/o+FdfXwf0s8xaT/0/RCEv7vdvxfwf3/Zv0fLayH/5uYTxiaMrdxPPxf1LU6xf5/ 7Ij+z4Wa8X90Qo/k/3gt1SH3/9Nt+Co+FPzfjP+z3/pc/k/67C79HxeH9H/uWh3P/4lZ/0cN 18H8X7hWRfwftewl/F8YCxzM/1V0Ex3L/zFqisr4P3qepfm/wTEYg/9j8H9vhJopFfzfQpQH /5fR/zXht322dv+/4THYQf1fLY7o/wYobx//x00jpOsoCbU6FK+165+EzH6GG/i/LKW69n+C skP5v8pIhv3/JkNh/z+k1BT8n9wyRpz/M+T/1AOD/9s+ubsc/i9+3hv+L71U8H8J3YpC/s92 wPb3f/QmLvPf1J32f+FFOPzfWv/XwP+d2P9h/z/4v9lQ8H/wf1fVAv7vKhb8H/wf/N9sKPi/ hFLB/yWGgv+LLBb8X5fB/8H/Hdr/hbXGdIJW+j/eDLN5/0f/6Xvvq/3f5cUq5P+cUzqV/6Mi wP/B/w0S9v+7Pf/X3ML+f8fzf6Kus+//p25h/z/6okX8X13M/3HXwObd/89Wi1P5P7/2v4T/ q92Zy7v/n/sTlpP+r8ru/9iJ/J+pWp3b//nKPun/CP7B/01cKznK4P+22v+P9xn83+t9C/g/ +L+ZUPB/8H8zoUaFGg6Zj+L/uPB3kn166NWhxsdw4+4j+j/VwP9lKdXF/n9GSb//H1dqbShe a3dmQsbg/+D/4P+MyO7/XCj4P6TIFPyf2jJGnP+ryf+ZBwb/t31ydzn8X/y8N/xfeqng/xK6 FYX8H29uwP/RtG6R/f/g/9L8H1fwf/fj/2oG/zcdCv6vy+D/4P8mPgb/N+f/BPwf/N/8CYT/ Swx1MP8navi/TKHg/3L7P2r24P/g/2ZDHcb/hTXE8H9LPMWk/6N2iLLV+//Vo0zN+L+w3NZn q/3fsNs+KNXm/k9Wp/J/Jqwth/+7mk+A/4P/W/ACYdL/tf7MScNT3sAMfnne//GK0zUgFbDy iU+Ci5HgOqj/c6Em/F9jmtz+T1bn8n/UWpTwf/4mgv+bDHUC/9cc0v9xsbf/s2Ps7P7PHNH/ uT+5DP8XV6pT+z+aPy3h/8JrzDL+r+mz1f6vGWbwfwz+741QM6WC/1uI8uD/Mvq/yjfpIVvp /0bH6EPB/+X2fzQxdCz/V9d2iGg7SuFBtdL/ua2QQ8bg/+D/ovwfd69fjub/ZCtz+z83dwv/ hxSZgv/TW8aI8n+8Iv/HHxj83/bJ3eXwf/Hz3vB/6aWC/0voVpTyf+IG/J8Kb6dL+D+9QagT +T9Rwf/B/8H/pZUK/g/+77JU8H+JobD/X2yoyzMI/5fhBML/JYY6mP9j2P8v+SkC/5d8AuH/ coWC/7tT/xdWwsL/rfZ/9FWK+L+gRO7R/9nR+xH9XzPn/whSwP9NzCcMTZn7wzFn8n90Q2X1 f7qY/2Nz/q8Ltb3/C/v/5fR/Ym7/P89whJEp+//VQUjoLtRp/J+sjMnt/7pSXV+sgv4vLG2v u/aLdW1CytQP/F/iCYT/iyrVUv/nfxv+b1GP6dr/6abN7v/cmsdp/xfIA2Vr/d+oI30T/o+a 8RL+Lyy3LeL/qGko4P9svaFP+d7txv5v0DNd7f+aYXYu/zeymivbwNExGIP/Y/B/b4SaKRX8 30KUB/+Xz/91qxJa/6RfGWp0DP8XE+D/rkPdpP9zc7e7+j9ZqeD/aHiw1v+Jl2wQCv4P/m+i VKfY/0822ff/g/9DWpGC/zNbxojzf5z8n3xg8H/bJ3eXw//Fz3vD/6WXCv4voVtRyP+pW9j/ j97Ewf8tqBbwf5GlOrX/0yyz/xMK/i9DqeD/7sH/mQb+LzXU8fyfUvB/8H/zJxD+LzHUwfwf 9v+D/3sl1K7+j5ZEwv9FhYL/u1P/R8eF/1viKSb9Xyc88vm/PtSl/wsL5+/R/x1z/z+3tGjG /4W15fB/V/MJI//XwP/djf+b3f8vv/8z5fzfzP5/W/i/5pD+zzW3E/5PCJHb/7kTuLv/M8Gz H8v/aZnb/zUc/i+yVLv5P9qY9Du7SGX9X9tnq/1fO8zctTqe/xPwf/B/c6FO4/9of3X4v+vh AfwfZfB/S0PNlAr+byHKg//L6P9q2jKt9iORlaFGx+il3LH8X6ca4f/y+j+uZOX9X7U6lIN/ 1UvGsP/fhv5P9dlx/F8lWWb/V6nd/Z/O7/8E/B9SdAr+r94yRpz/E+T/9AOD/9s+ubsc/i9+ 3hv+L71U8H8J3Yoz+T96CVTG/20R6kz+z8D/ndj/ufdJ8H/JpYL/g/+7LBX8X2Io7P8XG+ry DML/ZTiB8H+JoXb1f34ZIvzfklDwf1eh4P9sbYf/SwwF/5cYCv4vNtQy/0ftUBn/p/vs7vxf JYv5v75UW/s/Lmb9H/0c/g/+b5A28H9G7L//X7czUb4XCFxh/7/YE3hb/k9VSmXf/8/cgP8L 6+qO5f9422b2f75hOpH/811o+L+JqZ+F/k/zPlu7xHx4DLpWu/o/U1U6t//zlR3+L+5ayVEG /3f//o+eHofzf7zPVvu/wTEYg/9j8H9vhJopFfzfQpQH/5fP//HK46KQrQs1PsZR/Z808H9Z SnXh/9q6blxHqeVibSheG9cHChm7Df9Ha5uP5v98Dxr+b2LYPfJ/otnd/6lK5/Z/LhT8H1Jk Cv6v2TJGnP+T5P/qBwb/t31ydzn8X/y8N/xfeqng/xK6FYX8nzQ34P9UoIjwf29Wi739nxTw f/fj//y6Q+z/t+AdBfxfeij4P/i/q2oB/3cVC/4P/g/+bzYU/F9CqeD/EkPB/0UWC/v/dRn8 3y37v26xGPzfEk8B/xdVL8b+jyv4v8hQVzXwgP5PwP+l+b+qgf+LDAX/V2L/v1pX2f0fg/+7 F/93uv3/fK8M/u966ue8/k/bhiu3/zvb/n+00VsR/xckTAn/F5rxIv6POhJF/B81ePB/q/2f 7LPV/m9wDMbg/xj83xuhZkoF/7cQ5cH/5fN/9iHsv2gtE9rA0THch47o/zrVCP+X1//Vgrv9 /4QJXaVV/q9xk1IhG4SC/4P/myjV9v6PmeqA/o838H9I0Sn4v3bLGHH+T3n/Z/gDg//bPrm7 HP4vft4b/i+9VPB/Cd2KUv6vugH/F4wR/N8d+L8G/u9+/J9k8H/ToeD/ugz+b87/cQX/lxrq gP5PwP/B/82fQPi/xFAH839awf9lCgX/l9n/Nf6bwv9FhYL/u1P/R8WB/1viKab932DV7Wr/ 1wyzef/X9Nlq/ze0L4NQW/s/1tQz/o8Ofjj/R9UN/g/+b5A28H9Sn8j/8Tq7/wulYpdJGz9I DNnKJz4PvdSQncr/NbXJ7f+cEoH/izmBbDf/Z781/F9kqfbyf6Fh+s4uEvzfbKkW+r9K5vZ/ biXn3v6v9nMkOf2f/dbwf5GlOrP/qyv4P/g/+L8soWZKBf+3EOXB/+X0f/Q8Mw6LrPZ/w2Ow l53yjuX/OtW4p//jYSIgn//jcm//1wgjnf/TSq0NZTvI7syEjGH/v+38n1/8fTD/p10NzOv/ 3Ah/b/+n6uz+T8D/IUUn8n9qU2oX5/807f8nHhj83/bJ3eXwf/Hz3vB/6aWC/0voVpzI/0ka wuZ8p27g/+D/6LdHGfxfmv/jAv4vQ6ng/+7B/9Ut/F9qqAP6P+z/B/8H/3cRCv4P/m/iY/B/ 8H9TxYL/g/+b+NiW/o+FNcTwf0s8xaT/q7P7P7ewA/4vrgqOli2Lupj/q9SM/6ORN/zfxHzC yP818H9p/s+IYv7P7O7/uv3/ZJvybBxPXZi5/f+8jRHGJLxXYjXdm/Ru6qD7/9nB3IT/U5VS uf2frcw34P/oBMP/veH/3MakJ/J/nKYb4f9ux//ZjvQB/R+b83/ds+Yu/Z+Y9X/0HCzi/4Ls pgmtbf0fta1F/B+drSL+jx65Jfb/q/3Pi/g/6v3C/zH4v9HV2iwU/B/830yoUaGGQ+bj+D8V 5hwT2sDRMfpQO/o/gn9Z/d8Q5cH/5fN/bc057f+3OpTb+E+/ZAz+D/4vxv8pmd3/qf39n1TZ 9/9T2P8PKT4F/8e3jBHn/wz5P/XA4P+2T+4uh/+Ln/eG/0svFfxfQreikP8TQu3u/0L3vcj+ f7QeBv5vyQrzKf+nFPwf/B/8X1qp4P/uwf9pAf+XGup4/k8p+D/4v/kTCP+XGOpg/q/h8H+Z QsH/wf+NzyD8X3oo+L/llf3c/i8sn8q5/5+B/4sMdXv+r4b/g/8r4f+qBv4vMtR46kLA/0W2 Fsv8nzTNIf1fmGMv4f8C/LtL/+fG+PB/caXay/+5lh3+L6pUC/2ffwcC/zcVaun+f1QHivi/ ILtpQmtT/xcGPQX8H8G/Qv5v0DPd2P/RYm34v+vhAfwfZfB/S0PNlAr+byHKg//L6P/qilMm 1ocaHcP3Aw/o/wz83xb+Twkj3P5/drzSrA3Fm8q9ngwZg//bzv/J2mfwf6/7P94c0v9h/z+k +BT8n9gyRpz/q8n/mQcG/7d9cnc5/F/8vDf8X3qp4P8SuhWF/J9b1bG7/6OpF/i/BdVib/+n K/i/+/F/fuYZ/m/BOwr4v/RQR/N/2P8P/s//1viP6Av4P/i/+RMI/5cYCv4voVTwf4mh4P8i iwX/12Xwf7ft/+i48H9LPMW0/6OZ5CL+Lyycv0f/x7k6l/+jmg3/B/83SBv4P6nh/yJD7bX/ n6wO6f9cczvh/7j74/d5/R8X8H934/+0Opf/8wsR4f+up37g/7L6PwP/B/83Fwr+D/5vcAzG 4P8Y/N8boWZKBf+3EOXB/2X0f93effTSMW3/Px0G+of0f6qB/8tSqgv/x2XDvf9L2P+vqVwn P2QM/g/+b2//h/3/4P+QKAX/J7eMEeX/REX+jz8w+L/tk7vL4f/i573h/9JLBf+X0K04kf+j F4vwf0uqxe7+z8D/wf/B/6WVCv7vHvwf9v+D//O/NV5E18D/wf/Nn0D4v8RQB/N/WsH/ZQoF /wf/Nz6D8H/poeD/lld2+D/Givi/sAIxzf+FiwX/t6n/G7+Ahv+D/6PTm9//GXFE/1dj/7+J lv02/d/0/n/S1Nn9H/b/uyP/d7L9/6giwP9dT/3A/8H/TYSC/4P/m+pywv/B/y0NBf8H/zcX aqZU8H9vrNvb2f9p6h4Zf5CVoUbH6KXcsfyfNDfg/2gUkdH/yb39nzRCe/+nqZlY6//kS8Zo Rhr+L0Op4P/g//oM/g9pRQr+T20ZI87/cfJ/8oHB/22f3F0O/xc/7w3/l14q+L+EbsWZ/B+9 nCji/2gtC/zfkhXm8H9xrcXN+T+3V2Ne/+feJ8H/JZcK/u8e/B/2/4P/8781XkSn4P/g/+ZP IPxfYij4v4RSwf8lhjqV//PdTPi/uFDwf3fq/+hswf8t8RST/k+HVbcei6z1f/UwY3LO/4WR WOuPlOb/+tWBx/N/fam29n924DPj/+iOgv+bmE8YmjI3cIT/i7pWN7j/Hw+d+3wvEGQN/xd7 Am/L//FWmEP6v7CuDv7vDf8n6lP5P+z/B/9XxP+xOf8XIMfR/B814yX8XxjKlfB/1KMq4f9s vaFP+d7tYfwfjeGK+L8wFi7g/xitKEjyf6NjMAb/x+D/3gg1Uyr4v4UoD/4vn/+zj426z9aF Gh/D9wN39388DBeT/B+dhuD/Wvi/Lfwfr1ulvf/jYm0o3lSuoxoydhP7/wkalh/O//lls/B/ 18Pukf8Tan//p+vc/s+Fgv9DikzB/+ktY8T5P0H+Tz8w+L/tk7vL4f/i573h/9JLtav/o54R /N9VqBv0fzX83734PyOO6f+Gb44P4/90zeD/pkPB/3UZ/B/838TH4P/g/yjB/8H/wf/B/12G gv+7CnVn/s/Qwhn4v6hQ8H/wf/0yOvg/Fre8Ev4P/m9BDYT/YzH3Ffwf/N9UqPHURQP/F9la LPF/9kq18H9n9n+2WpzJ/x1z/z8/Ax2y1f5PDzJ2Kv/XKJnb/7k28ID+T8z4PzpEGf8XltvC /8H/DVJB/4f9/yJDwf/B/82FmikV/N8b6/b29X+C+/nCkK0LNT5GH2pP/0evxxL9Hz3g4P82 9H/2e7iJH65kWIG7yv/VrZsfDhmD/4P/29n/qf33/1OKw/8h3UAK/s9sGSPO/0nyf/UDg//b Prm7HP4vft4b/i+9VPv6P/o5/N8d+L+KBlMl/B9vNgh1Jv/XwP/djf/zU5rwf0veUcD/pYfa 1//RUguZtLZSqkEG/3cI/+dvIvi/JWcQ/i/DCYT/Swy1q//zZ0uF5Z5r/Z8YZPB/8H+36v+6 tfnwf/B/s6GO4//C7C3832r/F5YvJPm/oMTe8n/hxWmS/wvzR/3qwEn/R1OCRfyfCJiMirOl /+tOWQH/x1q6MAfzfzTsgf+bWEOyzP+ZMLSiPsam/s/4GljC/8km6KwC/s83lWX8n/SLCDV1 4hL9H12LG/B/wh88q//j1ZT/M4Yrt45O03211v/5Lxiy2/B/YWl7Cf+nqLqV8H+ORMH/TYZa 5v8K7v/nOmeF/J+XdGX8n1J9tnaJ+fAY7gvt7/8qXs7/0X1Xwv/5vkUZ/xcWE5Xwf6bc/n+h uhXxf9SRKOL/qMEr4P80jUyL+L8wFi7i/6hmp/m/wTEYg/9j8H9vhJopFfzfQpQH/5fR/zWe W4dspf8bHaMPtaP/E7Q6lf4C2Vr/R4OzkN2C/xP0x++kSAlF3YQu66Tcbv7PSGU7Z1y2XCb4 P//eMGTsRvyfP+7h/J+vesfyf3ZkL1hm/9fs7v905f6ONPwf0t4p+L96yxhx/k95/2f4A4P/ 2z65uxz+L37eG/4vvVTwfwndCvi/yFDwf5mHVvB/V6HuzP/5ZgL+b8k7Cvi/9FDwf/B/V9UC /u8qFvwf/B/832wo+L+EUsH/JYaC/4ssFvxfl8H/wf/B/7E3llfC/8H/LaiB8H8s5r6C/4P/ mwoF/1fA/2lbWuf/VKPW18DW+N8KGfzfiuYW/g/+b+IWhv+D/1vSkYb/izyB1TCD/4P/o6PA /20RCv4P/m8u1Eyp4P/eWLe3r/+TxNtCti7U+Bh9KPg/+L+JUo39n7bdF+U2aG7a9f7PGPdb IWPwf/B/Uf7P3krseP5Pcfg/pBtIwf81W8aI83+a/J98YPB/2yd3l8P/xc97w/+ll2pX/0cz WQfzf9JPoub0f/bnu/s/ocLb6RL+z2wQ6kT+r1bH9H/hZjiW//OvQ0K22v+1g4zB/8H/zYba 1//REm/4vyWhzuP/dOWPm9H/SS3g/+D/Zk8g/F9iqD39Xy2z+z9ewf9lCgX/l9n/0Zos+L+o UPB/8H/9Mroz+T9F3TfjF3as9X/htXoYefM5/xd6gn7qYq3/48Nszv9x5StBRv9nh03T/o8N l7Fv6/84LYXN6f+EmPF/huYpjuX/NDUX8H8Ta0iW+T+yLyX8n6w7MtWXMdH/yTn/J7L/AUHe TPu/ui7m/2r/20LzFDxUB5NBi01vwf/RDbW9/1N1ZZz/sz3o9e8qWu1XrYXsRvwfneAS/i/0 0Ev4P57d/9lqcSb/59lFEf9nXAOb1//JOf/nvyj836Ie05T/8ye4kP/TQeMV8H/+T5AU8n/U jJfwf2FhfRH/R0Uo4v/CeNv3bjf2fxSqhP/TdPoL+D8W9vAp4P8YdXOS/N/oGIzB/zH4vzdC zZQK/m8hyoP/y+j/lDB9ttL/jY7Rh9rT/9GroET/R/X2lvwfrf5I8n/dn0jqZnR29n9K1naA yoUxCf5P+z8eFTJ2I/7PX5ij+T+afzmW/xPSvVTK6/+U2t3/GXdh4P+Q9k7B/7Vbxojzf4b8 n35g8H/bJ3eXw//Fz3vD/6WXCv4voVtxIv8nK/g/+D/4v4Q2cNL/0TrlkK30f2Gtc8gY/B/8 32wo+D/4v6tqAf93FQv+D/4P/m82FPxfQqng/xJDwf9FFgv+r8vg/+D/4P/YG8sr4f/g/xbU QPg/FnNfwf/B/02Fgv8r4f/sdXH+TzQqxf8J2WfwfyuaW/g/+L+JWxj+D/5vSUca/i/yBFbD DP4P/o8OAv+3RSj4P/i/uVAzpYL/e2Pd3s7+r6aJYcpW+r/RMdzbDvi/iVDwf1P+Tza1fdLb h3lNY6p1/q9q+UvG4P/g/2L8ny1Vdv93A/v/tfB/SLeQyP/pTaldnP+rvf/T5oHB/22f3F0O /xc/7w3/l16qff3fFquW4f8iS7XI/wmT/Z06/B/8X/jKo2zW/4Wvcij/p1pf5+D/FryjgP9L D7Wz//PHzen/tID/Sw21v//zMzDwf0vOIPxfhhMI/5cYalf/x2k9Kvwf/N8J/B+NwOD/okLB /8H/9cvoTuX/QowU/8eDXrgd/xdenJIhWuv/zDCb9X/h1X0J/0fns4j/03JwHo/i/xSdwIz+ zw0cz+T/qO5rshBr/Z8cZrP+z6/RL+L/RBtClfB/imX2f0bN+D8vGoTig0q01v/VpILMnP/r phPoEbqp/5PZ/R/TU/5PNrzWto3gKTWwVb7qhexs/i9UmzL+T8H/LbyvZvyf75UV8X+ub1HI //lnSiH/x/tstf/jw4zJ/f2fe8Tn9X9i1v/RfVXC//k5kqz+j4sZ/0evsMr4v26k4v9jU/8X ql4J/xeaiaP5PzonJfyfoeUBRfyf7LPV/k8OM/g/Bv/3RqiZUsH/LUR58H85/Z+f15D0/mWt /xsew31yf/9H3THRJKxd5mFKIPx1i/oG/B91+qTvVKz2f/UwY83e/s8OVFq3MpBzsTaUvVJu zB4ydiP+z9eew/m/2meH8n9VWx3S/7k/4gX/h7R3Cv6Pbxkjyv/Jivwff2Dwf9snd5fD/8XP e8P/pZcK/i+hW1HI/7nOEvxfYqgT+b+mgv+7F/+H/f/g/+D/Yu6rsf+TBv4vNdQB/Z+tFvB/ saHg/zKPD+D/Ek/gtP9rsvs/Bv+X/BSB/0s+gdP7/1GzB/8H/zcb6ij+j1YFwv9NhoL/y+n/ OJ/2f6HulfB/osnu/0wF/xdZqpEpszUM/i/uWo39H2vFtP9TOrv/Y+X8HxOl/J8UTTH/V+3v /xTNf1O21v+Fpkb1nYtr/2fqSnr/x6uE/f+U76SG7Db8X1hZHJ4lK/3fJcqb3v9PFvN/wnUI 8vq/hsP/RZZqmf9r3AnM6//YnP/z7WzIVvs/M8hYSf9XHdD/OUQ+7f9M2EjlLv2fo/GT/o86 2kX8X1huW8L/UY+qhP/rhvhF/J/qs239n6FSH87/6T5L2/+vy+D/GPzfG6FmSgX/txDlwf/l 9H++Ix2y1fv/DY7BbmL/v/z+j9+A/6OeWFb/V+3s/4xUtv9iB3JtmAhc5f/8rHbI2E34P1n5 PsvR/J+/J47m/+pj7v8H/4d0Cyn4P7FljDj/J8j/qQcG/7d9cnc5/F/8vDf8X3qp9vV/NCd0 LP8n/LfN6f9ko/b3f3oLlAf/lxhq2v8Z+L978X/KTyjB/y15RwH/lx7qYP6PNdj/L/q+uqoW h/N/bhkn/F9sKPi/zOMD+L/EEwj/lxgK/u8q1L35v9pXbfi/qFDwf3fp/xjJDfi/JZ3Oaf8X hJd2H1vt/8IZrC9CXfo/02er/Z8YZgX93+AEjv0fHTyn/xN1Mf/H5vyfagfnEf5v1v9x+L80 /yeb3f1fUEOZXyAcz/8JNef/wtvTI/m/mlda20avbRLeVbTSLzULmfsk/F/UCZwINb3/n3sm 5vV/Wp3L//m1/0X8n9vJIav/Cw3Td3aRyvo/0Wer/Z8YZrv7P6OEyu3/fGWf9n/06LxP/8dm /R814yX8XwCURfwflQr+b63/o05fGf9HbWQR/zdY3bza/12ukIb/Y/B/r4WaKRX830KUB/+X 0f8Z35uQ1MVY6f9Gx3A9ov39H82k5vR/3a6Ge/q/JvxdoyP5v9pNWPCqVVKsDWWHFO4tYsgY /N92/s/Pch7N/wmV3f+J3f1fW7lrBf+HtHcK/k9uGSPO/0nyf+aBwf9tn9xdDv8XP+8N/5de Kvi/hG5FKf8n5vwfdXxL+L9tUN60/5Nig1An8n+tgP87sf/jAv4vQ6ng/+7A//Gqhf9LDQX/ dx0L/g/+D/5vNhT8X0Kp4P8SQ53J/xnqM8H/RYWC/4P/65fRwf+xqOWVt+f/DFGrjP6vR3kH 8n8OpMD/xZUK/i+r/zN6d/8XiBz83/zittvxf/4QIVvt/8Qgc9Brwv81rWi9/zNifQ1saWlh yPwGivB/MSdwItT0/n+uzuX1f+4WPpH/C/NK4Sm80v9dbt1UyP+5bsyU/6srf4iQrfZ/zSBj 5/J/+ff/Y7P+b9Qw3Zv/m9//j5px+L/V/k/32Wr/d7nue8b/1X222v+1w+xs/q/ts9X+rx1m 8H8M/u+NUDOlgv9biPLg/zL6P0kTw5KvN9DjY9hnuID/mwgF/zfl/xojbF+TV01DxVnp/9wS m5ANQsH/wf9NlOrS//Emu//bf/+/Dfyfvb/g/5BiU/B/assYcf5Pef9nqgcG/7d9cnc5/F/8 vDf8X3qp4P8SuhWF/J+tW3P+j/rpJfb/o0mKnO/UDfzfRv7PnTn4v0Whdvd/fvo5r/8z8H8Z SgX/dw/+Txr4v9RQB/R/HP4P/m/+BML/JYY6mP8TNfxfplDwf/B/4zMI/5ce6iz+L6whhv9b 4ikm/V9YveKztf5vzGxUM+P/hqubV/u/ywW+pfyfUyKH839uTnXa/xm6MPB/8H+DVHL/P2of cvo/s7//owXfou4Y8zr/NzTQbmXMpP9r/SkTJty2K/0fXRPq1bnlKjP+j0pZZP+/lmX2f665 vfJ/vDKae/8nEprbVvgBY8hs7/hc/i+gpAL+T7p39vB/k6GW+T/f8ncvlNb6PzPMCvq/Zs7/ +cYvZKv9XzvIWEH/x8Xu/k8J+L9F/o/N+b8wVVvC/1HjV8T/hf1sS+7/B//3ZrWA/4P/ezXU sFDbhYL/g/+bCTUq1HDIfBj/J0zdZyv93+gYfahb8H9mfagX/xdeLgn4vyylGvk/O67SVev8 n0nZ/0/T/n8a+/9t7P88/IP/mxh235r/022b2/+5UsH/ISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhnTL9f7PxnScACAwA --------------010504000402070106040404-- From romieu@fr.zoreil.com Mon Feb 21 13:39:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 13:39:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LLdeNl028426 for ; Mon, 21 Feb 2005 13:39:41 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LLaF7r028730; Mon, 21 Feb 2005 22:36:15 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LLaAUX028729; Mon, 21 Feb 2005 22:36:10 +0100 Date: Mon, 21 Feb 2005 22:36:10 +0100 From: Francois Romieu To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! Message-ID: <20050221213610.GC26248@electric-eye.fr.zoreil.com> References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A4FFA.7090003@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1917 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: 292 Lines: 9 Christian Schmid : > I started it after one break-cyclus and stopped it immedately after the > next break-cyclus ended. I'd welcome several cycles to feed the data through gnuplot. A sample based on 15 minutes or more would not hurt: I speak perl too. -- Ueimor From tgraf@suug.ch Mon Feb 21 13:41:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 13:41:37 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LLfWFA029055 for ; Mon, 21 Feb 2005 13:41:33 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 57D6782; Mon, 21 Feb 2005 22:41:09 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 796DB1C0EA; Mon, 21 Feb 2005 22:41:51 +0100 (CET) Date: Mon, 21 Feb 2005 22:41:51 +0100 From: Thomas Graf To: jamal Cc: Andi Kleen , Leonid Grossman , "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050221214151.GZ31837@postel.suug.ch> References: <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> <20050221164006.GY31837@postel.suug.ch> <1109005385.1074.68.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109005385.1074.68.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1336 Lines: 30 * jamal <1109005385.1074.68.camel@jzny.localdomain> 2005-02-21 12:03 > Most of this came after SUCON actually after the BSD folks claimed to be > doing 1Mpps forwarding (only to find out they used CSA later). Got it, found your patches. > Look at the case where we have 32 bit bus in those slides; in that > scenario we do see an improvement with batching (but really for the > wrong reasons). The next piece of hardware we see infact a degradation > in perfomance. I see, thanks for the elaboration. > I said in some cases it does make sense (as in the case of 32 bit bus > above) in some it doesnt (as in the case of most xeon boards, fast CPU, > fast PCI-X). Yes of course, I left the 32bit bus out, it shouldn't be used as a data point for optimizations since everyone interested in such optimizations is unlikely to use such hardware. > Any solution should be where things work all the time or most of the > time and are not very hardware specific. If we can hit 95% of the cases, > then it would make sense to do submit such the patch. Otherwise > it was a good exercise for me, but useless in general. I do plan to work > on trying out some heuristics like discovering a few things (such as CPU > speed, runtime congestion etc) before activating the batching code. > Wont have time for at least 1 month. Agreed. Thanks. From webmaster@rapidforum.com Mon Feb 21 14:11:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 14:11:30 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LMBNYP030459 for ; Mon, 21 Feb 2005 14:11:24 -0800 Received: (qmail 26420 invoked by uid 1004); 21 Feb 2005 22:11:23 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 22:11:23 -0000 Message-ID: <421A5C6D.7080607@rapidforum.com> Date: Mon, 21 Feb 2005 23:10:53 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> <20050221213610.GC26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221213610.GC26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 416 Lines: 11 Francois Romieu wrote: > Christian Schmid : > >>I started it after one break-cyclus and stopped it immedately after the >>next break-cyclus ended. > > > I'd welcome several cycles to feed the data through gnuplot. > A sample based on 15 minutes or more would not hurt: I speak perl too. Hm I have already restarted the server. There is no other way to make this behaviour go away.... From shemminger@osdl.org Mon Feb 21 14:44:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 14:44:35 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LMiUOj031455 for ; Mon, 21 Feb 2005 14:44:31 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1LMiOqi023557 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Feb 2005 14:44:25 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1LMiOIX020231; Mon, 21 Feb 2005 14:44:24 -0800 Date: Mon, 21 Feb 2005 14:44:37 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: Netdev Subject: Re: Intel and TOE in the news Message-ID: <20050221144437.555497bc@dxpl.pdx.osdl.net> In-Reply-To: <4216B62D.6000502@pobox.com> References: <4216B62D.6000502@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1920 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: 99 Lines: 2 What Tcp Offload Engine's already exist and are shipping on Linux? How do they interface and work? From shemminger@osdl.org Mon Feb 21 14:56:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 14:56:06 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LMu0Cb032117 for ; Mon, 21 Feb 2005 14:56:01 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1LMtsqi024390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Feb 2005 14:55:55 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1LMtsAp020754; Mon, 21 Feb 2005 14:55:54 -0800 Date: Mon, 21 Feb 2005 14:56:07 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] BIC TCP beta calculation error Message-ID: <20050221145607.67f05ced@dxpl.pdx.osdl.net> In-Reply-To: <20050221095559.18128947.davem@redhat.com> References: <200502211535.j1LFZwun012564@uni02mr.unity.ncsu.edu> <20050221095559.18128947.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1921 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: 3153 Lines: 97 Dave, did you get this already? ------------ Yee-Ting Li and David Keith identified (in great detail) a problem with the BIC TCP in 2.6. The issue was a BETA/2 when BETA*2 was expected. Here is a better fix based on BIC TCP 1.1 code. Test description and results http://developer.osdl.org/shemminger/bic-beta-patch.pdf Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-02-21 12:55:57 -08:00 +++ b/include/linux/sysctl.h 2005-02-21 12:55:57 -08:00 @@ -344,6 +344,7 @@ NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, + NET_TCP_BIC_BETA=108, }; enum { diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2005-02-21 12:55:57 -08:00 +++ b/include/net/tcp.h 2005-02-21 12:55:57 -08:00 @@ -505,9 +505,8 @@ # define TCP_TW_RECYCLE_TICK (12+2-TCP_TW_RECYCLE_SLOTS_LOG) #endif -#define BICTCP_1_OVER_BETA 8 /* - * Fast recovery - * multiplicative decrease factor +#define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation + * max_cwnd = snd_cwnd * beta */ #define BICTCP_MAX_INCREMENT 32 /* * Limit on the amount of @@ -606,6 +605,7 @@ extern int sysctl_tcp_bic; extern int sysctl_tcp_bic_fast_convergence; extern int sysctl_tcp_bic_low_window; +extern int sysctl_tcp_bic_beta; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; @@ -1244,15 +1244,16 @@ if (tcp_is_bic(tp)) { if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) - tp->bictcp.last_max_cwnd - = (tp->snd_cwnd * (2*BICTCP_1_OVER_BETA-1)) - / (BICTCP_1_OVER_BETA/2); + tp->bictcp.last_max_cwnd = (tp->snd_cwnd * + (BICTCP_BETA_SCALE + + sysctl_tcp_bic_beta)) + / (2 * BICTCP_BETA_SCALE); else tp->bictcp.last_max_cwnd = tp->snd_cwnd; if (tp->snd_cwnd > sysctl_tcp_bic_low_window) - return max(tp->snd_cwnd - (tp->snd_cwnd/BICTCP_1_OVER_BETA), - 2U); + return max((tp->snd_cwnd * sysctl_tcp_bic_beta) + / BICTCP_BETA_SCALE, 2U); } return max(tp->snd_cwnd >> 1U, 2U); diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c 2005-02-21 12:55:57 -08:00 +++ b/net/ipv4/sysctl_net_ipv4.c 2005-02-21 12:55:57 -08:00 @@ -682,6 +682,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_BIC_BETA, + .procname = "tcp_bic_beta", + .data = &sysctl_tcp_bic_beta, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2005-02-21 12:55:57 -08:00 +++ b/net/ipv4/tcp_input.c 2005-02-21 12:55:57 -08:00 @@ -102,6 +102,7 @@ int sysctl_tcp_bic = 1; int sysctl_tcp_bic_fast_convergence = 1; int sysctl_tcp_bic_low_window = 14; +int sysctl_tcp_bic_beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ From davem@redhat.com Mon Feb 21 15:28:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:28:06 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNS0ae001075 for ; Mon, 21 Feb 2005 15:28:01 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1LNRs4N027620; Mon, 21 Feb 2005 18:27:54 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1LNRsK26949; Mon, 21 Feb 2005 18:27:54 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with SMTP id j1LNRrmY007905; Mon, 21 Feb 2005 18:27:53 -0500 Date: Mon, 21 Feb 2005 15:27:31 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] BIC TCP beta calculation error Message-Id: <20050221152731.7cbf8cee.davem@redhat.com> In-Reply-To: <20050221145607.67f05ced@dxpl.pdx.osdl.net> References: <200502211535.j1LFZwun012564@uni02mr.unity.ncsu.edu> <20050221095559.18128947.davem@redhat.com> <20050221145607.67f05ced@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 151 Lines: 6 On Mon, 21 Feb 2005 14:56:07 -0800 Stephen Hemminger wrote: > Dave, did you get this already? Yes, I'll integrate later today. From romieu@fr.zoreil.com Mon Feb 21 15:55:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:55:50 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNtg65002682 for ; Mon, 21 Feb 2005 15:55:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNpa6s031616; Tue, 22 Feb 2005 00:51:36 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNpQ2n031615; Tue, 22 Feb 2005 00:51:26 +0100 Date: Tue, 22 Feb 2005 00:51:25 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 0/5] r8169: intro Message-ID: <20050221235125.GD26248@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1924 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: 1263 Lines: 31 1 - The upcoming messages contain a serie of patches which fixes minor issues or moderately clean the code. 2 - The current 2.6.11-rc4 r8169 driver would benefit from several patches availables in your -netdev serie: - the extra netif_poll_enable() in rtl8169_close() -> without it the driver can not stand an open/traffic/close/open sequence ("interrupt 0005 taken in poll" and the story is over); - the endianness changes for vlan -> without it a big-endian host can't reach a little endian host I tested it through: - (old code; little endian) <-> (new code; little endian) -> ok - (new code; big endian) <-> (new code; little endian) -> ok - the endianness changes for Rx csum -> this one hits big-endian hosts as well but the fix is more trivial and it does not bite too hard. Imho it would be safe to push the whole queue for inclusion in 2.6.11 but the changes above are enough if you simply want the smallest set of changes to improve the behavior of the driver. The driver is however not perfect as I can still trigger the pesky "interrupt xyz taken in poll" error when asking for a change of mtu at the wrong time. -- Ueimor From romieu@fr.zoreil.com Mon Feb 21 15:55:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:55:52 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNtibv002686 for ; Mon, 21 Feb 2005 15:55:45 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNst4n031738; Tue, 22 Feb 2005 00:54:55 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNsoY7031737; Tue, 22 Feb 2005 00:54:50 +0100 Date: Tue, 22 Feb 2005 00:54:50 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 2/5] r8169: skb alignment nitpicking Message-ID: <20050221235450.GB31723@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221235301.GA31723@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1926 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: 1129 Lines: 36 Nail an overrun in skb alignment and remove the relevant magic variable. Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-410 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-410 2005-02-17 22:13:04.000000000 +0100 +++ b/drivers/net/r8169.c 2005-02-17 22:17:25.000000000 +0100 @@ -1697,11 +1697,11 @@ static int rtl8169_alloc_rx_skb(struct p dma_addr_t mapping; int ret = 0; - skb = dev_alloc_skb(rx_buf_sz); + skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); if (!skb) goto err_out; - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); *sk_buff = skb; mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, @@ -2140,9 +2140,9 @@ static inline int rtl8169_try_rx_copy(st if (pkt_size < rx_copybreak) { struct sk_buff *skb; - skb = dev_alloc_skb(pkt_size + 2); + skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (skb) { - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); *sk_buff = skb; rtl8169_return_to_asic(desc, rx_buf_sz); _ From romieu@fr.zoreil.com Mon Feb 21 15:55:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:55:51 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNtgC8002681 for ; Mon, 21 Feb 2005 15:55:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNr6h6031731; Tue, 22 Feb 2005 00:53:06 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNr141031730; Tue, 22 Feb 2005 00:53:01 +0100 Date: Tue, 22 Feb 2005 00:53:01 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 1/5] r8169: fix rx skb allocation error logging Message-ID: <20050221235301.GA31723@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221235125.GD26248@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1925 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: 1047 Lines: 36 Fix rx skb allocation error logging Signed arithmetic is not required as rtl8169_rx_fill() return belongs to the [0; NUM_RX_DESC] interval. Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-400 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-400 2005-02-17 21:50:09.820173216 +0100 +++ b/drivers/net/r8169.c 2005-02-17 22:00:00.210450784 +0100 @@ -2156,8 +2156,8 @@ static int rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void __iomem *ioaddr) { - unsigned int cur_rx, rx_left, count; - int delta; + unsigned int cur_rx, rx_left; + unsigned int delta, count; assert(dev != NULL); assert(tp != NULL); @@ -2225,10 +2225,8 @@ rtl8169_rx_interrupt(struct net_device * tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta < 0) { + if (!delta && count) printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); - delta = 0; - } tp->dirty_rx += delta; /* _ From romieu@fr.zoreil.com Mon Feb 21 15:59:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:59:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNxgZ0004370 for ; Mon, 21 Feb 2005 15:59:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNuGlF031822; Tue, 22 Feb 2005 00:56:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNuBW1031821; Tue, 22 Feb 2005 00:56:11 +0100 Date: Tue, 22 Feb 2005 00:56:11 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 3/5] r8169: removal of unused #define Message-ID: <20050221235611.GC31723@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> <20050221235450.GB31723@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221235450.GB31723@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1927 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: 697 Lines: 19 Removal of unused #define Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-420 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-420 2005-02-18 21:24:40.664919294 +0100 +++ b/drivers/net/r8169.c 2005-02-18 22:19:14.888302521 +0100 @@ -113,8 +113,6 @@ static int multicast_filter_limit = 32; /* MAC address length*/ #define MAC_ADDR_LEN 6 -#define TX_FIFO_THRESH 256 /* In bytes */ - #define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ _ From romieu@fr.zoreil.com Mon Feb 21 15:59:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:59:54 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNxiRa004371 for ; Mon, 21 Feb 2005 15:59:45 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNvNnK031828; Tue, 22 Feb 2005 00:57:23 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNvIWP031827; Tue, 22 Feb 2005 00:57:18 +0100 Date: Tue, 22 Feb 2005 00:57:18 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 4/5] r8169: uniformize comments Message-ID: <20050221235718.GD31723@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> <20050221235450.GB31723@electric-eye.fr.zoreil.com> <20050221235611.GC31723@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221235611.GC31723@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1929 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: 8498 Lines: 292 Uniformize comments Signed-off-by: Jon Mason Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-430 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-430 2005-02-18 22:21:13.590966183 +0100 +++ b/drivers/net/r8169.c 2005-02-18 22:32:43.918377456 +0100 @@ -48,7 +48,7 @@ VERSION 2.2LK <2005/01/25> - VLAN - baby (< 7200) Jumbo frames support - Merge of Realtek's version 2.2 (new phy) -*/ + */ #include #include @@ -107,13 +107,13 @@ static int num_media = 0; static int max_interrupt_work = 20; /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast). - The RTL chips use a 64 element hash table based on the Ethernet CRC. */ + The RTL chips use a 64 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 32; -/* MAC address length*/ +/* MAC address length */ #define MAC_ADDR_LEN 6 -#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ +#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ @@ -226,7 +226,7 @@ enum RTL8169_registers { }; enum RTL8169_register_content { - /*InterruptStatusBits */ + /* InterruptStatusBits */ SYSErr = 0x8000, PCSTimeout = 0x4000, SWInt = 0x0100, @@ -239,23 +239,23 @@ enum RTL8169_register_content { RxErr = 0x02, RxOK = 0x01, - /*RxStatusDesc */ + /* RxStatusDesc */ RxRES = 0x00200000, RxCRC = 0x00080000, RxRUNT = 0x00100000, RxRWT = 0x00400000, - /*ChipCmdBits */ + /* ChipCmdBits */ CmdReset = 0x10, CmdRxEnb = 0x08, CmdTxEnb = 0x04, RxBufEmpty = 0x01, - /*Cfg9346Bits */ + /* Cfg9346Bits */ Cfg9346_Lock = 0x00, Cfg9346_Unlock = 0xC0, - /*rx_mode_bits */ + /* rx_mode_bits */ AcceptErr = 0x20, AcceptRunt = 0x10, AcceptBroadcast = 0x08, @@ -263,11 +263,11 @@ enum RTL8169_register_content { AcceptMyPhys = 0x02, AcceptAllPhys = 0x01, - /*RxConfigBits */ + /* RxConfigBits */ RxCfgFIFOShift = 13, RxCfgDMAShift = 8, - /*TxConfigBits */ + /* TxConfigBits */ TxInterFrameGapShift = 24, TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ @@ -285,7 +285,7 @@ enum RTL8169_register_content { PCIDAC = (1 << 4), PCIMulRW = (1 << 3), - /*rtl8169_PHYstatus */ + /* rtl8169_PHYstatus */ TBI_Enable = 0x80, TxFlowCtrl = 0x40, RxFlowCtrl = 0x20, @@ -295,38 +295,38 @@ enum RTL8169_register_content { LinkStatus = 0x02, FullDup = 0x01, - /*GIGABIT_PHY_registers */ + /* GIGABIT_PHY_registers */ PHY_CTRL_REG = 0, PHY_STAT_REG = 1, PHY_AUTO_NEGO_REG = 4, PHY_1000_CTRL_REG = 9, - /*GIGABIT_PHY_REG_BIT */ + /* GIGABIT_PHY_REG_BIT */ PHY_Restart_Auto_Nego = 0x0200, PHY_Enable_Auto_Nego = 0x1000, - //PHY_STAT_REG = 1; + /* PHY_STAT_REG = 1 */ PHY_Auto_Neco_Comp = 0x0020, - //PHY_AUTO_NEGO_REG = 4; + /* PHY_AUTO_NEGO_REG = 4 */ PHY_Cap_10_Half = 0x0020, PHY_Cap_10_Full = 0x0040, PHY_Cap_100_Half = 0x0080, PHY_Cap_100_Full = 0x0100, - //PHY_1000_CTRL_REG = 9; + /* PHY_1000_CTRL_REG = 9 */ PHY_Cap_1000_Full = 0x0200, PHY_Cap_Null = 0x0, - /*_MediaType*/ + /* _MediaType */ _10_Half = 0x01, _10_Full = 0x02, _100_Half = 0x04, _100_Full = 0x08, _1000_Full = 0x10, - /*_TBICSRBit*/ + /* _TBICSRBit */ TBILinkOK = 0x02000000, }; @@ -382,7 +382,7 @@ struct ring_info { struct rtl8169_private { void __iomem *mmio_addr; /* memory map physical address */ - struct pci_dev *pci_dev; /* Index of PCI device */ + struct pci_dev *pci_dev; /* Index of PCI device */ struct net_device_stats stats; /* statistics of net device */ spinlock_t lock; /* spin lock flag */ int chipset; @@ -463,7 +463,7 @@ static void mdio_write(void __iomem *ioa udelay(1000); for (i = 2000; i > 0; i--) { - // Check if the RTL8169 has completed writing to the specified MII register + /* Check if the RTL8169 has completed writing to the specified MII register */ if (!(RTL_R32(PHYAR) & 0x80000000)) break; udelay(100); @@ -478,7 +478,7 @@ static int mdio_read(void __iomem *ioadd udelay(1000); for (i = 2000; i > 0; i--) { - // Check if the RTL8169 has completed retrieving data from the specified MII register + /* Check if the RTL8169 has completed retrieving data from the specified MII register */ if (RTL_R32(PHYAR) & 0x80000000) { value = (int) (RTL_R32(PHYAR) & 0xFFFF); break; @@ -1037,7 +1037,7 @@ static void rtl8169_hw_phy_config(struct return; } - // phy config for RTL8169s mac_version C chip + /* phy config for RTL8169s mac_version C chip */ mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1 mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000 mdio_write(ioaddr, 24, 0x65c7); //w 24 15 0 65c7 @@ -1159,7 +1159,7 @@ rtl8169_init_board(struct pci_dev *pdev, assert(ioaddr_out != NULL); - // dev zeroed in alloc_etherdev + /* dev zeroed in alloc_etherdev */ dev = alloc_etherdev(sizeof (*tp)); if (dev == NULL) { printk(KERN_ERR PFX "unable to alloc new ethernet\n"); @@ -1170,7 +1170,7 @@ rtl8169_init_board(struct pci_dev *pdev, SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); - // enable device (incl. PCI PM wakeup and hotplug setup) + /* enable device (incl. PCI PM wakeup and hotplug setup) */ rc = pci_enable_device(pdev); if (rc) { printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); @@ -1194,14 +1194,14 @@ rtl8169_init_board(struct pci_dev *pdev, goto err_out_mwi; } - // make sure PCI base addr 1 is MMIO + /* make sure PCI base addr 1 is MMIO */ if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) { printk(KERN_ERR PFX "region #1 not an MMIO resource, aborting\n"); rc = -ENODEV; goto err_out_mwi; } - // check for weird/broken PCI region reporting + /* check for weird/broken PCI region reporting */ if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) { printk(KERN_ERR PFX "Invalid PCI region size(s), aborting\n"); rc = -ENODEV; @@ -1231,7 +1231,7 @@ rtl8169_init_board(struct pci_dev *pdev, pci_set_master(pdev); - // ioremap MMIO region + /* ioremap MMIO region */ ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE); if (ioaddr == NULL) { printk(KERN_ERR PFX "cannot remap MMIO, aborting\n"); @@ -1239,20 +1239,20 @@ rtl8169_init_board(struct pci_dev *pdev, goto err_out_free_res; } - // Unneeded ? Don't mess with Mrs. Murphy. + /* Unneeded ? Don't mess with Mrs. Murphy. */ rtl8169_irq_mask_and_ack(ioaddr); - // Soft reset the chip. + /* Soft reset the chip. */ RTL_W8(ChipCmd, CmdReset); - // Check that the chip has finished the reset. + /* Check that the chip has finished the reset. */ for (i = 1000; i > 0; i--) { if ((RTL_R8(ChipCmd) & CmdReset) == 0) break; udelay(10); } - // Identify chip attached to board + /* Identify chip attached to board */ rtl8169_get_mac_version(tp, ioaddr); rtl8169_get_phy_version(tp, ioaddr); @@ -1340,7 +1340,7 @@ rtl8169_init_one(struct pci_dev *pdev, c tp->link_ok = rtl8169_xmii_link_ok; } - // Get MAC address. FIXME: read EEPROM + /* Get MAC address. FIXME: read EEPROM */ for (i = 0; i < MAC_ADDR_LEN; i++) dev->dev_addr[i] = RTL_R8(MAC0 + i); @@ -1578,10 +1578,10 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); - // For gigabit rtl8169, MTU + header + CRC + VLAN + /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); - // Set Rx Config register + /* Set Rx Config register */ i = rtl8169_rx_config | (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); RTL_W32(RxConfig, i); @@ -2009,7 +2009,7 @@ static int rtl8169_start_xmit(struct sk_ smp_wmb(); - RTL_W8(TxPoll, 0x40); //set polling bit + RTL_W8(TxPoll, 0x40); /* set polling bit */ if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) { netif_stop_queue(dev); @@ -2290,11 +2290,11 @@ rtl8169_interrupt(int irq, void *dev_ins } break; #else - // Rx interrupt + /* Rx interrupt */ if (status & (RxOK | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } - // Tx interrupt + /* Tx interrupt */ if (status & (TxOK | TxErr)) rtl8169_tx_interrupt(dev, tp, ioaddr); #endif _ From romieu@fr.zoreil.com Mon Feb 21 15:59:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:59:53 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNxjti004372 for ; Mon, 21 Feb 2005 15:59:46 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1LNwdAo031840; Tue, 22 Feb 2005 00:58:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1LNwYwS031839; Tue, 22 Feb 2005 00:58:34 +0100 Date: Tue, 22 Feb 2005 00:58:34 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: [patch 2.6.11-rc4-netdev1 5/5] r8169: literate PCI ID Message-ID: <20050221235834.GE31723@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> <20050221235450.GB31723@electric-eye.fr.zoreil.com> <20050221235611.GC31723@electric-eye.fr.zoreil.com> <20050221235718.GD31723@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221235718.GD31723@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1928 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: 1188 Lines: 35 De-obfuscate supported PCI ID Non-hackers happen to read the sources too. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-440 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-440 2005-02-21 23:42:21.193570455 +0100 +++ b/drivers/net/r8169.c 2005-02-21 23:42:21.200569312 +0100 @@ -174,8 +174,10 @@ const static struct { #undef _R static struct pci_device_id rtl8169_pci_tbl[] = { - {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8169, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_DLINK, PCI_DEVICE_ID_DLINK_DGE528T, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, {0,}, }; diff -puN include/linux/pci_ids.h~r8169-440 include/linux/pci_ids.h --- a/include/linux/pci_ids.h~r8169-440 2005-02-21 23:42:21.196569965 +0100 +++ b/include/linux/pci_ids.h 2005-02-21 23:42:21.204568659 +0100 @@ -1485,6 +1485,7 @@ #define PCI_VENDOR_ID_DLINK 0x1186 #define PCI_DEVICE_ID_DLINK_DGE510T 0x4c00 +#define PCI_DEVICE_ID_DLINK_DGE528T 0x4300 #define PCI_VENDOR_ID_ARTOP 0x1191 #define PCI_DEVICE_ID_ARTOP_ATP8400 0x0004 _ From webmaster@rapidforum.com Mon Feb 21 15:05:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 15:05:20 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1LN4TRS000451 for ; Mon, 21 Feb 2005 15:04:29 -0800 Received: (qmail 29600 invoked by uid 1004); 21 Feb 2005 23:04:19 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 21 Feb 2005 23:04:19 -0000 Message-ID: <421A68D5.6020808@rapidforum.com> Date: Tue, 22 Feb 2005 00:03:49 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> <20050221213610.GC26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221213610.GC26248@electric-eye.fr.zoreil.com> Content-Type: multipart/mixed; boundary="------------020206010906060800060906" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 511313 Lines: 7024 This is a multi-part message in MIME format. --------------020206010906060800060906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It suddenly appeared again. there you go.......... Francois Romieu wrote: > Christian Schmid : > >>I started it after one break-cyclus and stopped it immedately after the >>next break-cyclus ended. > > > I'd welcome several cycles to feed the data through gnuplot. > A sample based on 15 minutes or more would not hurt: I speak perl too. > > -- > Ueimor > > --------------020206010906060800060906 Content-Type: application/x-compressed; name="log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="log.tgz" H4sIALdoGkIAA+z92bLsyJGuCa5rPgVE+qb6IrtgM1BSUiIt0rf9DJRIMvIkK0kGT0Qw82Q/ fUMHDGaA7+UYHO4O/yGZ2zZjrwWFATaoqumn+tdf/sf//vXgq659nULoWr7Klv9ualtHH731 7qs2tfP2qwqPfjC6/vnb7z/9WlVfv/7yy+8/+rnv/v1Nr7923/8/Hyyj+57dt/XL3996410c v78z9POh+09V/eDn4uvDv/8/fv3lT79V/zJef/v5b7/8+t/j/6Z/++2/fvqH/O1f/uUvv+h/ /e2/f/v957/pf/7TP/5JzR+q7lX+a1VVv/3XP/7cNf/2688/d82//vPf/q2q/vTTn/6d/tdv f6E/fqnoH/7Cf9Lf//J3+mv3LP/8rfrtv6u//Ln6r5/+ULmqshVfdff/jUux+w8hNL5KrW+N if0/0R/GtE33Nxd8ZVKTur/G4CrT/a+28nVl0x/oZma4n4nBe7pfTLa7n/NtsJP7ORdT1J+N vm67n6wb0/3R/Ublur+4P1R++nwmtnXN92sj3S81+f3a7vf1Z5Nx3V9t7P7s+tDd0oXKNn+g h5s8Xzcx6KeCtw3117S2mdyvmyvNcL+6pUeh92MC3c9bfr7uR/3k/VnH76+bjHS/6Nz0/Tkb 6fnaxnb/akz36DaZ7vkSP1/3ZyjfXx21v/J8ofV+er/uP1D/u3/v7peoJ657c/I9nK1cLJ8v RXph3fftvlZ3v6YNMetvt0L036MNgd6fN1X3iLa7me/+Fz/fZLy0rfWT+8VQT9+fa0Lbf9+u v4n6a/v351oeL11n3dhfE6Lcr7Xc364/0/t133sYL42lN2196L9Hze/PZM+XGhl/dFvqbz6e XQxmeL7aUX8b43S8jN93fL7u69Y8Xpqa+utM3fj8fpZ+KnWDJNXc39B9Vh1/rvskxf2Mc4bH S5L353hQTO4XZXzz84WWR2pN96P51s0PX/a3NZ6fL1nub4p5f7v/XI/jmcdLze+Pxkvsptxs vLSNjD8aYd16UOfjz9ZpfL7I46W7Tfb+TD5/rYw/eX++tnF6P28m46Vu6CebbpXpxrM1NP7o +Zz+tM43mrjd/boH4/7y4076m/h5adLGNtFIiDHxfHM831w5nhsr61/jeb41Ifsevttmh/Wg 6zs/n+3Hc9frtlhfXB0jv7+W72e9z+dHGu8Xm9bxeAk830y/HhTjOfH3iLXj75FcysaLTcN4 id1c4vnrumHSr6c1f9/x+ayX7xsNry+2XK+611cPz+davh8PPvkeNhbjuXt/tCDZaA3P327C ZfdzvvtOVUg0u2tPXaMBoOtfoPf34rtltjr72PBoiaah0VxH7vw4Wuooo4feRc27UXJ1vxqk fvUzk7fX8O4Rnaz23evPV9M0rn4xtf1oafvVVEbzODuMkdWPvyrNtvx+vls8x92N9xnT3ZWe z1TdL9JoMdn9uvnfSH89774xHy3Gm2H0dc9KX5d2o9hrBzKax9XFee9lj+bVoG5ik/WXtuNO w6A1q1s3ut8zKclU60Zf9yJb1g7G53OtkdU50OrXmG7wTleDbnh5HuzdHGlMov/a7S/dHkuz o/sNL6vLOJpDamT183y/po1+ej9Py2H/fbs+0PuTpaC7q215NfDZbh4cz45Am0j3/mTxn3yP 2PS7b7cfdD/pTbf9kYIgu7kpxl+3GshqlWR19ibbjbrd0w6rved9xnfDhDY42T3K3dzGVlbn bgDS9yDtIxt/kVdT2jNj1xfqr+fOOtXZiu/brfaiHcjq3Kkm+e5Rt53y5WRvrhvejTodq3ub sho4X2pr3ZrL36OxvPvWwU6fz6aWdpOGvlK3TtKvNr5lbSjx7hHL8WxT4+V+/HwupEzb7R5w 2N0SaX/dW+uW5khDJnbdN+X9XG2z+8Wsv9M/u+ejceZopHQyQ7c9df95Nt+Sahvf3k/04m6B tXw/eqEL9+sG6b33M3Qb2lD4fq6ifWZ2v4YnfL+7dffLtMl+VNHuG0QRob/K/UjtdsX9bC3r y+37DeuVb53cr+b7dcPV8POVu7msV3Xk9TT57PuaNg27W2eg0G5kOj23W/yq1P2HbtSU2hAp pPx8er989/WNq4f5m7p9t5spidfnru+u7sffZLdMMU7667sVP98/3KgNpbZbT7vnl/VUxrN7 9d0ye3ukGvLX6L6HrAY214V4N7Jt17+mGwi0nHcakWH1mRb8mS3TOqtfl+4XxHQY7teZJPJ1 A98v0GA2svo1/epS2L6hFt3K8GoaU6ZL+u63+WvQ3mx5knXaKusulnR7si1dsZurbiq7b7fX ZffrBsuoi9e8HUbur+pWTbk6D7YH36/TNXJbQXdjequxdaw716JLygLdFrOt052j9LcR24Ns hvF+NtGs6TYR2ps9r84NfQx5f7F/f9P+1rWsfrG3PbLna+xgW3aSaCLQaq66X9vbvlNdV3ej llerUNt8tpl20IaSZVuGtIPbvghac+X98W4Zuu5lu1urtib9q4usxXY/3/VXdyNXzN7OdHKy WxrxbfiYaVfGj7tvnUixCLHt++vn2kHXIbFVE4/nbgFuM+2qZVvLOvIs2ECrVagN20Zi+8r8 mNhaphFbWvrru8Uo+x6GbXXLuqFtWLcnX47rbUE7m29B+tuIbyg2+W7ejfZBm3Tsi/Biu3Xj hWzBVHxfer563I28T/l6EKKMR9rNHdmCzsbBVm14fuT9dawed/cT26PTrnLbyI7alSPtSp7P 9uOlLW2thgcc2ariO2jy52sjr/amG6TJ8/gLsR8v1N/Az5eG+zlaAmR+0GpvYp3tbp1ySqa9 o1WwU21oajXU2ZpVq04hnz9fo88nvpLYFLZbLbsRvd3gZLz036Pb1v1Mm2yNfN+Wtb9yt+wU 0jCsf/J9m3qYH92GVBfWR7ce6O4m1kyT8vHX6vrK2ksSxbztbemGx0ud+UqSvr82se+vKcZL MsP4i+zGowWztz7YF/FOu6VJvWXOnqFOS87eXmcZke7cWZyRLU9yFXpWXMh86zrcFJa+qWux LY18XWey1cVGnW0VfauWPbHdGmgMfRBvefUrdstGdL8kq0EIuaXfioLGs40XRkvDVHePxKtL bvuK8j7M3hSy5/PRDLZlNw7YUzKsVjp76/z51BYkjwiNPl9nthFrpTqaa1L5bNLdV3aj0rPm 2VgZZ6+P+eij5aX7Gw25bjfi+3XfTz2xDc+OXPdre0+Tejrz3cjXcdzdDO0e3ZbZr3662her QW+7qSc29zR15p8dbX22VXk3GnwRTXG/bkdt47i7kbKW9deEye5GC6uhaam7r13wXLVBdt/Q qKfYFbvbuDobXq28Tf39zNxXYryOvyircx0z7c8F2ZxplCfRO2n10N1tsC3H5+ssMbEFA4+X TsHLv2+nLPH9aS/ttvZ+twz97uZntkct3zeKp7Opi92oHVa/ZMVpHEw+XnJfThDXcvAyP+qm 8Ny7UbuqXWJnh+Hva/n7xvJkwTTquRdttxuAmTYUbD08n+Hx3A2w/vnafvedrle1+DaCk5OZ 4vtGOgHqtEmydALPt5Dc5HvY2Xixspt7+b4xFr6DZhzPTlaOJNp9ovmh7y+bb/J8XrTxWGe+ oe4Wo63FbiNnulVV15fA39fn2m6U8eKSeGJtvv4FO/oObMPrle1PysR2K9crLydHVsZLysdz 931kvtFqwYqNJQ+bzt+mXw+mnthG7yfzLZnc8xwdDye2nSyd5JFXLztJefHdslhNaxktVs/d 2txTZ9TTRmPd8OijZU1XU9fP3qku5GX3MLpaFatLt2WMq1/gc0HSrabnULku1Oo5hXhOu9GS 2zLd4jDej3ff7mdYUZP7ueLcwzVRPJO8vrUmFZ41V4+ztzY0+pKVczLTj5Z8NfC16OJObLfa 5atBm9g2IoO7E0zvj3QEPadw83PVbjSLruZF24g20yWdlXMZWk1jK+coZMtMz0Hr/HsEL6uf 7Oayuk++bzPxPEcaCcnY/tyymZ9DddqBnoMafb78+/bakexGbHZ1y9C4+6bZOZST2RbYM9kp KNm5tGnSxDai1cAY6W83IEN311Ibcs7r7mHFVkiZ9tL/aWj2dqL5VRpyY1dtRd0vPZOd6STf 9+b9aPzR8VZnewS5NR8aVd3zWfaEFfdLeq7/w+eTk4+G+6X3c72nLr+fc6IdfHM/+r41uV4r Wl7V87fgmXRycHzP/YKXk4Da9p7OpeeLupoO98vmb5V5JgP9lbSd8n6T3dJH9dzL+lL7TLuy Xs75afUJLf2Tcy2f43UKPp3MzLSrRuMiGr5fqE2uTUY7ntMG0v46/bzm3U20+7rw5Vhje9uc bTdb59pzSj7fff1Em2yWzvUb2X0dz49g8ziBUIfRc8o+ak/rOZ1sWTr5WJhvql3ZWnxDIT/5 cO3kXDUkGhB6skWL1dyXQ/vDVLvyTe7Lsbxc0DDoPifZ5s57o746up9/g91yegrfqG7Fq72T xXCymno7vj1PkzZpFIh4EpvyXKtWz5VP6nnJR5/xcZi9kT27ZEyQW4PnnCujLKo2ydfQqI1g snPVztaaRIFE+pA0ptUTa3tPzlQX0nMUL7ZRyqM2vNVzx4ZtQZq05J/U0TfoktPdSP32Xvz2 pS3YiueJY566mUijxfW7kW1Z1y08p3o/1V5S4dntz/F49+WoiCCGtM62eRSI7pbiGe+eMvd0 xnG2xcTz0jqjp/q0u808Oa1ENfkmLdmqnW00RHEl8hp0t5LZQbulnKPknuxuARX/oEZFFJ41 aybjz9HIMolvJtqaaUpPbFTPc83vr9M1bL6be+5kTdJ497BkoYvnVD2JxWrKzgfqr3hOfa6t WV0dRm2NDg6lv2MUyNSTzWFq3f1Et2evzfT7Tlcr1tZcMv33jb1ndzLfOm1X7tfwOVmsc92e wuCG78v7AnvCUq9N2pmnLrIxwMf7/Hy5bVm7wZcjirAlf6y6JclI4ueb3k88Pl7PtaIvfAfs 6qFx02l/6mtKes5NRnp5UmGM+DZ8K7aqc/l6EMdz2sh6Sae8NPr+OmVGtavxfsmxMW89x2k1 dNqUR3HF8f0FjmoyPul6ReFmXX9jrh20bAt6Oec2qdCegxujHBvbVhp1lbS/1pS+jZaPNrr7 SZSja0tPpzxft6jESFE+pm1sHwfSzKPWBt9a3du++fN5OTlru1Ee6cytu1Vs+pOouGBbJvU8 17I+R1v6csTaimwtRB5/Tf986Q1sy3x1Tvo11FOXTMhnr9peomuIpe97283wbMs9TXJQYn1s xJOYe3K6t+cGXY13j26cevVjUwyhKT11IXj5KfZM2jY/V+hGy6CrxRTEFhxiTmOvq01j/ppa Zq+e8xSjz4kpQf6sZHV21L1tZPvdaDpa1FbQ3ag41Xd8HkyLfmQnEh/UOnFlW1qk4yzotJFg JS+uWB/yIMdg4+ha65Zu+klTq+vZL2zn3hjdLnl57nTBQj0Ik4MKNrtTbXplt2ZXYr48N7Lf BCMHg9HYXHluh6DTGHhoNa7pjdXA0y0LaxqCOq0Y090ymC9/cjRALo6Y+CCv1e1Dggh9eVBW 60Ge0TCzPAyJYrKHAeMl6NklXe7J9VcGYVoXxJVY84CxbVsY0+0YlCiSaxnNNEFcH2YxVV/U eSDbOcVMZsvVJMhbt0urYVey/M1diU6dJbUa5/nz+Tj2t7U8oFszeb5mtpxGceZoWEk0+f0i z5+KlN7YsvpSt72xoMtzoU5yHAmpQXoQmrvu61a2T1H/DG+//fLszTxMr2qsbEe+0e03396S HdW/hsMS2dji8UL7Zhl0340/eT5Sw7ulv05FELAbvm/g+GoTxdLiKIZuCpdHKd2eL/cLEmZm Stf44HyJ7IXutjf2Y1MwUpqru9Y4UQ/E2WQbk7l2LesE3Y1oNrKT1dAKZoyG5fhSHXdGHMo+ 8P3onDwzZ5ydqFcSNN6G0Vwg9a8IPGhkgVZzxjb59htbO6rjVtYDw5alzF/z6ttlNjsorkDe Hm+X3djKld16GsQqyrhL/Wiu57PXBAElfJAgwphyJKCdGDNsXHbLfztx/ZX36yajle1Xt8s8 bKh/Ppo73YcRuyH1yn2zsDo3cvDhgxgL3uWzI6hrwnOQHn9d205cnWVQYje4rLw/dpXQIft0 tFRtPemvY1dTSzYg7cDs6ZgF1VkxZm7cb/JnZ3XzqPXiSuxeQHe/WdBf28+O7+/n2ZUoHqub QYkaVOdjf78sSLn/qcjKrthhTd27Eql/s/6G9vv7sWsyNOz6IxuBl/2KzlnL57PWy/f45n68 +vmon7q839T5YhpdDVj9q5v8IL4dXcWRzN7uu3bGAp0ddcYH+bBmIfdqHDkNe8mDYjvTlccz OQQbjjhzZAIbtgc7ddLXbMxkqz3rd16RqBDy3bfmMDN26CdL2lWnv7Kuq0HKZX/7MDNdD7rN LQ9qTxI06Xjv47C62vH87cazIikxW001iNVLULupU9bf0DtzSHeIhHy4WhEc3ztz8kAGDSN0 ZP507z4UB6u1IGqkK3V2DhvndGIkllE93827jsjz1bL+ufygsfuYfDTFrnvPiEZDziGrYWGq TU6cG0aCYr2VoHFb7L6hmSAztBs5b4sws5oCjMfvYRv5vqINhdw5RFFttHnzahbZmcOhrKKg kj9n5nwR17h37HqW8JzJ+zOs/RrmPLqtk360JZKED2u7B/S+OKmlO8h2ztavTW2dD+jRu5Es URCOlHyhFsi79vK+2Gy4UFRaLduRRMXGfHvriT/qrQscNZnShNiaRek1jS73GldSF3EgZtx+ mYhyxF3K21PGoPSFyfSNYg26fLnyQZRfy75TOupwFE2jvth6iVkQ37NXQrKpC+OjnsS9MHHU pIHIq1n5y5Q148V4U2XNedMUvhI/KM/Ji1fF6UkA3a98vs7Wlv5yjyjmMv8eVk6SyFMbWo5T IWaGlN1Ai76elGVxUqL8ObWmU+E7taMx2C0WHHfQzqzzyUmFl8AWH8QXq8vJMH35ZNR4miOJ l6tuDzGVHIZSXMks7qoR65zjPzhKOd+OLL0/0wbePlgZt4mPBWl5rjkqMfsedIIi44XUtaZT 9fPlJfXqWtMToeQhkjga8m74Mu6ljrJdJl2uXD6eXZrEbbAvMbZWoxzHuKtsPNd6v2bpJL6P oqzYecC+XYpKnEaJZvOt279VPVBnRH4S741EodOs676HRE3WIzHo5sxCFPVZGKFufuSEc5Cz GY4SkYggp8ZMIuN8HkfTO0v0+zblybkZCdNu6NHzmdgzYIveK51vPkjkQR5H2NlOGldH85c3 1mQGQnIpziwJESqRQS0FPefvbzQuI9vBFPfeOzeGk/3J7pFq3T24vzb5MpJBvFmWt0vLv9Cv L2MU+jj+uvGi6qnGJdZ5f7vhR3/luD/DBHurZ1FmcjYzWa+sxObreOnMl4KxGuOuooys6EO/ PqeFuL8kcXBeiHjf68jjejqaC+K8Iit+ShC/+G5ZRoXp6iKzzbfFbunGc27DnvYQpbfNcsx4 0NGXZPcojUFZvPVrsCvHtqE/SbH97jE92dLVWQi17r42/7rs/+Lj18RxFt2+UOd8c3Hypsp4 q66hJneVuDDulhIBRSbrSFyWzIxrjRhHrcxel4o4pDi9HymnSfMnmJ5YzVerVqLWfBvVVVec zKQxqrOPh2xyRiNfDQSh7d6fMC6pyVcrawemR+8XWzeJYp3Njra2U182f5fJ8xl21XmOmRVf exxnb+xj0KfaVZA4EGOUqSjGi5toV61EYQ75J2LP9EyMhZAkylZckya5PCpxOv7EDGiUIZny 4bmvnVVoI66/UMTcM3mq97Pqena962rI7zDer9ts5Kux86yt20K5r2X1o7cRG3Y6MiMkzxf6 8TcaH4IOUxwI95eCbHPjg13R3qQ+yrbbX5gIpd1NXHXZ+DMCvFNciTqHcu00jQR2I5IpOkd2 c9I2StezEd9hH6fivC/m73hSqywqx9HE3jlUMkedsSIn0xw50tahLlzFcWK8qbHqemdT6sff dDdPcj+xjbpNOM9PUI9nR1FiHlLoT0LH8bIUZ8bOK1sXkRaGj7IsfeVOMP2kdawN0XhpF5gj Dtel83B5f02RD8T3Rx++j0JPTb9eqTZUxjVp3J9V7W+Wn2B0jUs+lXYYz2Ee12klTF+J7m6n bnJnhJ1EviSO8iZvBWkvVvPHvP5uOd09alldvNhaLid67JQvZaLMWMO8b/dByKSeRxG2GuMt UaexKaPgeLZbWRv5n9ohKrH7n352Pz2Y+eH9ZPa6hh9VoxwD88Ol68/ZPqb9x/fjr2t5VLgh KpH23VlUYop33i9I1N/M9Vfnno0ku0fi3dJq9p7hfikMB1Eh0PeoKMeNRGHSg4Q5jyz3a0U3 tUXUcxRdlzVhjvNxxDUaDkPv1glv51HUcq6vxFYoCFhj5aCCvge7KUgb5t1cCN3SNupsXyVq NYa/dE1O+PpA35fi9vrVyi3EcbWSxaAnENs8zsLH8SSejm04DHRgKlKfPWaibTR6kNdn82nz qL9atUFmhIiB6CZQ2zMVpr/f5OjDOZlvQgwSz5bvvnyS4en4J3G8Kx029ATdInGZMkaoyZkK LwfLnuZbty853o1Mbwta/h6FrS+EcxDtrzMZ8qjsRpkFJpzZt55aM2OOpt/DKXOkcVI2Pzg3 2W5JcXVJBsvo2ygOQpVYTRo1nvL315pJVLu4stOQzcctaWuqDantFouDVctMhOP5IdmVkm37 1d7MszXRQbLsHj3zltn6nfLP88PzQTxrf506xP1l7UXjJsf1xfpaGCbPtr5p8qjxrr+j7evZ 90ex/ONBaJi5sr2MP2V6XG4teOcmB42c76BNLs82ZHPfmviuVJt0BRGqDInsvqLnjNmfxJZ+ 8d0y1yUl0pqidySqrsmPzRvVVYlZaCQ3WrQTXbzb3VK2+zZ9VGyt2XwyT6ccoBlZDUSXdH4g JOnschbzLLYve8DY9sh1qzDxnHIYjW3dwEu3S8SgJFwIteiSIbelvddjauZ9aTe3luKQvIbR zJgPJ8my+rAXE0wRdar5D3g15VxcxvcEk9rS2Wg2RnVTsY0cZ/WZjmbJlkP+yWjZ80InGhTg zQdbs6hTWg3k+6otWIS9iDgeyMnU8v6G1cr1tvl0NVBtSA6iXJvz8LbhxYwj1DsrkcKULS1a cvJmScP6A1lG2cmWxtF4ORlM2UkUBbnzB+eTN04A0DayXMmKNUfydLsU5LcbNrlx6dg1RB5K co1LYJgErnHcxjzsuYdmZIJ0mn7hivXD9tGZNXQU7cxgTNt5woMxeaCEoac2T6ZnyPak43qv CQAECeWTsu4pgykB8TYq9OHlpNbmYe1WjQcegLwd2TBMYD9P4NEpw16hFFYojM0XhHaMM4uW pzqt/2R8RDYWyuerWon2CknUIZNDCy5IXBKd88nOzIyobm9hvv0aARV7BNG5UKQLY3KJAgro zJTDOhu2LOnjimu3UDfk4K1HJK0pw6jpdXEwemwbWQBd7xzyvXMt668Y+3KU0ln1RSSIxLHx 5iJnpjUZb6K+NP1RwNyZEwR6965AauMkbkgMgbYdoLIh+WeGBejzaVxYERbbmvEogBN4SPLF 0C/487BxRUxrTcdVbJfdBOG/ek4gIwlpwmj8vn7yu3y0pEa2o7qPwsyV+x4hDAyssuvKDcpu 2x+kTI0jJ64DK5EAjctHi6UwB8P5AlM0tNxb63tXTjNXxgNHT3OQPB1E2TLqio1iPr+pAvMa 3XRq1StuFuKGmqRAMh2ops5yKNKLtONBnsRFOCPEgh5Ll65i73W1Mrya1j4VyGqaHHOTckph aeNsc6VxaWoFxFV9aYv0GK6ZjmbD8aJDcjk/T11pjaYDEajHpiYfzY5dfxTOQcn+avadsbFA uwctgGXUn+2RPE32VxykOD+4igUycJSURlNNLrhyqkYRXUlW1+1mRfLAOAmjZsTUNVNELZZR f1bihkJi5dk0Ibtft5Xy9yYXQHSi/lnbE0y2hxaygzdN56OuOlOkyzFjVGfLB6EUvZYd/Oa7 kQS69MZlN/ry3UNcWS0rIzUdXBo6Tp6uLuX701TFfdSpKXajCZLcjQXeffuDWgrociWiK9t3 7ywh13i+mmoCE/pamm4otT2E0y6ku9I1nI90aPzZIj1QMxozLbsSo0JW4roPZRh/2yODrSJ+ ubHVH/yydiDfo+nj/jTwwGbpzOp+9+X7lc6DTvUhJojTMiSOcDdEOelBqKQCzo56jJVAi5Cs mB855EJeHP4r3S+RN42GIcfXykHtDCLROLhYS+rt6Itkem50vvC+T6E/7GxKDM3MkG6F8qI4 EylhQu4M8xNjn7OEW40j9BxgN38+OXqLDc83Sp2cx9X58fs6Mmc45kKcdYHjRF98t8x1tSCp MJOR0WJ9ETVJux1lF27os3JqSNdHTfqmTwCQRf3x6EuaUKDOk3sZJyHlkuqUdD9Lyy0Na9Gt St3FcN49PY3nr5sfrPbH8HIMFGQd5yAu3o387CClloQHSWYbuZZy3S8MSFTj+aDWUvBB5LBM vxAmoOl3GK1iWyY3pk073q9uOCislnQ0jn3Gtpi9xtXSXwlDGqCbYXUW1wbN3oaSanZ/M2L8 Bp69bWkMNhJVnATq8d7munPk0czHv41XXdLx+6O8s7xbFkio6JIpqissn73ejEheouh48lVL OprYp1fKnRtyEju8v9aWqYXHg9pAxrkni0t3I7eQvqiRdFJJEVjJ9TVZ7ZsxuWHkqERDrjA+ 29Lkgfn8cBKWk6zYHkUyQh8nB9MUb0r368NyXJynp3Itqyc2ie1rYrE6OwnrIp0wNhzmQ+OV PC+e9/TZwWojSG0y4upsclvQTwsP+Miu9tT0u9vwfSfaQWr1fpqeqtgtoxm008SpSQky7rUX sxTGJbt5suqKbfP51rSjNsQRWEQN9el30jwBgKnFuZGcINM2Pxj0VsKSTO013ZCjOKrx+WaJ 1WXAdfeT3dfkiGn31EzQ8uiMrB1QvJyp+6jT2Xhp+QVZjh6m3Tfktn6thRtIF/Hi2m0T25aS rmlmC6p2kJweXoV8vnl1Bg4Isas1AUpg30apTXbjRedbo2F1RXqqycEvF75wnJBmqq2VgQwy PzSM0JZhUmJ9iPYnhRaawTZnbfLFd8s6X52VsxOCyRlfltGgPdFw4lJJtubDYFva3vaY6GpW XLFJHOO2yW1V64LoVuTncZLIu0192IGECSwyKUnSx3S2ZH5Q0dRjcio58vN0EFX3yalc6fnj bH68W0qi9rzMRzeaeXfnoKfaSJBjo0GsiwkPWmEWknoiysTbaXTcJ6+pYofVYCG5F8Xgcn/l aNe6VMw2jul11Ilk+f2RMj2mcmxK7aUVJiWpJ9HlALGVc4yKNU2x8myU3SPy+ytt6b4sQlJi MDSF7aYJH9iVLUeSw3hZLFujyfmSEdeuLwBnNw3b4FSxreBk+v7SbLWPknm+0XRSprRVx+Rt lCaMtIP+IM8vBAH3rvuoZS9CkTDCTYJE2dNpowZ1apzy7H5ed0sN4yoOtgyvhp720MZw4QFP BwKS2Np2usLsfhxlLjbbQhhS62Jv+ybahzQMaUgtPAPYNdVpP158wYClNPpeIvkiOu3A5UcV IdMOJJep5RgyGs9Nrq2lNKZ6DjzfmmG39EuEXyupmRnM54QgRXI+O46XhlOn8ngxfSrq8uDS aFiYzt+yzJE1bOtzMZtuqQmyHfL34PRAGsQ/TVVsRNuVsDVXpMtxXpkSWs34FIOwA9Ym06Qs THb0IaGprWq7pjhYnaQHYgbHNqad7L7zBC1e76fp20KRCH20BaUwgk2pTxXLRmaJsGvQbtSE EbFI+FKPxG83xXn8Rf6+CkG8fFBsPlqMhLYlo2EgOaLRWZYcJsABwkJWs2ui7omjhdSB/PaS iRp0VSa/Y12VLTsrYRF+WF3qpdEiYT6x0aDEIs29C2MIug1sK7gwCeqcJY5uJFUnJ/kjW7XN bZkw5bmDBIna/hxl8Oxmtox4SvrRl/IwC5PG3dwzb964NAliLYk8I7lCe1vBlciHhB1IyR0+ I7VEnav24hbOPRrVhkyfrC7/vn0ibp69nOCBPU1D6tSF/AliK+jBb2wL7SWNybiszF7dLU2/ u2WrX/fPcvgv6UpszHVnl8ZEz8kwv06uVU1c7uZhB9bpal+L9lcXReNiGlMBW2WD+4NpXa0y 29xoVa7YtPo9ipMKjlytLKejkSJR9VCUaCDopudkQUeV2DKuKAImRdS846Js4hXwtg/qDAvI h7jWB23N56mUu8V17C+v9taqdmUWCeJKmAQbNV2TK4ow2Un+BNHrXJuU4BwJ7Mn9JJ9Ldz85 6anNMgHLu7njYN/AhhGVSen+5yw/QStlcPR+3WS+SdQSQER/871nkmb2/H6qTUqQsmvcUpie p5xTsv6Rfqy+NSq7MivjUkvq6B/fT96fcz1sejuMsNt0771fiI776+IsjHC6u0kQf6rFc+8K bbI2kyDght9MYEPQ1H0i/sJaYIZn2M1dW0ABYYQqOD0QR3aY2BO6L59YvbQVZLQYeXtN7omg 1HSep1Cn67LTrdv/xNMUetut1MXbiW7q6qKokyaDk7fHiYWdH0oCDqvB9H4CgHGwWjf+bW77 +joNicu7CS5FwEwfMTmksp3ofm2js1eQCsmcONHVxpKPgsx44s313M0tncto6kopK2GbXDf1 fswe0/3NMc/dJ1JWIK/QXmqxjYyupkWURSTTxDJFnKj4HJHswq9zoIWfedY0TErLwhBXm+2+ QZO30dMnjspp67a39dNi1EGf6L737Oa7RxqSG7JzhoLI/QTQna32rYbIN5rdpkRIJkGxhpEj TkwfJrZl/v50NQ2NFgooQvhTHO8nyFEjYVyq/ZWeYvqm/Hx9ScWwGAZH7rek4Z+17bWXoUzP BPloBeDU+1mfZ3sxjm0PtoipfiN1iJYbdm+40CMfE9tcPfec9I6jaHLtwDAebmlUNpY97VxC 0vRFk8rxbBhJGsazt4Xn2afJ+4tD0K7vtTVXniPXfdCuIC6+0IacnHOxbs3n8BTH0ifXrOdx EUPUVaMlWwvbspmcW0r4cYxFWZjcF2aClE0ykk8gNJntRkWDaLpyCcLAqa0bV/fz17KtWmbL EdvN9P3NS+i6SdCu5zIunP3J9+tfaaua5LzqYKId5J7szvwbbUFHuY6dr1PvexmicqbampP1 pU9+VyI90yKInI+GyyZ5jTtYsGbEYxbFd+BdUVK2aceSmYKAcVzJkHzx5XfL/GtY7a3tS0jm niapH1pxeVjxiba1zWdHyHQ1CXuwXM6jW1FTzM890ogPRyepMJ3o4g3PjlicmneqiaZO5ewd dcqDbKksBw+FTgpXFqHhJdWlOWayjNowdag1yJZWe1IAihizZlKwmnOjURkICQRxZh5kSwq2 REXQ7Gio9/luZKdRKlKAuE+dqrp9Nvqc1dxoSWJEm8LW16JnfIqhKd3DxPZQz1W+W8puJOeM 1hbA4FggOWr1TNf09xvKpExW5yiev6C2uS8LTNsxlahYyZz9ZFpQtsgtFyUmMYmnLhRB2XHU rqLAOtQfTU3qOVtOgV9H2c17W7BI5minqU75Tbshlaji3Nn4GzxhUkTNtYWn2MvJguNzI6m3 ZYfUuAsFkocoC43ZbQvAOU4S04sVb+o+yofKVJQxu8bWvTbk1VdSaENDUae++KfrbV+yzevy XD9a0V7E9nWltuan9+Pci8H240VLyuarqUzYoeieKWz9ZCdlepJky/H5/CiirqIWwFbtwObp MVqOO2g58TCB9Yxq957npl/tp9qumRZ0p6pB2fuLY3qRTvuTAtjtpCxMWWiBzkFlVoq2W/ti vtWl74WSRmTac36/PqhdzvU75aosgD05l+aote7N9Oks5CQg+x46wSQYk/pb5HLsc9VJOgs+ OfJ9VJ1GSeXaqdWC3xJF6FIR1anJffhUU7RTPgielIl68d0y6y3lRm1ktZfUrnmyEhfNqKtx /IerbV+GRM/JSl1cAcQ+IjsH3mo3KSLEnj8uoTYtmlTns0NjJr2WHShiWJMmkxHgjWN2QxyT lcyRD+GZ+yI9xhaezuA0bb7vdnOebS5IuL2RouRlVE5fpiJpScW2fD7aLOrEidVldfFNrm0U o6/HkWX0uTyVlJUaXTXtmQ1HbVCKaU2WQ/mB5omPNWI8aRRNnvuOvhPdhE5/uzfNq4tp9NzS GS65V3wPycXVF+2qi3QHTpN58HhhyaTtGKOeusWSe6ptCGHQlgW1pf+0lhmeba0xo6eT7ufz +0XZzTW3oSmA0FZTA9Nq6jnqyvhB+0tLJUdVG5IYx+Fcdng+WQ25yIt42q0Al7Saul7byPor 2prGTBZRTdM/xTNOUYUcBddWtLjOM6f231fw8JSfC+b3q6PeTwHdhQLOvafznvvVNT+fev78 YhkSSnaXP18Rgzn+GakUeTV4JpdzGxob+phiAfxyW7D/03GVmsTzvhnuR/vubL7peFHtqslL olotUcuZirmMULdgSoytFJyfnQum1k18TZ4TmE/Gi6j0lZy6Un85+abUyXPNYtFC2S21xKX3 ua/OpsHT2bBn17E1M/j+fJEZ13gtEZo0mU+p7dbjuTR7TinOcHKuamcAZ9CSwX0Zq8KzyzHQ jqN8GrItHUd12jGq7vV3y6kl3eviiwWDfZycC7a0Wjmr+PpAfBS6lZevq6muQl3slu2IN/PG RyVI+0yxZm4bEZ8vq5/ofm1Z8FZsIz5XkPsZUxREzXVnq57ToOc8Rd7jMPGcBmVh+t1IT80L T6Li3FHeX1PEOAZxRNV8LsO7GxkVPziFl4rS5A+T+xW6aTOxVQNlxqVkhXlJuzwGU2OAlf+i RG/Z93B6GCNROQxc1hNtYxZzSlnt5H5Rd7dQrgZjTB0TCxTemZUcLXRnzWsdJfOnL2JYUxgJ jeAkU7GUCG3ZFxEKT7szTokjiZKyRdEzTmFnWEpkn6jh5DFE9jFEUmb+NFZsGS/pHVxbJOKP co7Hb1d4Mi956Q3zffMC3a0mu9Ly9dEVmZQntoJjYqbVmOd2AvxOV1NJScQuE466Ks6NdDfh dAIUY+vIAv5R6jvxtPtWYmJ9KNJPpLrXTmMrMdSqnfbJWcrnM2H8vt14KfjXEMfCDUxU2CBl OfScu/wexP7QrPS99mILbbLlMAPeS5VnJMB5iFEuY1i9zjeJzCA/Z1F3QO/P2pVknm2HKJVm HiNqfe2m4y8WJVuDEnmd0NgY0Zua/GShjItoJuPPl4RLnwqv4nN9rrPQtPl6kEdNei0zI7u5 K6LMnARB6v0SR+W0zaRoYSoz2bZ93QZNNpQXaTQ1H8w5mmqymxtOORT6xLMvz1vmu5HtizBJ YkPf5KOlj3DnVFdBTzj7rzGcy2S2hxaZEd2viblnqB2LMHGQOukadZ/8pO4jvLMoH1n9WvU0 NYVu1Y7nZJwn23mJmVTPXzmajeeyHspvUpLmws8+KdhqOCLb2qF8+EIMnHN1lmrNF7qV8IOB zxkZfBbbvNGY4oUC03ouKCU4u9man3tMI7xNYM9fGs5l7EIViEaLOjnRTU2Z534kXLp1mm3p ga4fizpNPH+N5kHX1Gh1UXYl+x5cEtXZ/hxl9ORMvkeQUlJeiA9Xnnv4SVUJ0dqTGQpqp3nU EBWu5O8blA4vaGnJPFc5SdRJ665pm75I1ELe7Z7QGO5XeCbdSBz15zJh4C2bapYaLcQ+zz0X iWpNnp2A0g4PtlbDxII3qecP24U6Bm3TJ1KW7ATluXSceLJ592ViRjyxUiQq6k9rf72spkkL QheJP/2k6J5EgdjW589XnKtqmSMpSel8O0tMylsaF4liLxfzm6I9x0XbXIqAaXIgU+R9b824 +3K2iG48pz5xdNtnJ5hqu1HHs1lKt0G7OZ+rUhSX57JEdO5HJwu+P5nJThaM0VSdSkSlmadz 9K1JciDy2GW+sLqIytH5q9qpK311I88oJXRjVqVnXpLSaR0NTWztMt8BJVqMdP7FBI6mmA79 8w3nqlPtz2ii5z5dSb5eSZUjK+cOkg0k+gmv+vJVSMpcDLIa6GpaF7lFYpqkFebkNsR9aNrj gfbNVmcZzVZsN1MUDPZjok5No0yF2cYYx5knotXZ61S3d/Wt0dfNDl6dQzNZrWaJFwWf75Pm u5DH1LlGzi0spymW0Wz7ol3qqcujIvoSdFIjqtPEfLFbDgWc+8SutpklwhxnmyIJ1ve+mtzT SQU3x9WZtU5as7JTfZ9HtGsRNYlRpvPabLb1MbeSGJLfXxyyJ7Tz1cooX+qVzy0K/BrjRtvX ErFADu1KKrrTiyoLJA+21vL9pn8mLlA7eP6kgPPcM6k1k6yWfGwKflh/quGIe75fK55JSZU4 j3EUT/E399Pdw06e71aMo9P58e39QiuezgXPZKZNiq0lPCN51rLvkcyQnCrW3nBUWFJPLKEa 87IIVqtoyOrsQp7qzzfDbtRwtggpGGz6GMeyikY3/3W+6W5kc9uIKx5WHLvWNlzGwFIsDQ/B bn74UjuttGac9/p8uTZeCW3Phama5CUGuOX70Vba85Hj/PVeEx8nzbZRFvFrhqimbjOiYULb vWWDQU8CCt+aJMb1PY+c2/rRaAnN7l1JDuTOGPY9IeTn/e10GxkvElXnbMh9B06iHMlBkwJ7 TpPvEwtTfq/y3LLT/jRRsfLIqeCROeykIfdwN5w5NV/igFgK3fAcRWiL7zHNndW9/SKqaaLd O5pvgzXD1sLrn1sWUQdeYvQ0UWeqC/5wogsZ4pccOfZ1NW2qWdJ8I3XbrJdcJb5OJX8z7paW aWlaNlTXaBdPzfsKeVK0odg94qTiY59bJPSeKzuPoulWF3m+pDFhRdEVCVkMHOOoxTVN3dfo aebnZDbqT0lRjjoVPKhV27yhzYITdaa20fKRNvbaxsRzanR3E92+e5l5CRyriUD5FN5ImnbX 2+YLuWO6NUhq/iTVXvK00a4ZPafdbhkqSTSZFSAuPc9BbTc5tyxiTidp37vdnM+lvZ+MlzJG dEgjr7ZCXdtS22goNKbh1Hym102nad9zTywv88PqZ4rUhs6w55kyEpLvwPLq3GeW03PzMhuD rPZyztMtDWWUz5ArR6NoqJJaSZBkURtiC0qa7M6WLE4Cwpg9wUhPVDut+yIVuW001KDTzHxN /nxxLJjevT/xqgxlApZ8EW3QErXiWWuLmlN9wW7uL9tatfX5/M3mm2l9X7FVcnvl/HWfDYVG deRzZIl6GTy7aZbtQHJT9Z7Juqhw6cUWplcnxTiF35wWNC48z0497Tr+THHOGCfzQ07Ybegr Zg4VOKe+jahlG2r9HrmvJLXT7yFRjkUUTWHNSCpMzhE2t92chNKRetApj2JbymDWtP7l+kJ5 ae3ke4TiHJ7r1ZOSQIAMl+yqw7AeDGnkp88nUUhawbR7viJuI01yj7FdxuXAmjHK7MV3y9w2 in0RErG1TBET6yZ5CCWPI9tuA61aetYorbWcA0gumibnbzpNcoxAV4987fII7/J+MlokExel ES48dVN6XWLgTH4OUKz2WiJKctu4JtcOnOYe4rWsligkP9iCcSnmVAgcPUfpbNOcIHFSLp53 35orcDbR9LubnxfR6Pk574eYv9z27c+RebVnW9AXnuJ890iSttxL7hNjbOkJ03PBWivuUXRl /3wLaZmtVj32EnVlbZ431bVhLF/fJoleNP14qfvVfkJUBD0JkPdnbW7LOMP4ouPcFHUUT9OQ R9TOeUYbdbWS2WvrIveT5kai2Klu2eXErmRymVrPGsMM0LWS7kDVNecLhMnV43Lg2VlChRDH ZDTlwb4xWtNOjj4oCDFTh2o7OnOodC4lXwu9K9EtHC1I/op+O+9GQzHhwqQuAi/PVMhU86Cb al7hvJEwPd9qMqkC+ZCwFZ8kFabpt8shnUB58DZ8YNneCPfPBqDmGdfllNOfGNMjC2khPUGj rr9+eyuD2s0ECG0kHUO/vY2JZycTOOly3/ZBp4Wr3YzPZ5K4Yt0kzHGWl77VowU9Omp9YUw3 k6o6EvJQhwkAO6u5l5KYC5p6sS5Sf3IiWzpX9T1QG8caZWHhqKcN6mrXoOy8Rp7z7WSBlvQi ppm4YucH3ZqaVAM3aleETYYJ4MxHH96YLEz0xbfLDPkg5d2PrgPThOLgaGIMGpkdZlj+XK+c Tr9u01cs1IOjAoFwk5pdjZTnrnNjJk9Gk6IWXK4FOC6O9VtBLGgzCFzhzaQ69JbWgJBMjEHJ TtIbR52ukCe3aVr53y0dpLBryBN+7XX71cSLk/tZNVaX7zf9M0UjrsQf4ddWil7ddT99VLnf DfzaysnnXffTPDXOzoIcp/h/UNeQAKumXQjq7FTdRMaC7FRhwLkTV0kpnBu9sSCzNxVhAkGo PvqhyEOTNjnaKyvKDMwISW6c234N0iDvoiqH8aMzgg8ayRfXByUuJJPq1T+tsUUHY7l64Mfd koFVHwVQk+Q7bp7KzGsaaq0QWme7B0X2988ntSE7844BNQUk3cy41ILLWkMt5uoV1QAbVvvA B/FuCELX3TxTN4w6COWovSVtL3etcZSQYQBL0zFEjhBV19oszbimnwhD8p3c2cQ8bsWYbbfa S+DB4CwZKt5Onq9X/3S8BJsHMtQ9IjQECnBNQK9x7W6WKNarsSVVdWwoXJNNnB7s88G0rn/L acaNSVrDTw7yYhG44Rr5Hk2vPrtkmkmgRZnmfghkUKDRFkCtakPsOuJ6y+LM8QqIu9lBrWoH QQDTztoo0tGMNcoUGSSvWRmGND2KCrKbK3JUF6n06hFw7rQ/ktxqGn6jB9Mvvlv6xTAQTbZR JvOZHFwmSXsR3bTGUZnIUbJE0f28Jg7MXS+1G9M8azmcod7yiHxMjKOm/xpSQdIU9VUNT0ZD FnL3pJx4sRl0NUkMmfXXWMF9uW4xrc4pD4vojV/PQYlszLTtrCbRdHY4XZ3V+C2By2nqNvYC mtBMgLzZwVESXa1Pc2+KCn7TsBxT65fLkxcVIe2960VcdTYUNZiaYTWNrRNA0v/QtavGfqO6 bgGoOQEmPQdhGtle+1R1asuU99PVSooi1Hn98B7RUN1U5nnTp1pzC86NIQxE7lesLr5f/fn9 sS1DDsXMVZzZMqHWetoc5kOGV5Fm3I5hJeoKi3Xvqqt7AHEy/qRAuuWUbRzWVIyXiSs7WtHa zaTCZblaUa43Pargg7dQBBVzcHrFmGOUowBvB1fYEMblJv1VVyzj/000eVpw59T5RIhGS2UW 2FgkuIrTY8zSbg/aaasVH/N0IEPiZ+6vVLwNPQ811tjKbV+dbwr4lYl2x/EsESaBOdXeNR7L 78ELH48q1j/7GmLj95gkQ9JyJX7mGp/i/0HTyGuqziJVXc3ESN1yzS4jzrVWK0hyJYj5UZQc DGpi61SmrpT0GDSJIlWq7u4Q08S164qjMutqeSuMEXTacxHG1adnIFd24u9BkQji29DxnM9f YWz6+3XrSZ5ot/WTMDgKPDAEkkzXgxffLXNPiVXbTUezLYpe9CVdWDdg4M1KqitaDaRGVKm7 6Gxr+pDiHMAZKzQKzs0x0eNuFEpPmGvUE8barGmLRJPiiDLk5+m+Ln0NRiC4BJNz86BEwhTk fpKmvfFF4kpx5HNSaQ6OduR/yTxhdnG1l4Oj2extFGGgsS4HR9HbyUHKLNFp49VVLGERjSuC bKcV/DgMyQzJQJY8YaaWBHkShEm6brG7iW7JJaw4TICcovx8gcMEZsk7JJOm9YK4EA+aay/U X8McUZ9o0kwPksuDN6trGpW2ZN+GK1zFmqyp+6+N4YqK5JEYi9aUQaL9auoFYXJN7lnrbKMx aNdyiLwb62nbpdXPqy9CE4nmB91kFI3jmev7tkNQtq5WORCaBInqx0ubitSLduKp4540xuf1 qm0elqP9jeIpTmkxrTWdHmqqP3rBqk0uHC1YqTpEB+e8HvgckOzWA54vHBJNCby15FkRND61 zW0/Xvr5kc03m8aD2jpy0POYmm+x5p4iJFpEYz5/p0VX+OijHcL+2mqWKpEq/PLzuX68FIiG nRzE8/ij47zRFzbTJjUdg/d68OsLbbwePcUtzw8bhxp+pi8KE6fjT4NYNSwx/x7G8W7Jx/7d 4uj4hUdGNLhoZpil6kyN3k+eL+TjhUK66X41Two5sw8N476EzYQqlEyKtcJKMMhJ6lBeEDqE SZ2FxM4D+nmNBEnvERU7UTYYdR97WxBqlXGjMq5H6DXXKqSoRD+PIrS1uhKdbr9uiR/mj9UI CkvrmfLStHrNXInq+vvh/XS6OR626ppc5qUpPM/ed79YJ/6r8tzLmReNlFGgk0YhQvODnio2 YwHnxAWwafuw7G6mf5m7/lQ9UL6+LqKKe2KN+kvxiISnmEpqGo81wMbnc1ZdnVJhsFMmch7Z cRIBLkTUGHKNk/NI+WaKcpy5miRwgcIzxFi12fsLtSq/9H25xptE6Q2ZWOfbm9ftra8Rldc8 422vkgqXHEXt2tgXqNUaastxB5rPoi8v398v1mM+C9sKMWh7gm7RWaJRnZz9bOba7dSFSa5E NhZiLSfJbhLnM4kSlTDknlmgeoS5sdVwImbawyPRN5T7ToxVhkxnedo700nmG5vzTfc4+fMZ Zkr4uFU0OdkuTZ+7rTRmOuWwmagbyhRMtg8zbh8NB/9yHEhREnU6nl2YRh7EQp1MU1cnGUdU B6g39t3cFUs11JqpOlmof40Z8rSLn6jbTuyEUZsXOFdXtkbJp6LKh506hyTHdGPzOKRc/XNq LgijIdHek+er+aSKg70SbZQUKdaO/V3Igy7RY/J96aA2j8vpc23K+OOD+KaoeZY93xCHpFVI XBG5kcYKl7Fl9Y8OGPR+fqFgdavORKlTYU0qIhnixHllhoPVSZzoi++WRWZDo8oVK2umyMLv nB/zjMs63sSeeFuK4rLqivCST8C0Rf1SxwU1DTtShFWkQJEsu41dXK20BlNdEIOxGY1fLVVc x5lrN7ufHHNrHE1dF8rzhChrOS6H6/EOyumsv+Jg7Yko05gin4AfXXVy8EGVhGip5wLYc9dG a3X3FddGMIXrxY33azSshAkwPViwZRyN1kf2SZ4v5XE0cuAghXc6PdqyK6fPx0DH+jPjvOmj HAdXWG7M6G7ErqHIBymxJ8rU9VwY0076G7U+clEAO6bRlZM4t5ePA5Hn5/WCq6SMS9TsMUVc WB9Ww9+XidVow4TgLO8XjGovyq/bwhj07cjr15z33Tv2RNiG/6+sydYpL+p65vFMVXnygx6e FJyVIQqh5mPsD47CwkGe17i1Vne3kBsfUdJnkAnWML9uOOsB+3NIO5jnx9CDS8kk6kKev8P3 UY/8/ri+tOb605rks6jO1OrBm9xvZvw2Yy44I8RvG/PxUhfzV4luJRqLOK6kDBIf5LEZRTpR FrVbGlvKVCTdLXNnjkadym4prvba5VHPpXYg+SJkPS2NQcnQyspIr615ySVK861diqL2fcZC Mc59vj57Nwks4fwi9RDmo0RtXTAfStjr/Chcz9MKupLXP7gh86wwb1ngi3EaFpaCVggtD0JH wr7m9cD5YX1u3qBmV65LCiBNq6nkJyhywcUxLEKjHNl14DVTpy11ex81SIp1K4qJzU19cQV6 ipQPjmevj65XrORgqxh9ctistlGnm+au4qYew4YSVzUxY+bPel6TyPh+9xDdtKzHm7QaO4WV tJJHuR4OKiTsID/47V27UV27rqixZSZ8PesRrh2YgIV60DakMGEqqEBmTphOwlRq3j3Iv6Ha i+XvUey+TpkUmR0uz3PfqZa8OFHwlNbjrdNQUyws5M3vCT/Jk+1CXh+50301dyC5YjlKmeIm DLsj3NJBY9L+9rtvob20mq+As8dEUcdCvvrZfDUQC4BQMlkN8gqIJk7yJ8iRVaxnYQyT1aDp jyokqDMVB29+erDFFSkbYQLG1SW3LY2OFzmodUVNNpfYVRGj1Jcevu90/OXzN4Q0CRSwZf1w KzXFAukifUhBPXl/s/wOTR9VLM9Xai+1H2ts1ZzdJmhdBNvXHSh3S/2+TudHvjonP2FmaskN 2QdNao2ozJYxpo+6V74+DyOkfArjai/ala3z3bdwxaonUQ+SU2ELOj8JEpVMtnbIfxKWciUa O909YrFbiquMa8VI0mxDs8T0NcDsPBdhv16JtuF8TphO/pS6DZV4nG9WcWk0kOGO+6UgcGjT E8mLuRJVW7vjfoZ9a9VQIVl8fy++W+argVHP1fe9jZRlrZrz0vnu1oega6ZTrkM8GS2JR7cE MLNLu1OwpOaP6ELzgzfluZOufjmhNvC/FR1scRAhZWfRCnT1PPdYN8v6HBWWM7/kx9KkKU9m B/O0vAlx6o6FmjXBq7bBmU4byqSV726yG7PfV8ZVm+RUwUv6tnI1kOSDveeq7vMc9/11fkJs ea5qIoZWH2lR2DJBUs1qrqumsXn9Zhu4mDnrCMlzmIBzwvTwGj2vatITdBoE18R8N5JSHI5r N7D+KlFwVatRp36WaFyOdnvjl04W8+XUjK4mL8nlJA5phHoK16nXk3O77Iq1Y/JFutPoCls+ 2SLXUj0YlxSXk7uKNd0S3TV6I2VwxFgV+2Mpde90woktN9neaJvqrEDLzAe7rmKrzhcKbWrm J90KgUlcSconMCWrG4wjSyfddFbYnwz6Prlhpl71gH2fwCNXJ/34PWouEdqM6t/gOp2qL426 JvVktXCdetnOSRXQ5G1NMxjTS9BWn97LqnHki+RyIyIpO71tx+SVZp7M0QY9WhBnkymRRkfa emcQmQFxJpeEOsPiPLnmgMB6Tc0cSnNBmRSS1vL3Ta4vMyPGflGoQtKQeO8lwUgepzckO+T5 UXP6MU2E7npXbB43WdfqiuXkrSnmqbfpnLzW+RGMY0jN2b6sk0RGxDxK3qmzTl3PRdxk0qMU jgIOHOdIZXBCvwC+fBmSTNm1UjG3X56p+ni2PHO5H8Mp7FJgJC+YehJnMT+o0KhJRS7bPEbe aiJzTj4iaaciWTJG01m4GVEWg2y/XssiFDHofkRCk9OyITZP619Escb+oFETWxcHM6PrNFHa u4rrnEhyNI2azO+nXJL3oky63FUyTa2pxkyTxeXMEFOBKOigQtOV5OpBPSkA6zhVZytRwJqK dZZeJCmRFyRK1BUEWJLZTIXzkhcmIJg8FXCx+qkxaIVQs3miZxfbMbG6JiJp+lS2mgAgez6p P0YOZXFNNoXxm9zoynFWENgwMT5mCS2aqA7+Pqo4X+2juo45vZLh1bRuZ8bq5Ps63X21bEgs 4kr8xFj1fNATQp842vv59zVGDwatHrwV80OqbEi5ee8knQrnotHV3pSraRLGwGnJTNsUrkQ9 uuCiYuz6i2Mq0WbpoFZKhLqeuGyKKGXdTWhvprRotPyGPmwj9Ecpk/62ElXsJKq9G61F1G4z pALuNC0ef87mCUaK+cvqj3V9IvQ676/lipCUIreKks4nxj7oxS3EcZk+0KIvitUUUfx0bmg4 gW+KnMyRyhJpKuqlgu5ek8tJQegyAcDQf4p6EiKUEGdN59P2Rx8ZQyfrqenToxVMXpoWcE59 KuDYF+ielyAWpswljRovj1KEoTEcE92wE5gYplrv58ooflFLKylcT7tlSXBO1tPoZN93/f3s G4T52DzqT8oOuKbnffPVoJWDHi7xYlvePZqhJFszZz661Upmr/LXbZ4akoOeCcPqpGi9IglT oA0zNn1RonE1kPoA42xzeSpbYgW8zt5uoWVXiZbwc/x1Z+l8GiVC6z5RcW57+HaIWmt4tyTn ViXZSUcib6KbRtF1XSOuumBz19rk4LKRKEw6CKjYe0Xl10sCzGgUnK4G8l2mq4HEZPNojpaT j0nqT50dM2NQlG/rNHF+UfLRO0ltazjGNUpRolpLZmqJy+L9cRijfAe+X37wFtpx9gpZ3UbZ PeJktk3T+UhKQCeuYu9zY997PQiOfD92tde+/x7twm4uvmtK4Se2ZVnkzUxKjnJdCtrudXcb wiKy8SyrfdJkZnV+MJ0mq33oyzX1ifPrpUTyjc43o+Xmi4QbvPo3Io1X00CFDPqCy7MSnJ4T CdD9eHfrFvcinUocnRHk5KRUxWmST2Bmq6pr0slRgAuu0E6nUbtSZkbTcXHqVDd3/clBvN6v LDBtnKQLY8tJAo5pd7M85UhSSThXknt6uJ9pbyYPJMuzqgZnWMNhhAvJEnW+aaL2nKHTPwMf g6ufLA2uSXKTzZIlNtLfH95P3h992WooWD0kSyxcxX3ZbS0BGzLbjep/9N8jSN6+RkLa6flo eVhIbjhd/3rbb1gPeoaECWK6AR3cS8oN0q58GXbVKtGtBaZjnjifopyG9bQmIr7bpp0mSxTn 34vvlpkuafpzZxc0u0Ou+3nW1Qw51aSgLJXo1ewnVIA4lQd5rZaVqHk1tSlPxkUe+2E1pWJs FWdb0rCNmlc/l1v6rejimubeuUVPGDMfXnZzTW8zHCzkx9Le6PGhJpMqUle2fkid2g1TDhJ1 Juebs9W0L2/Oj8mpNXNb0LajJ0yKOsUh+8mYDWQ6mjVfhNVUxKlIxsW2KodSJmZRHaUHN+It tqwd+FwXN/p9dTcyhWucDpIMOcrIauSDKCO6n4SBLPD6mjhabJmYckbDapgYezqZvyZngB70 mCVbtZ0GUfsm5/8pBpXvT9Icf18qzWacEnlzxqXp0xfp7lYc/Lbq6eWjAB5/dvSspaXE1ppe yYluH4sg5Si2CEuTcmZNqHNbNbdlxPffB9m6aArPpNiqbGlTSnU5qhgI5xnD1O0WafJ9nS1W P2unB2+ed0uX8+s5IWn1/alnrSlKek7LpHB6JWeUmB6y0RTagQY9OyVqY679tWH0JNYyP7zN mZTiYLqV9UVK3rZ1UUbISpgejfKoSZflYNByFV3ShmK2HrTyfE6OKkJx1GO8nmuSp50Lzldc kJxjmhgTKsuaSFQoabmcDDO0xXierAe1hElFo8QlnfbMrI/etqzl/ZmikEEzJlZPFI49+uoG z3MxP6RCuO/zY+SeU/pMg7ZhOIww2TCZH2VYmNV8Fprq2ZoiGWFrx4LQDTNHMfREqKzPL75b ZqOPDHcJ6uTV3hREnq3J8qeSLBSSzUGTqWbDzcY+CC7f3YKR2eFlt/S2OEcRTwSXgeAyH7YN fRmNMexgHM3WaO6xoInLc2TB13ZS1kRGyxhE2C6l/tSgsCC7h0lFmIrYrkzbmiQ8d5N7Xsow Ac2+o7Z0YbsN2Swo9SIHTTbWznjzbDQrD6/l3IuSmRKE2dJXiXICZoayIZoNKdvdhkTt4ok1 RXJDw6qhnrJQeCjFjbR68OtsX+Jymug52annPha2eT2x3XQeNYNn183P8Wg3l7ANLRFaZJNK 2v9mKDmaJLmD5RKcWmYhD7vi8SwlOLtRXZwsTMNKJJlePRCIac7Dm6C7uVdP4oyoneSWs0Ks Donp5XtkB9NV0vvpSUXKfSWO87gbPg9JUuiedLasCF15jqdIiu6+s9xy4+rnODtVqPv8Doue 2KTnjKIdOPUMT7SDCWHKJzNN6MPgxjIz0/GsicaNEo2uIBD9WHDZSBBw6vOBqO+qnvbXRiVC rSA9bVEAu5kc7GumCmNyojbX7sUV3n3fpJ7d3DdkW02GSfOXtZcYB4LTzk+ijNXU1nLO2Gn3 uWey0aB0O4TVkS14u2xSp8PquarRwgMF4pIm65+WcWkm2svcE6uBDH0B51QgKfq/+Xtw9jY6 Qp8GsRbfo1btKui5alGmJzRj8tTE/e3LzAiR/A6e2OycbJr7zjWmKPojnjaakrGVEo1pCClu F87dGusnq0v3e0XJvaknh4scOdunTqU8FzPALypw6SXXWpuHyHdTR84ZBLCi2UZlB3Q0h4Vz BatRAjI7rCtC0CdBjlGKOXLRmiJbTsY3i64WhvL1+e4bJkGxwtfbegJELaTGFU+JAmVFyULH peQkqLgTRa+qNe0k+8lCuXnRDvR7pDI7SzPhw/mcjJwMWdBk9nwUIi7nqrXmCiv6mya2jJxT NEM2JNvvbvk53gQR0v5Ndks3AlucOZWyivVFxWwfIj/R1tRzqoBap5Dlq2lfdoZnb8OeydQD nGPi6GmUj74/4ettX1Kwv59hU9FwWn0OOuVkj0JVeDtPvG1Cj8ws3k//5KwMndXIAUQ1lzWh AsSJ84Hknj9vwvf3M2TxN6FhJ76xfa5Ev+BJ5DRI391Pvq/1k1yOtwpCBxfvvF9Ukl0B58Ez Wee2uVcdTIL4Y8x3tyBlijjTnpeg55aTqRjTn5sXYYRR5lsrvitfFEjW8ZIYwWFbsAlD2ZXA cRauyGch99Nz1VQE7QY/AKsp0Dm3j7E/SRmjpKbrgQY9a8H5lO9GIU52S8v4P5knYxhhmdtw 8F1FjdvId18XxfNOvo1Of6WRRUNR6GYyp2fakCSDHKPMQm7NBEVyKP9J5MT5ybd9/hjCkt9g t5yMZmt6XVdKDOaZOmUXMC0nwZcsW+R9ViDP9KNluvv2BVs1BL04BzX1pOCoxFwZM4vKmepC aqGorZCKc6NGTvUreT4pYDrk5gv9OVmGGJhJ1Itr8nMP7ya6EO9uVLiiX01dD0RlmTAV5+6z 2+TZXmo/7r6ym0c36JLN0jmZ7tGafadMTJ/E8+LHRONuLMib+ky7U91ZbbfQA2VFCb92SD/R aQcMRLVtvxuZvqRipounERGi3bfILDzRNiS+yGmuNdeX3CsQl6B4s7y/UGhDNkw8V1He31Aw uKnmufT6XI62j8HMd18TJmUlJE+2sPoyXmbaUGxtn5iegp67xT77vlZWPyNlUtjW8hrFZRZL AgavtiDHuTVUAbuI6WTfDr3VwNmQDGlXtLRooctS2whOi+7pblTaMpM87Yk9naEZfBsLSAop Dxojyr4IX6SzmESZiWfSkro0fo959iz1ldQ6f1Nh+4ahYLVUr7U2A7rlnHZ6zi3n5lrUrtvd 8vvZhhObMj7J2YFMOyBvY4xtFgUn2u6N8SKJtCv++pZXtii+JvoY7RKw2p+kLI5n7+ykLAev RKlxs++RracaxK+AaZHnPk492Twz45D7bqkkbzff9P3Jeh994atzk8IIrZwx9b4SzU5V7L5q bdX6fEU6i0ZjnkkaDyXxFCdFEM3L51X3xWiWqIgk5etNAbyJZ83QFIqOEYNWdYPIq0s5e50X xMAJYFW3ObJAMXCjLkkLNyexpAVBdJeyxKXzVqIYpAiOMUVea0lGI6PFckwnezqnEejF17Ua Mym6VSo9V2ZSpIwL3rq6zT05+TlKq7tvLbZbLHDf2Ba6n8SE+T4qpzynsH1/OVNyYxqX7W62 pl3eclH3bt4wbi5F1JjVr2bAqpeDje790erSdJpzbksHDV3oOtEmBgY1JpE+SbOUJ1tjYvX9 FVEvPk08f7JuUL5T9bSH+bm0ZpuhovQc0Z6KzLOpmdiCUmJVQnLkJIC+b+Hp7GNiZXUuECFv pWAyrY1SktLSB9MCv3VvS09jJgWv71dnkxclEgzdcbb67k2y7RuTrs70/sr7UeZPuZ/4Dnye qVNWxUr8tD7ybml67dQ2TODkq2mjiFW/WoUibzlXjak4k7INfBLgpwV+F7RTjSpRbShPZUa5 HIfV2SnxMeSudPPV1Ip63N1Pc+m5Ineg1wxhNF6SPJ/PY7Kz/lJ6B436sxIFl+9ubpIOpJUq M81QtsYseDp7282IZzLmUU2OzwulKnin/LHn3g3pO+r+3HLyfI1GTbaczoKq/+TPN2ay7QQH PniWkDrPIFiZ+9P74dySkzU1RYyyfH4Kn6CTnsjn+vzyKHflUjqGRtNtaKbdWBbds5P5y+eM jXrGG959/Ux7blTb0PXUFCWNw0gcUTQx7Sh1RvS8+G5Zrs6aWi5qkaPiHIVsRMuFKrvRTL/A 5dLrnlgov243+sQToURFyEs+Gi90tCZ2I92PeK2KN6RuxfEzz0GrniY9F4xFyb04Sf0kyV6i RNyrbjUruRf7KBXJXGnyc6NuEE1qMDHAySUQi6oN09VKV1OrUVL5bumt6loc9cKeiNaH3JYu 3p/W6NHR3Bbl4WOa4vWWZ0fKz3mK2RHEVrVao6dItuGl/2xpJ9nNrUQJCLBapjYczn2tpIto iqohKY74eqB0EYayv1sujECAwCzGcbAtNf1EvltO/+zWChalMYRpMcbR1Iqv33E/JqIm+DUN 73kB55TfL+fxpn92iwH/lfJ4iyfRVbMCzt02rTyeFBWLebKm7mXRP7MfOVK9FYpfc7SOUn8p OHaeh39aRK3TVXNtqJl42rmqDiWU4PHMRc+8LbUX57WwptjSLs8LPs0jn9hWdck1fWo+P4+6 6pQl+b6SjIZ4w+n38E52J7K0G0534Dh1YFHzLLO11NaXGO8Y8gLEfgJMt5LKsW5mhNVkdwtC pGiJWorgnj6f4dKStuYoQk6eZdhjwsSHlyipkM9fjarTmOwivcPA11Z9zD0T1JJ/x7ueH85s QZ2/jTAdeXI0z9VdKp1vUjJTquqQNVPPfWGuT6fCjFJrUip2S9HOee/jKDNfa8041sbnqQNT f5IixFZT7L6a913GC61/zrh+t6Tv8fKe2CwG0/cxV56rLIS2SDTJtogJXIPJ8Sl3IwVCFdcv 6HBDNRT94KlrfJE4UPM8cgKshlcDcl3w7mZ6z272NZIV/kuSbXRfuiigm9pmIEgMJ5pkT8m0 ZlI+O2LsC1bXGrWR7ZZpUhFQUntRwrps9mbvz9g0PefxLk/24t2Yqi5xuKzjkpRT3TmzjWzQ mMkoNbZiEeMYzJishAeiRGSHPLHmNErF9LS+5t3Oa54F+u5aoyRwlAXHONZ9FIgvYzBrpZEl +Y73RU2i1BdIJj6NafjgXL9aLe7m+nxawa9PdTdoG2GM2vCkV3GFbSUg5ByqiMnuE4kK4eLz qCZv4ujZdZxNoI2D515ilLOYyc6WlpMKSf7kfe7J7kzE0bfhnBTojpP7lefw1mg2gSAxhG1T 3I8Tz3LKIaXraTyMUWazioWNVknxsnuY4py7mdQxkJpObT1E1TXzGEfas+y4u1EB8nw11Rht 1v6EL62HvPS+r3qR+SI0aki+b5/qbrjftMqMVBFyw/3qPuovT+xas++FE+OGoqZY75llWysK H27bfr1Kc94yCLBNvitOL2JSbutzmnTD0HJ3P6oJGIRQsxJqMfOtWY2aFELDuDafbzz+Os1L oiZIck2HlhKD7tlWzfpLNALfz4gtnfKaYt5NUvM1kphZfWGcSm/Bd+B7IkULVhfJrtK4uwXP Meh2GH9hTjAZDgCter7Z+VBGDU3mL1UhoXRxyuv7+j1iYqeWtJ6TGeWDcl3NeT/JjSExXK1X Pk10g3y0UE6WWkxW5r9MzM4F5XS+j09vuYYLpetselumjLivWuUjNQ1wndPNneYz5sZgzyQn 89HV2bLtW+eetT4GzsnsLcqHJz+uphLfQeE2GpFt56uLKmf9akXl4HNdPI4V4xx7iseqK7pa leeMfqL7dUtrMTt0N28GTzHXuw23+Vet/xoa/b5FAWxeTVvOVMOzo1tdkp7LUK6SuWdNc+8E TSNfVElJk9wxWiGvDn1UWFiM+ZvUxOIY5dxWUG1DYiYNqxNDzPOQBn2yu7WarCmKrlu3Ba3v BsJFC5xT0PIYtTavB+0020bSKLh8fph21O2lwDktF2Wul/F7RMHnLa/q3UYSy+wJrXhiOe02 J071YmupNjRLVGzlnFETndoybXkbRm1NCA1SD3U393MetDNu5asZPVkoUjnadpIKs2XPc/KT c7K6IJh6vi/0uXcKz65txhjMWgqIyzn8Lbpev2+wmkg59125frdjT7vEYNZDIuAl3lceiGI5 F3MNBT7IMEx3cpowqaozpCIsaX2nvK/kkmp8zAkXLVsRyKHSGaEchO5k+7CSsaRcsLoZO8kN 2bRlidVaD6r54CHK/mrVuWYpQ8Y8zEenpRys+rxoXPfAk+2S1CsXTcgX1HwBtFZLZmoQcMhz pyY5+uB0ICal/oO8T0HoHPkw4noJsjxbm4e9SD1hwyl51JXotYoBWVrsyrG5qa8l6KRkXB3y sIhuVxmL6rDa2Vlj0wK15fJiXNI8xTKcTeFqaic1YYzg1zFMlKFZlRQrOHewovy1eVCsmaQn SBJBFCWxHOHSC65Ea7WQ3vL9pn8mjZfVoL9lXFq05qFEnimK/vRziIGaxEGOnXXe48j0i+X9 goQxjPfLltPpn3GMmLodlEhZQGS8SFCizVPBSWJd+XtgZIaOnun9UdBkzc9XF65EqQzktWRm jl97Um/or2xK8MER5a80zLzReJkDklpyVBAhSq+RH/RMjEFeqR1hoVqVI83Vg251kWz9mk6g Trlrjb87nXdbLSrmXJsUSKb5Mct8rKnRgqZ3qPM83kNBZ7ofB7SIqzP0B8nzIm+thn42WsSq APzqifHLXl4ThhKwdb/9Zq4/+R5JjgJ8m6trRlzvXMKMzR5Hx4Na1M7Og9CNhtEErWrii/Wg ngCDHJbjTDNU5RjCXqaubKnGECQPf53Kug2MCEW6a5TtN9ZWtw7b9GFw0/enecsFkHSuQEhq vj9jhMnz7lHXqU9mNiBRU1espJYLkmDCuRIpk7A4Nt3ZDdI9sZkAyWVYnZHsTN37kyKIfYHv 4X7iaufy3Z6dOZTEQ9XnIYg/O+gW9Uoz45bqbvRDZuYkijHn6pwWBczVKzmb6PcPZwvnpBur WMUo6UWcV9cundW+fHqCwvEsoWghqGlehGTXdExrOTJU7AZrKBd/qyHyM9O8kiJGNqixUJfG ZV/QmIPMeLds+lRNNDvmq4uR2SbKn3c54uL7MJWq1rAIS9G9uls2S0GsrWoHmvqpdLS70dXE ZrKjBGk6O8LcNdnnUQ6S3sG7ulxNh6C/xMCgHMMHPeZeUJ4lBD1I0Kk3eUlP7ySokLO4SxhN M6biGnS/6UGPpHcIQROx2jwswmvyDa4a4mW1GsrXm8UaVrpaeXX9lekEJgfJXLWBlkcxVsfk MdMwM0mAGKJ+X1e4TsVVzkCo4yBWSnGj2tXgPJgelInrLyjiYlMRVCy7MR0zR8sFkimHH4VF cKTPPD2BVKrrVxfKT5q7mmjXM3z61Fl5dD8OcnQ9EhAKY0Yzo9ogB1tUz3z6PQwDyY4LuTa1 VA1pgiZ/opKF84N9CdXU3aPTLnJjpg+SpfsJcMkYMSuovunTd0wOLr0Y00GSK3W2fj4/egSE vq+URG1i2/e3ndeM612xQV3t5e5hwniwmjgBNWfKdf38mDlfFDANXLCaUi/mYTStGQ8u5X4U rDImV5rXeBNjv7+fK4xpo0GxpGtS+HR2NBMX1j89SOYTFU5dmR8t1G50NmlAZOt72y0uHKVI lGn3/uTg3Nf5bhTbMfGxlVSEQ2rNxRp0rZf5q65xWxeJceMkLDHITOrHs6YiLNbTfr5JcqDi YNW10zBMQcqkKtHgan/93TJzlYhu6tUV1hYV8ni1TjSHu/nDjnbfTHaPMkjUaU2sIGEHprcN htk2BsUmL2mZTcwPKorVQJIN9au9KYLW+oqFrJsmSRbh89U5+7qdbiyzTYEjV97PjbavJJ5N Ysioq26e5ll3c13tTQn4TSog+iDLeX+woKPP57qa1jjSqiE2fz4rSA5TccnK7B1qYo2A5ES3 D4IjhyRhTa4o4Dw9hq95NbVxSGVml5KB6OqiqeDKCpxNmlR85IPGlFI+e4v7qa0gtow3vpi9 aQzSs6ybsm4f++Q2Jb5etXKQHDTVX10XyXfaCa4vQaxhWJ19D5QteK6ipGk3Zao6DuEXaamW 1d72QX/1QtptPXgLsbd98+erOcZQ4PEoVTniEBbR9LbvxBWryXKCFITuLK9cG2riqL1YNu5D Gya70QwglgR0lp2FrE3mnrWmngDEgq83A7A6pPGeri9B15fYz49cm9QwLNYmxbXr2snqXLrG h/XAqW3eFrvbJMzHs+ePAV35HqGyM1u6aVS7l9W+zrXTrnf0z5zONqkV6s3ke8x8JY2k8gyS CJjyC2fabp9GnvZSz9oVZTvLdt+kP92vL73vKurRQv7+pgfxHFQcm+HgPC4lQ9Ld0upRVOEa T2NNuxRU++sDBcjVPgvKbnX/kKDirr9F+ompNSMH8cZPdsv4Brvl+DWMhlAHOWjUTEZDbyv2 3BmOw9ZMAzSHNZFjt7jGWY0jAd5u3W/yZyIbv2LPH51Ppyot1JgxWr/0nvv5ZsClORRn8X5N uPd+UZ2CnoO7yTO5cD9b1+nO/obG+f5+7A0a7zexjYQIpOiKWu635Il1kjaa1XwTHHs6u+9B 29zsoDbI7PD9QWiRiFWiEsji7LRyijvwVOjS8NkHuRLny5UwKcGqMp4vV932OxBbjecoR16/ eAUk46Mp1QOjD6jGvikOPkIzTl+KJ6bsXLEn1BZOooyzdTO6/gZ1oO+wFNSNmpun5gzcQlw2 i0XZjNWSqJypswlt4Yq1wotzJjZ6MopKlFyEzaTk4+Tk0mt+h4bjLKkuTPZ8Xv31LRfApp9k ZqHlOBU/zzZEXiF5PnF1tjm/TmjT8P7YLdAZH6GPPHA9MT11Hlgtgahx67kr1qVJEavAUbZM wDZ9FZKF7EBaKkyNwaKsjm3GPPxeChoLISldnkUydONF4pCUcSnyn1j2FXR6Fb0/zwW6aXsd qsCGMqqTahAK/y/qRn/QNnwPjWMj11vi3J++7V3jYy7M6fP1RePEGGxjHrVbK4FJ09vx0ZEb cyW6eSRItx1pnFmf+Tg3P3w9qdIjR1vtUIC9WTL2NZuPFBn0sShp3LoxUoVDsLrxNzBvps9m Nt1+reSf0EzPqYgsUUaIz5l1/A3ZvUQd+rr89ddf/sf//ttfzUNl1IYMA/9Vy1W03aKY6i9T 2+5nokne0c+nGL6q+qFPpdc/f/v9p06L+fr1l19+/9HPfffvb3r99tef/vUvf/+3X6p/qf7z 519/+8svf/8/Kvv/Mn/4f1R//+lvP1eT6//86U+//+U/f/7jL//6f//2f1X/59//+bf+r9T8 5f/3s/ztH91dunt2/+MfP/2Pn38b/uf/Uf3+z7//9K9//fm36v/8159+/9O//+mXf/799+7H /vqXv/2F2t/+/adff/7zv3VSfvmVfpx+7c8//f7TIJj+Qy+5/7v80k//+dNf/vp//eEv//jj v/3lX//401//8tNv43MbOS61snQoOM9/nT5TJRH8WpZoKl5+LWvqXtS///Tbv1elKEMhuhVp F8Pf94j69R9/+iNp1N2LnH6OZmys0kl2LorVr0qTDs5E+awRUb//9Nt/ZIJ6UYYVGUnhJX/f 26u//P2XP//8x95OkH+YNJqpOS30Kohesyyqzps//PPvf/lff/ztlz/9R9YptVwFPtoqKmQN DYvfeUzwmB5lZU/ELoho1r7Asle//+kff/z9v7qR8af/+LkX5Rw/qA89e02NWylKo4+06bRy FtUtEn/OhUmvD55XJOqXf/z89z/++vP//OfPv4ksYmn4UdKeF5iypvtWf//59z/+4+eff52O wD6tVYx7RMWsqf/w289/+sdPv/97PtTzT7rtW82Hxf/6t1//9sc///Z7IWv6Y1uncCmqWwNL QdZKLYI+5GyTKCPlurRhUT/9+o/y5fHt+c+DF6af/mu+WAxTnEfH1tWiFPXPP/9jSdQj1kCa V6WoThunzUkDEoyW1EzyYu/dRBRU7jOb+eYP//bXX/5r4WM9YrD/+W//8tvff/rHb//+y+// Ig6l4eaVhmFxSQ8OtFonymZNLurn/7XYK35NJqxeAxd69adf/7vbSf7yy60XWPGpYFjY8NeK +uPvuZT5j21c2RdELUh6iKjf/vTbX/74p7/9OV+aODk8xc9Ro5nuFobFD+eVN5PGNO0f/vRv /7Pr1p/++I9ffvnrrV4dNCxIVCGm/LE+X+tuUb9+K2rrvJoNi59/+vNfu634j3/+9X/eFEXj PO3er3767Y8/ZULokmLipnZ7dAuTJo1v6j/8rVNe/vnzXMHVpf/gXeTfvtOk+1wea0WVb/Dv //bbH//r17/83n2t4Wfo7txI1fOtvSpVJhL1azc2MkmVe4TSTqK+M0XSMdswiSKzuMqvR9gH f/ntl6V+ZcNCscO9vfq3n37/dgRqNp4jRC0ogvl6W/NZyt4X+PP/+t2W3eLiGOTnt7KZiL94 wcT/Ua88R4H3DbkZ/+9f/vnr33/6a2c6/v3Pf11W2o/q1SCqm1u3XiBbfs3uEfjrz//5y3/8 /Mff6ZdvieLj/nb3LqKifv35T7/8+udboo5RLrph4RZGe7Za1Hqvmah1g51F/a+ffv/912p6 PeZb/eW3zhIu+qUdUbxW8h2unsOpmTa05f/9l9//8m///SNr+LA5/J8///33f/zy17/+8R// 9T9viKLty9QLS/tWUT//4y/Loo4ye/6j0zh/H22QJVFH2fgk6l9nkh7Sq3/76bf//vufZqv7 I+bwb//+t5//NpvEckRvrMJ2PF5XLu3qAe6bTtQ/fvntL/+rM7L+9vOvv93ah49S2//5lz8v bY6i6IhGsVW7KJXO3/4H2Qf/orZ2fzlxfMsL0sNdPo67358wvMGmEKWRboMo1QRZe9dzdDfv 1Y9FmWkzitJ762WD3FzSSumR68IQ/OG4CGHSmLoZXmCcijJOuiAyNtqo+RA0pheVfalKS8Iz U7B5ubBu2sT6D//61//488//SRbxVFYrvRKtnU7T+7/vGYEqig2tyceSEeh3KZ3lsYiKUpe0 Ho5EcRG3rSwRvA/btbuIWp1aNdZ2ov7yy3/+/Kd/+d+6D/L/HDslzgNpnAYV6B/3DvbeK2aH eaWi8inci5IifUFMu7BOlPql+mYUlU9hdRlShGTFpWgGUfd/q/54TRsXhl5l88qLDG02DnaZ m30z9qpYl1o5NtFAvI3LbTNt3PitMlENr0jWxj17o6knjYssqppdEohhNQvdxh1fk/pEfUHd jv+Xv/78x7/+8qf/yHct9STLe2ad0y+s7Cv3K5JSbPiOcciqr1i7bbl1EjinDeGov/0Hnday gaWyDEEkFAfsnNs+ApuGaPO+oawRf1g4PKBLFhW7ZxOZ+b8pcHRu9qjrRxrZUszSKfQPRbms 6Xr1l/9RrOp0qQO1nhxOrl5u5wfeP/2ZtLNff/75j9Q1lhMMpW8mwEqWWHa168n+vb3yNQ9Z begn//CvtIXMtDNdTY71nf3t70tOEo1V1Gm7UWmfxUHM3T6U2lrcjbIIC5G3eli0btqwp/jv v/9aWI0S1mhqTd8pipNdqUg7KYqujTGeFqZ/VMUVJdo1NmaHgeWDnzQUEktRNr/NvpZmdOHG KzK35Kb70S48vYd8qz//+se//vTf+YF3lWS4ybeS92hXx6zMNCaOV8mcTN5zKq3URw1v8uob yaWjDYv629/++Nvvv/7zT5NwC/rtOGk26uwz8+A///bHn379+adMnkmcDtd66UnF+75fq1tk 5gEbw/MxQW9LQpm08xt1i/Jb0S48lyYnO9psXJgy3UJXdvI9FsuFfB0T9jgulkSRNzWXZeow NkZN/LXarTXThs7Wf/rtP2Zj0KhbnZutBmpmHvAR1t9/+fsf//Nv44EIXV78pxqcvtWlOtvw /8fUP9xfGtbhVDPdFuE2E/W3JVGyHEuzdQ2c3qOSYfH/+/lfjDOdEfW//X/+v//v3sYaPCny T70oVwwLUcg1xvlbJ9Moatqth4mKoTPXpp2a/Bj/Wy+qW+qPEDXt1ONEuU7/am70iv+tF8Uf f7+oG706WJShchA3emX6UhFySnSIqBu9OlgUZZ3OOjX9sT4lNYvaPdj7u43XxGTeLCozu3tR tPbc7NXWhWm5V/3d9OrWh3pstonK7zGKopjhm73aHFC82Kv+bv2lFJY0G0UZHydNlawO9tr6 m70ymltlnSl3q1f93fpLUVunCuo2UZK/rG86q5FFdepX3qn8tLF/Q0f0KpjJtDJUTSgwtiau uy2iTGRGVxvSm6IOixB/0KujDrB6UdNPVVk5WeybjSpnO22GYWGbH/TqqLOyXtS0UyZ62XLF StgoSi3T4DNRsZhVxRMdFLKiorIvxRkIqNB12OFQ9XL43Dd22PB/2KuN2u0N3WLaq0rIvW5y qX9om6g2TRs6raVjzdKSU8PqYPvq2dwSrmMu4f/sQ2Ws4/+88H/pqwL/9/iLZjn4v/V+b/B/ +3sF/m+HWnES/0dHws/m/9SbeQr/JyFM4P/uiTBf5P9a8H/vw//Rbx/K/7kI/u+AXoH/ewf+ L1rwf3tFPZ3/4+DVI/k/0pjA/60VBf7vYPsA/N/OF3gW/xc8+L+DRIH/A/+Xv0Hwf/tFfQz/ p+em4P+28n++j1uoqu38n/oTwf+9Gf9n7C3+T74O+L9vAnzB/+3l/7p5dRb/F8/j/6or8n+u fgH+L0j+uwP5P9Ms8n8hHM7/9b2af6xr8n++3zq5eST/x0nmD+X/eGH6HP7PGCfNW/J/6Qb/ J/HKh/J/Vfog/i/GdCL/p7s0+L9vvxX4v2qVdvty/F+QN3cK/yfVKM/h/9zYbOb/3LQB/1eB //tG1I1egf+7E8oD/3cc/1e1YupJs1FUdo+RlLsW/+ebK/J/Nj2b/wumFf5P3IJb+b80NPTP 5vn8nxxGgv9bsET8tLkk/0dezifzf4GP1I/l/yL4P1yrL+H/3ENlrOP/AvN/yXxV4P8ef9Es B/+33u8N/m9/r8D/7VArzuL/avB/4P8WRS3yf1xyHfzfXaIuyP+h/h/4v5uirsb/of4f+D/+ LfB/Ffi/e18g+L+doi7G/02hPPB/4P8KUeD/9nws8H/7RYH/u3+wg/8bXtCD+T83Nm/H/0V7 Gv/nGvB/K18g+L935f9OrP93i//z4Y35Px2B1ex6QP0/e0n+z4cl/s9Zir4xnaC0XTtrWtYQ tBl6Nf9Y4P9ejv/rNnzwf+t69Sz+z7pL8n/GPpv/Cw0dN6bUiD69kf/jxU8bLiIL/m/ntwL/ V63Sbl+P/5ObX47/m4zyzfyfnzbg/yrwf9+IutEr8H93Qnng/w7k/xrZ8KXZKCq7xyjqWvxf T/SA/zuU/3PWRM5blGq/VZSJicxBbSa9Av8H/m+hV4/n/8zz6/89gP8zDfg/XKsv4f/8Q2Ws 4/+i8H/uqwL/9/iLZjn4v/V+b/B/+3sF/m+HWnES/2f9C/B/fd3mM/g/7hX4v3sizMH/rVst Xo//44Ai8H93nFGA/9sv6mr8H+r/gf/j3wL/V4H/u/cFgv/bKQr8345egf/bKQr838pugf/r G/B/r83/iTkF/u8enmKR/1MnADdb+T+9ozbG3uD/RNuUZjP/V36ss/g/057G/1l7Fv/HSNQi /xdlcQX/9+MAXxfB/71N/b/q6fyfEX3MJnWTb+T/7KQhnmKJ/7OJu+DauOdcKRuBH8X/2Ta2 R/N/9K3A/615gdXT+D+qefBR/F8cm8fyf5ZG9qH8X2eogv9b16t7+T/H/F9SUm4j/5fG5uP4 P3GUncP/pUmzlf+b5VdZ5P8eEp+6zP/pPsjNZv7PTpvb/J8fm838XzNtPo3/i2Ozmf+L0wb8 XwX+7xtRN3oF/u9OKA/834H8XxKFQJqNorJ7jKKuxf+h/t/+08al+n9NYr+FizL0tvJ/dmi6 nzER/N8hvfoM/o+jvg/l/9hzBv5vn331bG4J1zGX8H/hoTLW8X9J+L/wVYH/e/xFsxz833q/ N/i//b0C/7dDrTiJ/yO14tn8n3Pg/96E/3O1Af8H/g/8375egf97B/4P9f/A//FvZfwfRbaB /1srCvzfwfYB+L+dL/As/s8m8H8HiQL/B/4vf4Pg//aLAv93/2AH/9c3x/B/1l+R//Pxgvyf uVn/D/zfXfwf6v/t5f8+rP6fFOXzzZ4TmCxG/xb/163o9O/WOHnPG+v/tZOGYNfP4f+sM0fz f/QCwf+teYHV0/g/XpjA/63q1dP4PwP+D/yfvJNpA/4P/B/fBPzfOfzftALl1jUwq2JZgf+r wP99I+pGr8D/3Qnlgf87kv+TjTWlHQx0do+RlAP/B/5voVcF/9dpt4n5v7CH/6PDNW0mosD/ gf9b6FXJ/3WWVXU5/s9FPuA2GkCylf+Lk8aD/8O1/hL+Lz5Uxir+L9TC/9VfFfi/x180y8H/ rfd7g//b3yvwfzvUikX+z8aj+T//CvyfhmQdyP/Fm/wf+2jB/90TYQ7+b91q8Xr8H8cdgv+7 44wC/N9+UeD/wP/NhsXl+D/U/9vSK/B/B9sH4P92vkDU/9spCvzfTBT4P/B/4P+WRT2f/9PI aPB/W/k/MbF28n9KL1yZ/3P1efxfej7/F3oIQn4a/B/4vwr8348GexaIGM/j/+xn8X88Bg7l /yqzyP+F5A7n/+pX4P/kBZ/A/5n6jfm/D6v/J+dKl+P/eEk/lv9zH8T/RWeO5v/MTf7Pqzv/ WvyfyDiF/9NHOYP/k63zFP5P/Fmn8H+6UZ3B/4m9egr/J8PtHP7PjM1m/s9MG/B/Ffi/b0Td 6BX4vzuhPPB/h/J/vLYmt0NUdg9xqF6P/0sW/N8hvSr4v0CKNvF/zm4VReCfH5rqRer/yanE xfg/G7i5Fv9nmqP5P86cdTn+j45fwP/hWnkJ/5ceKmMd/2eE/7NfFfi/x180y8H/rfd7g//b 3yvwfzvUirP4P3tJ/q8C//cg/i+B//tg/o+iOsD/7e4V+D/wf2WvwP/tFAX+b62o8g2C/zvg BYL/2ykK/N+OXoH/2ykK/N/KboH/6xvwf+D/wP9V34RXgv8D/3fHCAT/V62ZVx/B/0V7Fv9n LPi/ffxf/UH8n6tdOJr/sx7837vwf91Tg/9b2aun8X8J/N9j+L9a+T9xKmzl/+LY/KD+H/g/ 8H/g/8D/gf/jBvzfvaJu9Ar8351QHvi/I/k/2UQS74lb+b/pPUjLBf+3IOol+b/gn83/tU2q wf/dUDnB//XNm/F/Nfg/8H+4+BL+r3mojHX8nxX+z39V4P8ef9EsB/+33u8N/m9/r8D/7VAr TuL/KJr96fyfzKtT+L++1+D/vhW1yP8ZB/7vffg/9jyj/t8dZxTg//aLuhr/Fy34v72iwP/N ZYH/A/8H/u+mqIvxf8GD/ztIFPi/g/k/eVLwf6tEgf97U/5PuwP+bzP/J/9+IP83iir4P9XX wf9906vgT+P/or/B/6lD+WL8X300/0dxCeD/Vn2rF6z/Zw/n/9wl+b+b9f+UU7oS/2djOpz/ 63s1/1gn8n+6WZ/A/1WtrK1n8H91ezD/R7vwB/F/wmq+K/93zfp/9K0+iP/rz+8fz/81cotT +L8oh7On8H9KTp3A/+lwO4H/q0QBPIX/62PB5E4P5f+0H2fwf4G/Ffi/CvzftFOPEwX+D/zf DVFZp6Ym82X4vyies8i2z0ZR2T04QOuC/F9f0Qv837H8X2yt1P+T7mzl/9zQTEQ9lf8TGeD/ PpH/Iy8n+L91osD/XfQS/q99qIx1/J8T/i9+VeD/Hn/RLAf/t97vDf5vf6/A/+1QK87i/+oX 4P9EowX/d8eweDr/14L/A/8H/m9fr8D/gf8rewX+b6co8H9rRZVvEPzfAS8Q/N9OURfj/2wC /3eQKPB/4P/yNwj+b7+oT+H/+nM08H9vwP+9df2/kE7j/8ZePZz/q8H/7eP/Ivg/8H+V/Jdp cxr/pyOwml3H838UhPMx/J8z4XD+j9gX8H9rXmD1PP6vMeD/VvYK/N+h/N816//ZS/J/Efwf +D/++fv4vwj+D/wf+L9DRN3oFfi/O6E88H9H8n/y2zHuWAOze4yirsX/9VUNwf8dyv+5OnX6 7LH832vU/xMZ4P8+kf9zsb4i/9eA/8O1+hL+zzwUtVvH/3U/1xnoPn1V4P8ef9EsB/+33u8N /m9/r8D/7VArTuL/rH8B/k9O4sD/3TEsns3/2QD+7234P14mwP/dc0YB/m+/qKvxf00L/m+v KPB/c1ng/8D/gf+7Kepi/B/q/4H/+4Eo8H97Phb4v/2iwP/dP9jB/9Gv8wsC/3eT/zux/p9N L8D/yeIK/g/83+QC//dy/B8xZYv8X1tzNG8SAGFraJGugUne0wvwf7XkvzuQ/zN+sf5fuCr/ p3PiUvwfD+9D+b/uqT+L/2Of6uX4P5JxLP9nwP+tElXwf5Sc+On8H3+DQ/k/B/4P/B///H38 X7gm/+fGZjP/56YN+L8K/N83om70CvzfnVAe+L9D+T9eWyMPvc383+Qe7Le4IP/XVzV8Jv8n aq2eqW/l/8K0MfWT+T/r284IJv5PzIOt/J8dmuo1+D+ZDOD/FiwRP21egP+z/mj+7xXq/3la JoxxddghSqwZbXz04P9wrb2U/zOPlLGO/wvM/wXzVYH/e/xFsxz833q/N/i//b0C/7dDrTiJ /6O0Ak/n//TE80D+L4L/A/8nv5014P/A/1XyBqYN+D/wf/Lbkwb1/8D/gf8D/7fyBYL/2ynq YvxfY8D/HSQK/B/4v/wNgv/bLwr83/2D/bP5P/WancL/6fIH/u/eXj2P/5OlH/zfQoBvxv/V 4P/A/1XyX6bNefyfPY3/Iy/JMv+nXv9L8X+NPZz/63s1/1gn8n/q+gH/92P+j3L8fBT/x6sF +L+56+dp/B99K/B/6xRp8H/g/xaMHvB/4P8q8H/TTj1OFPg/8H83RGWdmprM1+H/5FiCi0Vt 5v+m96AfuiL/l+wV+T+Xns3/NbXW/zuO/yMn3dP5PwX/wP+B/7sM/4f6f7jWX8r/2UfKWMf/ ReH/3FcF/u/xF81y8H/r/d7g//b3CvzfDrXiLP7PPp//k2iEk+r/8X3B/90TYb7E//FpH/i/ u0Q9nf+Lh/N/Fvwf+L9boq7G/6H+H/g//q2M/yP3Evi/taLA/x1sH4D/2/kCwf/tFAX+byYK /B/4P/B/y6Kezv/pcAP/dw9Pscz/9TtaVe3m/1IhquD/FCbbx/9JWOCl+b8T6//Fm/yfHIuA //uG/0P9v7fh/4y9xf8178z/3ar/13jh/zSyd19okeyvN+v/XZH/i7E9mv+j1QL835oXWD2P /6Mp/Dn8X80G/bvyf4JE/aMqrjfn/65Z/y/e4v9U374a/yfG1Bn8nxdF+hT+Tz7M1fg/0VnO 4P9E9ziH/5PwAPB/4P+mnXqcKPB/4P9uiMo6NTWZL8P/hYZ/O7KevlFUdg9Sma7I/6H+3/7T xiX+L/pOfyH+r94sisC/emgqPu9+Pv8nS8PF+D+OP7oa/2eao/k/F2vwfytFgf+76KX8n3uk jHX8XxL+L3xV4P8ef9EsB/+33u8N/m9/r8D/7VArTuL//Cvwf60eGR/H/92u/wf+D/wf+L+7 N5GC/zMR/N8BvQL/9wb8n+0GO/i/naKux/+h/t+WXoH/O9g+AP+38wWC/9spCvzfTBT4P/B/ 4P+WRYH/29utp/N/esx+Cv+n0c3g/74dguD/1r1A8H/vyv/VzfPr/701/3er/t/x/N/t+n/a 6/fk/0jUAv+XLPg/8H8fw/81tByD/1tw/YD/O5L/41R74P/2fSvwf9U6AxX83zn8Xxibzfxf mDbg/yrwf9+IutEr8H93Qnng/w7k/2LjxmZr/b/pPUZR1+L/eqIH/N/B/F+K4WD+j5x04P+O 6BX4P/B/YwP+D9eGS/k//0gZq/i/WAv/V39V4P8ef9EsB/+33u8N/m9/r8D/7VArPon/6x/l OP6vAv/3IP4vgf97H/6Pfhv83z1nFOD/9ou6GP+H+n/g/5b4vxr8H/i/2y8Q/N9OURfj/4IH /3eQKPB/4P/yNwj+b7+oj+H/JDwP/N89PMUi/+eP4P80vPI7/m8SOL+Z/1P/UUnKPZz/C+mK 9f/qW/yffB3wfwsBvhn/V4P/28f/Rft8/i+qP/Q4/i++DP93YGjRS/B/vByfwf81MR3N/9G3 ej7/Jy/4YvwfDYtj+b9uF/4o/o9G9rvyf/Em/0e9Opb/q8H/rRJV1v+rX4D/q1v+EAfyfybc 4v8kbPkU/k+9Nmfwf2oU7XFcfDT/J70G/7fgewT/xw34v3tF3egV+L87oTzwf0fyf3Joknh/ 3cr/Te9BP3lF/q+vagj+71j+r6nd4fX/JlDe0/g/daFejP9jSwT834LZ/Qn8nwX/h2v1pfxf eKSMdfyfFf7PfVXg/x5/0SwH/7fe7w3+b3+vwP/tUCtO4v/Ixf50/k9+G/zfHcPi2fyfd+D/ 3of/44CiI/m/yoP/O6BX4P+O5//kbR3J/0UL/m+vqOvxf5yUGPzfSlHg/w62D8D/7XyBqP+3 UxT4v5ko8H/g/8D/LYsC/7e3W0/n//SM9hT+T35sH/+n8anjWff16v+dyP/drv+nseXg/0pR qP93KP/nAvi/laKyGH0dgdXsOpX/U3eCvOc34/9ouV3g/8ID+L8G/N+D+L/GHs3/VR9W/499 quD/5q4f8H/g/743D16A/1Nd7Vr8X+/mOYX/82MD/u/HosD/gf+7IQr8H/i/G6KyTk1N5svw f0nW1hR2rIHZPUZS7lr8n2/A/x3Sq4L/C7Wpr1j/D/wf+L+r8X+o/4dr/aX8X3ykjHX8nxP+ L3xV4P8ef9EsB/+33u8N/m9/r57K/6nyBP7vx/yf9S/A/4nhC/7vjmHxdP6vvSb/Nx094P9u 8381+L8DegX+7x34v+TA/+0VBf5vLgv8H/g/8H83RV2M/0P9P/B/PxAF/m/PxwL/t1/Up/B/ rTrNwP9t5v+UjeEg4q38n8gYwyt/yP9x/Pxe/q/s1cP5v9qdxv+NvXo4/+ebW/xfH9YsPw3+ D/xf9Qj+j1JpnMT/GXuL/3PqDz2O/3Pn1f9rzuP/6kvyf50xt8D/OZvC0fxf36v5xzqT/5Ne X4v/s9Edzf99WP0/3hPflf+rbvB/oiq9K/9H3+p6/F+8Iv/XvRTwfyt79dH8nyxcp/B/Scx5 8H/g/6adepwo8H/g/26Iyjo1NZmvw//V7dhs5f+m96A1+Yr8X1/VEPzfofyfs223dRrngvrq NvF/kQ5WtOEfej7/p+Af+L9P5P8oQAv83zpR4P8uein/lx4pYx3/54X/S18V+L/HXzTLwf+t 93uD/9vfq6fyfxqNAP7vx/yfaZ7P/7la9Tbwf98OC/B/K3v1evzfI0Td4P8k/uFA/s9Y8H8H 9Ar8H/i/slfg/3aKAv+3VlT5BsH/HfACwf/tFHUx/g/1/8D//UAU+L89Hwv8335R4P/uH+yf zf9pnAf4v2/4vxPr/4H/A//HD/UB/N+Z9f+qK/J/r1H/L+iL5OYS/J9t25r5vxS3a2dNyw+o DROoT+f/dAO4GP9H9uih/J9p2k/i/wyPbPB/C64f8H+o//ededCNKvB/K3sF/u96/F8am838 X5o24P8q8H/fiLrRK/B/d0J54P+O5P9kZZdmK/83vcco6lr8H+r/7T9tXKr/17pgyG8hR39b 6/+Ri1Qb8u9H8H+H9Ar83zb+j6zGC/J/FvwfrtWX8n/NI2Ws4/8C83/RfFXg/x5/0SwH/7fe 7w3+b3+vwP/tUCvO4v/s8/k/q4zRGfyf4/kK/u+eCPMl/i8E8H9vw/+xXxz83z1nFOD/9osC /wf+bzYswP/NZIH/A/8H/u+mqIvxf6j/B/7vB6LA/+35WOD/9osC/3f/YP9w/k+CtXfxf+o8 vzT/F9Jp/J9NZ/F/VXOL/2ukV+D/wP9Nrvfm/+IV+T9vwf+tXC3uq//nzeH8X9+r+ccC//dq /B8XJv0g/k/9SjqvNvJ/0+C2Cvzf6hDznP8z9tn8X1OHo/k/HuzX4/9oBH4Q//eQ+FTwf+te 4Avyf+3YbOb/2mkD/q8C//eNqBu9Av93J5QH/u9A/q8RH5M0G0Vl92A9EPzfXNR+/s+KpXIk /1eFZ9f/czEdzf+RLQz+74hegf97W/7PWz7gPpL/I1Hg/3CtvJT/ax8pYx3/F4X/c18V+L/H XzTLwf+t93uD/9vfq6fyf6q9g//7Mf9HB91P5//EoQT+745h8Wz+j6G9C/J/+i0vxv9xQBH4 vzvOKMD/7Rd1Nf7PR/B/e0Vdj/+jyDbwf2tFgf872D4A/7fzBaL+305R4P9mosD/gf8D/7cs 6vn8n4wB8H/38BSL/F9QDWYX/6f0wnf8nxubt+P/Tqz/dx7/d7v+H/g/8H+n8H/Rov7fSlE5 /9ecxv8RaniD/1NuRd7zm/F/tNwu8H/Wx9A1yYXtI7A1bHtqM/Rq/rFO5P90swb/92P+r3vq j+L/eBd+V/4vnsf/xU+q/9eYw+v/VR/G/6lydgr/Jx/pDP7Pn1j/T1ahM/i/WjVTudND+T+5 +dX4v8E9Xm1fA6f3qCrwfxX4v29E3egV+L87oTzwfwfyf0kUghR28H/ZPaqL8n/Jgv87pFcF /2dpd++MgqbZLMokVre0EVv4+fyfyAD/9/r8n6uP5v/I7H46/0cjEPwfrmdfwv/Zh6J26/i/ xPxf8F8V+L/HXzTLwf+t93uD/9vfq+fyf7rJg/+bmVYZ/1e9AP8nbrJz+D8JiwH/t5X/S+D/ dvJ/7gGizuL/rAf/d0CvwP+9A/+H+n/g//i3UP+vAv937wsE/7dTFPi/Hb0C/7dTFPi/ld0C /9c34P9emf8zRsLzwP/dw1Ms839pbHbW/+sbe4v/a8dmM//nps2J/N+J9f+oINUi/+fDpDmE /2vqG/xf6quzyU+D/1vm/7T6Gvi/t+b/5FGO5P9MWOb/WnMe/8eLn2mDbpGbdvzoJs0P6v9d j/+zjWsuyf+p6wf834/5PxoW4P/W9eo+/o/PGY/l/9wl+b8XqP9n0uH8XwT/B/6Pf7SeNuD/ wP/N7lFV4P8q8H/fiLrRK/B/d0J54P+O5P9EQZdmK/83vQdpuVfk/1D/b/9p4wL/Z1Mbqf5f 7L1zm/g/HrfaVOD/wP+t4v/i4fwf+dmfzP85Phw7lP8j3y34P1wrL+X/zCNlrOL/ur8T/+fT VwX+7/EXzXLwf+v93uD/9vfqqfxfn7oS/N/MtJryf6QsPZ3/U8boDP5PFF/wf/dEmH8S/6dT /GL8H8cdHsn/uQj+74Begf8D/1f2CvzfTlHg/9aKKt8g+L8DXiD4v52iLsb/BQ/+7yBR4P8O 5v/EGgb/t0oU+D/wf4NLFfwf/bGZ/xtFFfyfaJvSbOb/yo91Qf5v7NWj+T8Kxr7B/2lsOfi/ UhTq/x3K/7lwGv8Xwf89iP9TZOo9+T8StVD/z3t/NP9H3+rp/J8Gdkqzlf8rl9vr8X+8MH0Q /2fE3fie/F/1WfxfKyP0Lfk/d03+L4L/e3/+r48FkzuB/wP/92BR4P/A/90SdaNX4P9+YHa/ Av9Xu7HZyv9N7zGKuhb/h/p/+08bl+r/ueiE/xOVcyv/54am+xkTwf8d0ivwf9v4P/f8+n/g /3C9xqX8n32kjHX8n5H6f+arAv/3+ItmOfi/9X5v8H/7e/Vc/k9TV4L/m5lWU/6PlKVn839O jq7A/90xLJ7N/yUH/m8n//cISAT830pR4P/6BvzfLf7PR/B/e0Vdj//joATwfytFgf872D4A /7fzBYL/2ykK/N9M1Lvxf3Jj8H+rRIH/e0v+r2o1Mhr83zvwf2FsNvN/YdqcyP+5+oL8n7G3 +D+NnAP/B/5vcoH/28n/NeFw/s+exv+RqM/h/5w5vP4fZzH/IP4vyhQ/g/+jEXos/0eFST+J /2Of6hn8nyUZh/J/VMZ4mf8zh/N/7ib/N9FuN/N/YdrQt3oy/1eTN+FQ/s/W/qP4P9X8wP+B /5tc4P9uvkDwf9KA/7tX1I1egf+7E8oD/3cg/xeDnL/UO0Rl96iGSnnX4v/6qoZP5P+c7IOH 8n/1s/m/zhS2B/N/qP8H/u+5/B/q/4H/w6WX8n/ukTLW8X9W+D/3VYH/e/xFsxz833q/N/i/ /b16Kv+nB3bg/77h/+rn83+2L0V4HP8Xwf+B/5Pfzhrwf+D/KnkD0wb8H/g/+e1Jg/p/4P/A /4H/W/kCwf/tFHUt/o/OQ8D/HSMK/N+x/F+UCKkj+T+bwP/tFQX+b6co8H9rRd3J/yn4cwb/ p4Hz4P9+PARtejr/Z/Tfwf+B/5tcD+D/CLM5h/8z9or8n47AanadWf9PT3muxP91Fg7q/30y /9e0H8X/1eJufE/+z74C/5fGZjP/l6bNTf5PjWzwf6/D/1W3+L8ou8cZ/J8+yhn8n2i/Z/B/ fRHZU/g/RQ3lTuD/1vN/ExZiM/+3yFOA/wP/d0vUjV6B/7sTygP/dyT/J56zGNrtorJ7XJX/ 63sF/u9Q/s82lvMWXa7+nxxGXo7/436A/5ub3a/H/5ERDP4P17Mv5f/8I2Ws4/+c8H/hqwL/ 9/iLZjn4v/V+b/B/+3sF/m+HWvFB/J+rD+f/qlv8nxiU4P/uiTBf5P9a8H87+b9HrIFn8X/W g/87oFfg/8D/lb0C/7dTFPi/taLKNwj+74AXCP5vp6hr8X9Va8H/HSQK/N/L83+uAf+3VxT4 v52ilvm/RtZx8H/38BSL/J/GGu/j/9Tb/A3/pxGI+/g//Vin83+1+yz+T/wU4P/A/02uE+v/ OflIR9b/q67I/51Y/+8H/J/82JX4P+fCNfk/eVBttvJ/pT8G/N/KFwj+D/zfwlkF+D/wf3d8 qw/i/0yt6iJrM1ep/6fDu0n6Dra5VF3WvAL/l8ZmM/+Xpg34vwr83zeibvQK/N+dUB74vwP5 v0bWWWk2isruMYq6Fv8Xa/B/h/Tq8fX/wP+B/wP/5+nI71D+j2xh8H+4Vl7K/4VHyljH/3nh /9JXBf7v8RfNcvB/6/3e4P/29+qp/F//kcD/zUyrKf9n/fP5PyuG7zn8n54Fgf/7VtQi/8dB CeD/7hL1dP6vkfiHA/k/Ok8C/7e7V+D/wP+VvQL/t1PUIv+XOELnSP6PArPA/60VBf7vYPsA /N/OF3gW/xcD+L+DRIH/A/+Xv0Hwf/tFfQz/J28L/N89PMUi/6dntxyqv5X/y5iy7odu1f+T /4n6f2/A/5kr8n/JHs3/keEI/m/Vt7qz/t81+b/WHM3/3ar/140RfmWNkiEbQ4uUDtcXdIv/ M/KCL8T/dYuEiZfk/7zqFiLqkfxfD/49nv/ziaCXQ/k/inn8IP6vbnnMXY3/Y6v+UP6vW9mf z//JfR/O/4W6rY/m/zjV3jL/JwvXGfxfPJH/E6LhFP5PFqZT+D/Z3U/h/zRAi7Xbx/J/PWoo d3oo/ydz9xT+Tyj8c/g/+fd9/N/kHlUF/q8C//eNqBu9Av93J5QH/u84/s8kPjTRZpuo/B6j qGfyfxobeCD/13jwf4f0KuP/qja5NpFRENRXt43/o6QB2lSvwf8p+Hc1/o8PQ8D/zc3ujP+j kjZP5v98Tf04lP8jUeD/cK28lP+Lj5Sxjv8LzP9F81WB/3v8RbMc/N96vzf4v/29Av+3Q60A /7dSFPi/g00r8H8zUeD/wP+B/7slCvwf+L/ZsHh2/b/G8YsD/3fHGwT/d8ALBP+3UxT4vx29 Av+3UxT4v5XdAv/XN+D/wP+B/6u+Ca900wb839vwf5SE+4P4vxgP5/8s+L99/N+t+n8K/l2M /zu+/t8t/q9q+b4mtTvOlSoNwpJAnlfg/yRG/4T6f8aE5mj+j6OYwP+tGxazA+8l/q+hkX0o /8erBfi/Vb16Fv9XVbf4P/7tQ/m/6hXq/53E/0VnD+f/eLCD/9v3rcD/VesMVPB/4P8q8H/T Tj1OFPg/8H83RGWdmprMV+H/rGFNzJrgNovK71GxQ/V6/B/q/+0/bVyo/1e3IXkyCnRCbeT/ OAAq6SsB/wf+77n83/Pr/3WKH+274P9wPftS/i89UsY6/i8K/+e+KvB/j79oloP/W+/3Bv+3 v1fP5f+k1+D/fsz/UTrE5/N/Gm17Bv8njlrwfxv5P05KDP7vLlHP5/847vBI/s9F8H8H9Ar8 3zvwfyGB/9srCvzfXBb4P/B/4P9uiroY/+ca8H8HiQL/dyz/F1p+UvB/q0SB/3tT/k/C88D/ 3cNTLPJ/esx+IP9XxRv8n0Yg7uP/9GNdmf8be/Vo/s/cqv9XaYwZ+D/wf5PrqvyfKvfH8X+T b5WJOpH/a+LR/J/z/gb/p71+T/4v+EX+r/Ve+D+/XTtrxYeozdCr+cc6kf+TB70W/xdqCqAD /7co6k7+j32qZ/B/XJQP/N/SC8z5P2Nv8H9Jd9Br8X99JpJr8X8Sw38K/yeg1yn8n5B0p/B/ ug+ewv/JKnQG/ycL3jn8n+yJp/B/aWw2839p2oD/q8D/fSPqRq/A/90J5YH/O47/o2B4ahob NovK70GOiefzf/J1juT/eqrxmfyfWjsH8n+Uu+2p/F83alryW4TWbhZlYtvWQ1OJi+TJ/J+U cu+brc7vetq8Av/Ht7ga/xf80fyfi/UF+T8q1AP+D9fKS/m/5pEy1vF/Sfi/8FWB/3v8RbMc /N96vzf4v/29Av+3Q634qPp/4P/ehv9L4P/A/4H/29cr8H/g/8pegf/bKQr831pR5RsE/3fA CwT/t1PUxfg/Y8D/HSQK/B/4v/wNgv/bLwr83/2DHfxfdSz/V1+R/wvpgvX/wP/t5f8a8H9v w//FW/xfemP+TwnUanaB/7s1Agv+rzFL/J/1dTya/+Ms5uD/1g2L2YH3Ev9naJcG/7co6i7+ T+YV+L8F18/r1f87jf+rHbkpUmxFn97I/0kh2lqNtOb5/F9rD+f/Ivi/9+f/+lgwuRP4P/B/ DxYF/g/83y1RN3oF/u/HZvez+b9aTlyM2b4G5ve4Kv+XLsn/TaC85/B/tlOwLbnVmnqzKBNb Uo21qcRFAv7vgF6B/9vG/5HV+Gz+j224Q/k/6hX4P1wrL+X/2kfKWMH/Wf7vnYHu7VcF/u/x F81y8H/r/d7g//b36rn8nx7ngv+bmVZT/s80L8D/NZof+QT+z0kVd/B/2/g/Xzvwf+/D/9HN D+X/jAX/d0CvwP+9A/8XG/B/e0VdkP+z4P/A/91+geD/doq6GP+H+n/g/34g6qn8Xzyc/6Mt H/zfPlHg/3aKWub/ergB/N9W/k8jqPfxfxpe6QpRJf+ngfO7+L+p/2gi6uH8X+2uyP81N/k/ 8VOA//uG/0P9v538X7TP5/+aZtIcwv/F1+H/NLJ3H//HDSXhvsH/aaECec9vxv8t1/+zqa2P 5v9ouQX/t+YFVnfyf8fX/+OF6ZP4P3E3viX/R2kMPor/k7f1eP6vG91H83882J9d/689nP9z t/g/zx/mHP5Phs0Z/J+REXgG/yfhtufwf7Lyg/8D/wf+D/xfMSzA/4H/m/eq5P8ca7/G84a/ kf/L7sEJ2i/I//UVvcD/Hcv/xdTt7saFpL66jfyfGxq24MH/HdIr8H9vy/9Z/kjGpt6pvEVU f2hdD9ot+D9cKy/h/9xDUbt1/J9h/s+5rwr83+MvmuXg/9b7vcH/7e8V+L8dasVZ/J99Pv/n PPg/8H/g/3asgeD/VooC/9c34P9u8X/egP/bKwr831wW+D/wf+D/booC/7ejV+D/dooC/7ey W+D/+gb8H/i/K/N/WYz+Vv5PtcleqWxu8H8aUuIFOdjI/8VpcyL/92n1/8D/3cP/uQj+7/3r /53I/7UcFmhbnfDb+D893BN7prnF//G3sl4AhI07vsanp0HUBfm/G/X/TPCo//e5/B/twuD/ 1vUK/N+h/J+xz+f/Dq//V4H/A/8nN6mnDfg/8H+ze1QV+L8K/N83om70CvzfnVAe+L8D+b+G NxFtNvJ/2T1GUdfi/9oI/u+QXhX8X11bx/yfqJwb+T9aObWZiAL/dzT/x+Df5fi/0NJa4aPb LspzkNfYPJv/6wxEZmKt2aNIG3FQaYP6f7g2XMr/mUfKWMf/WeH/wlcF/u/xF81y8H/r/d7g //b36rn83yNCicH/rezVXfyf1TP1M/g/ccGD/7snwnyR/2vB/70L/6dxh0fyf3SeBP5vd6/A /70D/4f6f+D/+Ldy/q8B/wf+7/YLBP+3U9TF+L8YwP8dJAr8H/i//A2C/9sv6lP4P4kSA/93 j9L5dP4vmLHZzP9N1fZJrx7O/7n6ivzf7fp/MtzA//2Y/0P9v738X3LL/J+Tj3Qk/1eB/9vH /9mb/J905z35P1pu5/xfp14ez/+h/t/78H+N+Sj+T/iaM/g/SwvsofxfVd3g/7zcAvzfPRrT SfxfvMn/qbXzlvxfdZP/E+XsDP4vncj/ydp6Bv+n++Ap/J8fmwfzf+w+OIf/kyos4P8q8H/T Tj1OFPg/8H83RGWdmprMV+H/rBHdQpptovJ7jKLA/70+/0fOhKfyf3UTrCFnbbCbRZnY+npo aCTGp/N/VkCwq/F/kSt9Xoz/863wf+KN2cr/2ay5Iv9Hgfrg/3CtvJT/s4+UsY7/c8L/pa8K /N/jL5rl4P/W+73B/+3vFfi/HWrFJ/F/ohOC/7tjWID/W9mrT+b/nMQ/gP8D/5dd2Y+B/wP/ t/Bj4P/A/8kF/g/8H/g/8H+lKPB/M1Hvxv+J1gL+b5Uo8H/g/wZr+LP4P3mDp/B/ahqA//vx EAT/B/6PHwr8H/i/pdXig/m/miv+Pp7/67qcrPB/O+Ch1vBjaPNp/F+lgcrg/96A/zuv/h/4 v5u78Efzf0Hd+Rfj/8SYOoX/k0c5hf+TLlys/l+tmqnc6aH8nwzvc/g/GYHg/8D/TTv1OFHg /8D/3RCVdWpqMl+G/5PgBG028n/ZPUZRz+T/NDYQ/N+L83+d9kcbuXEutHarKBMjacjaVK/B /4nRczX+z8uWey3+z4Yr8n8tOX4O5f9IFPg/XCsv5f/cI2Ws4/8883/efFXg/x5/0SwH/7fe 7w3+b3+vwP/tUCs+if+TE+5T+D85LgH/d0+E+RL/xxQZ+L+7RD2d/+PoOfB/95xRgP/bLwr8 H/i/2bAA/zeTBf4P/B/4v5uinsr/8dAD/3ePKPB/M1Hvxv9JIBv4v1WiwP+9Kf8nbwv83z08 xTL/pweSJ/B/GgN7Nf5PXuDF+D8Jxgb/tzDYwf+dwv+J8+AU/k9zFYL/ewP+j+PCT+D/ommk /p/ZEXHWyragzWvwfzIeTuH/orwt8H/vwP9xIQLwf3PXz538X68E72FfpvegB3o+/xfb8+r/ xUlzHf5PiIZT+D9ZmM7g/5SUO4X/k33wFP5P3tYZ/J/M3VP4Pw00A/8H/m/aqceJAv8H/u+G qKxTU5P5Mvxfy54z2/L5zkb+L7sH/dDz+T/Ryi7G/9mWt07n4g5ROlO1Me7J/F9o69p1X6A1 onJu4/8MGcHaVC/C/0mU78X4Pzb1Lsb/2WQuyP8FC/4P1ytcyv/5R8pYx/8F4f/cVwX+7/EX zXLwf+v93uD/9vcK/N8OteKT+D/xbIL/u2NYgP9b2atP5v8iWeTg/+45owD/t1/Uc/k/OTwF /3ePqA/i/yi9FPi/+94g+L8DXiD4v52insr/sSoE/u8eUeD/ZqLejv/jG4P/WyUK/B/4v8Ea /iz+T+57Mf7P8SDYyf/p437D/1l5gWfwf/KCwf/dE82+yP+JvQP+b2Gw38n/8bc8hf9jR+fl +D/esM7h/3jMXY7/Yy/qCfxfsKTLGhe9366dtRL/qQ34vw3LLfg/8H8LUxj8H/i/pa3xLv6v DeD/wP+B/1shCvzfI0SB/wP/d0vUjV6B//uB2f18/s85cQxLs01Ufo9R1DP5P9F+d/J/Mm5f iP8TuOhS/J9v6051Nta1cbMoE9jtpk0F/g/83yr+r75i/b9OR3IV+D9cT7+U/wuPlLGO/4vC /4WvCvzf4y+a5eD/1vu9wf/t7xX4vx1qxSL/ZxJnijmQ/3PWP5//k1O0c/g/FgX+754I80X+ jzzd4P/uEvV0/o/PrMD/3XNGAf5vv6jn8n8SpQj+7x5RH8T/ccgt+L+73iD4vwNeIPi/naKe yf+FcHj9P2vA/x0kCvzfwfyfMC/g/1aJAv/3pvyfnpuC/9vI/1Vy8lxJRYyt/J+bNvYW/6cH pxxpu5n/C9PmJv9nxCUoe/1O/k+G2C3+r0dQD+T/KIZkif+z8k4O5P+6+XOL/5MuXIz/k4Aq 8H8Lg/0+/k9EncL/SR/9Dqf0aHuWvSrWpagxJsfxf+4W/8cL0zn8H2u0R/J/Lr4A/8f3PYH/ 86Ftif8LyW1fbtua3742r8H/uZ5Q5f/xUP5P1shT+D9auMD/LYq6i/+ruRTGOfwfyTiH/3Mc fn0o/xdv8n/y7/v4v8k9qpfg/9yJ/J9Gi57A//GSfij/F2/yfzL0TuH/5AWewv/JCDyB/6ta Heys3T6Y/5PhdgL/F4R2OYf/k7d1Cv8n/76P/5vco6rA/1Xg/74RdaNX4P/uhPLA/x3I/wXe ZLTZyP9l9xhFPZX/E8PqYvxfFKbsUvyfjXXb7fBNI+bBJv7PN/S9talehP+T5HdX4//4MORa /J9xZFhdjv9L5MQD/4fr2Zfyf/GRMtbxf0n4v/RVgf97/EWzHPzfer83+L/9vQL/t0Ot+CD+ z0lecfB/dwyLZ/N/llREbTaKolLxY8OiwP+tFLW0Wsz5P/aLg/+754wC/N9+UeD/wP/NhsX1 +D8L/g/83+0XCP5vp6jn8n/07+D/7hEF/m8mCvwf+D/wf8uiwP/t7Rb4v/nHOoD/k/PVI/m/ 2t3i/zSqRboD/g/83/h1rsf/iRV3IP/n4y3+rw/8GPu4nv8zeq+iV8W69Nb8n/0s/o+/5Rn8 n6EFzzjf2u3LbdPyTNEG/N+G5Rb830n8H++74P/mrh/wf+D/ljQm8H/g/xamMPg/8H/3igL/ B/7vlqgbvQL/9wOz+wX4v9imsdnI/2X3GEWB/zua/xPP2U7+r/ekcvN0/s8lisE0xqk7axv/ Z5o4NBX4P/B/a/i/Opkr8n9NBP+H6wUu5f/SI2Ws4v9MLfyf/arA/z3+olkO/m+93xv83/5e gf/boVZ8EP+n6vo5/B/fF/zfPRHmi/wfnVFos1GUiXwYpQ2LAv+3UtTSajHn/zh2CfzfPWcU 4P/2i3oy/8f/fiT/Fyz4v72ins7/yQEt+L973iD4vwNeIPi/naKeyv/x7gT+7x5R4P9mot6N /5PxDf5vlSjwf2/K/0l4Hvi/e3iKRf5Pw6f28X+K2UgkxG3+TwPnd/F/U//RpFf5Ya1pBFi5 Gv+nKuBx/J+9xf9F+TDX4v+CBFQdyP8REvVR/J8YjGfwfxLGvpP/U3XhG/5PFqZT+D8O/PC1 rrr7+D8Ji7zF/6XIkINTL9Y+/q+PvbrB/2lA1Rn8H+eVPJT/o+V2zv+55Izr/q1bkPbwfyaM zWvwf/Kgp/B/9jz+j5Zj8H+Lou7i/4R9OYX/40jvk/g/1lkO5f/cTf6vHpvN/F89bSr3dP6v pvDLY/k/d5P/i5PmofxfExJ/iAP5v+oW/+f4w5zC/6m5eAb/JyTdOfyfiDqD/+tjweROD+X/ ZDycw//JnngK/5fGZjP/l6YN+L8K/N83om70CvzfnVAe+L8D+b8U2rHZyP9l92An3dP5P1FJ ZU/czP/Vk6ZThZ7P/3lx4slDb+X/zLSp4rP5P0d1yjqb2zq7VZRxgewJbSrwfw/k/3iUX4z/ qynY7nL8X0sGLPg/XM++lP9rHiljHf9nhf8LXxX4v8dfNMvB/633e4P/298r8H871Iqn839W zOtT+D/+bfB/dwyLp/N/dIahzUZRJjJIoQ2LAv+3UtTSarHA//GYO5L/Mxb83wG9Av/3Dvxf 3YL/2yvqevwfhXGC/1srCvzfwfYB+L+dL3CZ/+NDq0P5vymUB/4P/F8hCvzfno8F/m+/KPB/ 9w928H8V+L9vj9WtXeb/jGwcR/J/Y68K/i+pCngc/zeScuD/wP89gf+rWrvM/3n3zvyf8Wfx fzoCq9l1PP9n/fP5P1NL/rsD+T8SNef/YvCB+T+bdvB/DevD2gy9mn+sa/J/zXn8X2uO5v9s Av+3sld31v8L5/F/7eH8X3WT/3Njs5n/c9OGvtWT+T8upH0s/1c9n/9rzeH83836fy34P/B/ M/5PK5GD/1vgKcD/cQP+715RN3oF/u9OKA/834H8X5QAreS3r4H5Pbp/fgH+T7TfI/k/Y5/O /7laIkeP5P/qJ/N/0aZuI+/MudpvFmUcx4JqMxEF/g/830KvciexaZua+T/nd5xf5REX5OV8 Mv/XTajD+b8I/g/X6kv5v/aRMtbxf074v/RVgf97/EWzHPzfer83+L/9vQL/t0OtWOT/avZC H8n/mdjc4P/cefX/xNd6Dv8njlrwfxv5P8fluqXZKMpEa8aGRYH/WylqabWY83+8WhzL/0Xw fwf0Cvwf+L+yV+D/doo6i/+rwf+B/7v9AsH/7RT1TP4vcpwn+L97RIH/m4l6N/7P89AG/7dK FPg/8H+DS/Wj+D9RAaWK3Vb+T53nI6d0g/+LY7OX/xuM/LP4P99ekf+LN/k/GW7g/77h/2rw fw/i/yT2we8KgSjqKd3k/+Ss4kD+rzqt/t+n8X8MJh/K/9m0xP+1Lgr/V9d7+L+Yxmbo1fxj ncj/aVGJa/F/hvbEY/m/4D+L/+OsDGfwf3zzY/m/CP7vIfyfj/Fo/o/q1d7g/9ToAf/37bcC /1et0m5fkP/j+57D/wlTcwr/J/vZPv5vco+qAv9Xgf/7RtSNXoH/uxPKA/93IP/neP1ynr1l G/m/7B7kmHg+/ycq55H8X98r8H+H8n9tHRzxf8HIMrGN/2NjXZsK9f8ex/+x3XY1/i82R/N/ ZDU+nf8zR/N/NoH/w7X6Ev7PPxS1W8f/eeH/6q8K/N/jL5rl4P/W+73B/+3vFfi/HWrFSfwf mVbL/J9/xLxa5P8UJgP/d8eweDr/R7+tzUZRnSHjx4ZFgf9bKWpptVjg/zju8Ej+zzbg/w7o Ffi/d+D/XAT/t1fUBfk/1P8D/wf+rxB1Ff5P4nvA/90hCvzfTNS78X+iSoD/WyUK/N+b8n9i ToH/u4enWOT/9NT4DP7Ph7HZzP+FaXMi/5fiafyfMc/n/zQaC/zfN/wf6v/t4/+65pP4v9Ye zf/55gb/13AEtYkK4m0MLZLHD3KP5hb/pwdzZ/B/PAIP5f8as8j/tcER/2fTjhHYNPzL2kgU E/i/dcNiduC9yP/Rkn4s/0dT+HP4v7rlMXcx/s8H8H97+L9z6/+pSnox/k8OZ0/h/+QjncH/ qfJ2Cv8n++Ap/J+ihnKnR/J/IfELPIX/c0KgnsL/qUa1i/+b3KOqwP9V4P++EXWjV+D/7oTy wP8dyP/VvG1os5H/y+7xEvyfelKd6Job+T+djTphE+r/PYT/i6EzD0wddOht5P/IvakNW/DP 5//UpQ/+7yP5v+bp/F9o2qP5P+oV+D9cKy/l/8wjZazj/4Lwf/arAv/3+ItmOfi/9X5v8H/7 ewX+b4dascj/SVzFofyfilqo/yeRAmfwfwn837vwf74OQ7NRVGfIpLFhUeD/VopaWi3O4P+C Bf93QK/A/4H/K3sF/m+nKPB/a0WVbxD83wEvEPzfTlEX4/9sAv93kCjwf+D/8jcI/m+/KPB/ 9w928H9VBf7vu2P1m/yfEg0H8n9UkGqJ/3NOVcDD+L/uJ8H/rewV+L9z+D8pB6TNVv7PTJtb /J/26pT6fwysdKuEusG38X9T1wUxZSfxfy5+Ev8XjWH+zzfbtbOm4X1JG4li+hz+rwf/TuD/ eBKB/1sU9XL8Xzqc/6vO4//iTf4vjM1m/i9MG2MvyP+Z2/X/ZF6B/wP/B/4P/B/4P/B/4P8e LQr837H8n21aWo5t6+1mUfk9wP9VD+P/tFcH8n/ku30u/+dcp7yZ2rd8QrGV/zNuaPgnwf8d 0qsP4f/s4fzf8+v/hZTA/+F6gUv5P/tIGev4vyj8n/+qwP89/qJZDv5vvd8b/N/+XoH/26FW nMT/0TntMv8n7+QU/k+8+eD/7hgWT+f/SM3UZqMoEzk2SRsWBf5vpail1WKB/5P4B/B/4P+y K/sx8H+3+L+6Bf+3VxT4v7ks8H/g/8D/3RQF/m9Hr8D/7RQF/m9lt8D/9Q34P/B/n8D/RXpr e/k/V4gq+T/5n2/J/3XWxmn839irJ/J/mi4H/F8pCvzfOfyfrA976KvR9ix7VaxL78z/6Qis Ztfx/J+/Wf9Pe30h/s+YUCfh/9z25bZpeHHThpfbp/N/SomA//uG/+tsfPB/63r1NP7vxPp/ t/m/ODab+b84baor1v+z/ib/FyfNu/F/1Q3+TyOoT+H/krzAM/g/tQVO4P/6iNlT+D8/No/l /6IMm1P4PxF1Dv/XjM1m/q+ZNuD/KvB/34i60Svwf3dCeeD/DuT/Em/43dDbwf9l9yB18Ir8 X081gv87kv8zxsZuJhkTWlEHN/F/3pOnVJvuZ0wE/3dIr2b8nxyGXIr/IyjoaP6PzO5n839B 6v/Ve1ARU5tJA/4P14ZL+T/3SBnr+L8k/F/8qsD/Pf6iWQ7+b73fG/zf/l6B/9uhVpzF/9WX 5P/iLf5PLAXwf/dEmC/yf20Ymo2iTORTUW1YFPi/laKWVgvwfzvOKMD/7RcF/g/832xYXI// q8H/gf+7/QLB/+0UdTH+L3jwfweJAv8H/i9/g+D/9osC/3f/YAf/V4H/+/ZY/cT6f+D/3of/ q8H/vQ3/F6/I/92u/2eP5v9osH8M/2eDc4fzf69Q/++S/J8jYwD1/xZFXZ//IzUG/N+qXj2N /2NX+wfxf0mMqYvxfw+JTwX/t+4F3sf/GQP+D/wf+L/dwwL8H/i/ea9K/k+OGa1L29fA/B7g /yrwf/fzf9aRXdA13m8WZYInV7M2Ffg/8H9r+D8T6yvyfxb8H65XuJT/84+UsYr/s7Xwf+ar Av/3+ItmOfi/9X5v8H/7ewX+b4dacRL/Ryn2lvk/HQ9n8H9ycnxK/T/wf/v4vxDC0GwUZaJL Y8OiwP+tFLW0Wizwf+x5PpL/SxH83wG9Av/3Dvyfi+D/9oq6IP+H+n/g/8D/FaLA/4H/W/gx 8H8vzf9JVCD4v1WiwP+9Kf+nkdHg/7byf16V6BP4P41AfE/+z7en8X8UQ3IS/9fc4v80IAH8 H/i/yfXe/F/1ifxf6LfIXfwfNy7e5P/UnSBryzX4v1Sbo/k//wr8n+7CF+P/aL6i/t+iqDv5 P949rsb/2cP5P3eT/5voBZv5v6luUT2f/0t1PJr/48G+yP8F0QMvxv+JfXUK/ycpl8+p/ycj 8BT+T7pwBv/Xi5I7PZT/k2X8HP5PPtIZ/F86gP+b3qOqwP9V4P++EXWjV+D/7oTywP8dyP8Z Ng+02cj/ZfegH3o+/ye/vZP/k+1VJ2wbn8//aWDRgfyfcc/m/3zqftvYqJ9sG/+XyIGuTfUi /F/vcN0h6vX4Pytb7rX4v/Z4/m/c8J9X/49PnbvO7RBl5Je1IVHg/3CtvJT/C4+UsY7/M8L/ ua8K/N/jL5rl4P/W+73B/+3vFfi/HWrFSfwfRXU8m//zBvzf2/B/TRiajaJMdO3YsCjwfytF La0WZ/B/qP8H/u+mKPB/4P9mwwL830wW+D/wf+D/booC/7ejV+D/dor6KP5PwlfB/60SBf4P /N9n8n+xHZut/F/GlHG4ynL9v2ZsNvN/cdqcyP99WP0/8H/38X8R/N/b8H+vU//PtXv2xoyB JqZskf9rmUywTr1Y23Z8CdnTykIk6nr8n6mb5fp/8fD6f+D/3oj/62x88H/revXR/J+eXXGz NcR8eg9WpK/H/9G3Av+381uB/6vWGagvx/+1l+T/UP8P/B/4P/B/N0VlnZqazJfh/ywfJGmz kf/L7jGKuhb/13jwf4f0qqz/RwfdxiYvrrtt/F9LRq42Ffg/8H9r+D8bDuf/KMvZk/k/3x7O /6H+H64Nl/J/8ZEy1vF/Vvi/8FWB/3v8RbMc/N96vzf4v/29Av+3Q604i/+zt/g/iY06pf6f 02jbE/g/L8E+4P828n/RhKHZKMpEb8aGRYH/WylqabVY4P/o3w/l/6IH/3dAr8D/vQP/V7fg //aKAv83lwX+D/wf+L+bosD/7egV+L+dosD/rewW+L++Af/32vyfdgf832b+T6IHD+T/RlHg /16d/4v+Fv8nfgrwf+D/Jtfx/F/VWvB/K0Vl/J+OwGp2Na3wf1Ze2kb+T75JGkTd4P/kid6S /7tV/8/49pL8n5Z0BP/3Y/6PsNBP4v/0QOkt+b8qnsf/xZv8nxubzfyfmzafxv+pO/9a/J8o 2ufwf9LrU/g/WVvP4P90HzyF/5MunMH/CQtxCv8nCuA5/J88yj7+b3KPqgL/V4H/+0bUjV6B /7sTygP/dxz/Z6JhRVoW+G2i8nuQ2XhF/i9Z8H+H9Crn/0ybYiCvtJGkTdv4v4Y8pdpU4P8e x//pTL8W/+f9Ffm/kMD/4XqBS/m/9EgZ6/g/J/xf+qrA/z3+olkO/m+93xv83/5egf/boVac xP/1oub8nz2t/p9rwf+9Df/nw9BsFGUin1lpw6LA/60UtbRanMH/pQj+74Begf97B/4vOvB/ e0WB/5vLAv8H/g/8301RF+P/bAL/d5Ao8H8H83+yv4P/WyUK/N978n8aXgH+7x6eAvzfqnHx NP6v0y7O4v9q8H/g//jnn8T/XbT+Xzyv/p89jf/z9oP4P5PsNev/ncj/6Y6hzUb+rxQF/m/l C7yL/zM8st+U/zMn1v87kf+jb3U5/o9e4DL/15/fn8D/JfB/4P/A/60QBf7vEaLA/4H/uyXq Rq/A//3A7H4+/9cpv2xR1fV2/i+/B2tMF+T/2nhF/m8C5T2J/4s+GfJK60fayP9Rd7SZiAL/ B/5voVcl/+eao/k/F+tn83+uCeD/cL3Apfxf80gZ6/g/z/xfMF8V+L/HXzTLwf+t93uD/9vf K/B/O9SKZf6vPZH/E/P6DP5P1PVz+D/NTgv+71tRy/xfCkOzUZQReFAbFgX+b6WopdVizv+x 9wT83z1nFOD/9ou6Gv9na/B/e0WB/5vLAv8H/g/8301RF+P/UP8P/N8PRIH/2/OxwP/tFwX+ 7/7BDv6vOon/E03wYvyf3PxN+b+b9f/iFN0A/wf+T14v+L/7+L/qBfg/d2L9P3mh78n/dcbc Uv0/V4dL8n/yoOD/SlEF/0fD4qP4P8fNPv5PJhT4P9T/mxwN31v/75L8XyW65in8nxZQPIP/ 02X8DP6vh/JYu30w/6exYCfwfzLFwf8t8BSTe1QV+L8K/N83om70CvzfnVAe+L8D+b8kdkFq zXZR2T2ql6j/J8dj4oHczP+FSXPR+n/ku30q/2ctfSTi/6Q7G/k/MjG0qV6i/l8/Aq/G/3E/ wP99E3HxAvX/XET9P1yvcCn/1z5Sxjr+Lwj/574q8H+Pv2iWg/9b7/cG/7e/V+D/dqgVJ/F/ dE57Qf4vgv97DP+X6jA0G0VR1pmxYVHg/1aKWlotzuD/mgb83wG9Av8H/q/sFfi/naLA/60V Vb5B8H8HvEDwfztFXYz/awz4v4NEgf8D/5e/QfB/+0WB/7t/sIP/q8D/fXusfiL/N/bq4fzf zfp/4P/A/4H/A/835f9+UP9PXuh78n/L9f9sPL7+X9+r+ccC//dq/B/FPIL/W9erp/F/zXn8 X4X6f+D/+F2A/wP/t6Bygv8D/3evKPB/4P9uibrRK/B/Pza7n87/yTK+j/+b3gP8XwX+bwX/ F+vOCCb+T8yDrfxfGpqJKPB/4P8WevUZ9f/A/+F6iUv4v/BQ1G4d/xeZ/+t+vAL/9/iLZjn4 v/V+b/B/+3sF/m+HWnEW/1ff4v/klZ3C//Wn08fxf9VN/o89huD/7okwX+T/XBiajaJM9O3Y sCjwfytFLa0WC/wfBxSB/7vjjAL8335RV+P/fAL/t1cU+L+5LPB/4P/A/90UdTH+D/X/wP/9 QNRT+b/AQxv83ypR4P/ek//T4Qb+7x6eYpH/CyrjBP5P9XWOtN3M/03Zl4moK/F/J9b/u83/ yXAD/wf+b3I9gP+rHfi/laJQ/+8M/q9F/b/7/THX4/9M3XwW/8f7ru4sO/m/YRcG/zd/gR9e /48H+yL/pyTdxfg/kXEO/6eB9Wfwf7K2nsL/yT54Bv/Xx4LJnR7K/yWer6fwf7UwNWfwf9Ir abaugdN7VBX4vwr83zeibvQK/N+dUB74vyP5Pw3JYsptK/83vcco6lr8X0/0gP87lv9rrGnI fRHUO7eF/4uGxq021UvU/7Pic7wa/8cGKvi/byMuxg3/afxfIIPgUP6v28nB/+Faeyn/Zx4p Yx3/l4T/i18V+L/HXzTLwf+t93uD/9vfK/B/O9SKk/g/68H/gf9bFLXM/8UwNBtFdUa9GRsW Bf5vpail1QL8344zCvB/+0Vdjf9D/T/wf/xbGf9HQXTg/9aKAv93sH0A/m/nC0T9v52iwP/N RIH/A/8H/m9ZFPi/vd0C/zfrFfg/8H+rlc5ZNDv4v1VT+BP4vwr83z7+r/4k/q9uDq//Rwdz 4P/WvMAFUYv8H2sTx/J/0YL/W9kr8H/g/+ZHwwX/F8H/gf/jH62nDfg/8H+ze1QV+L8K/N83 om70CvzfnVAe+L8j+T/ZOlPcISq7R3XR+n/g//afNi7xf7XxbbdR1XFH/b/o6D9rU4H/A/+3 iv8L8XD+7wXq/4H/w/USl/J/9pEyVvF/rhb+z3xV4P8ef9EsB/+33u8N/m9/r8D/7VArns7/ ybA4hf+r2SsJ/u+OYfFs/o+Px7TZKKoz6v3YsCjwfytFLa0WC/wf9Qr83z1nFOD/9osC/wf+ bzYsLsf/of7fll6B/zvYPgD/t/MFnsX/2QT+7yBR4P8O5v8kkA383ypR4P/A/w2ei4/i/ySC +hz+T0Tt4/80PvXK/F/wp/F/vrnB/wXwf+D/nsr/iQxttvJ/btrcrP8nr/Oa/J+VlXEn/6e0 zRX5Pyr0tsT/mdSi/t8+/k/X1rfk/2gXBv+3rlfg/67G/xl7OP9X3eT/1BK5Fv8X5XD2FP5P XuAp/J904QT+rxIF8Bz+T1aTM/g/GTZn8H9VC/4P/B/4v93DAvwf+L95r+b1/yT/4i7+b3qP kX25Fv/XU41P5P+sfJ0j+T/jns3/mbpTOY2r9T9v5P9IB9KmAv8H/u/J/B/F7YH/W9cr8H8X vZT/c4+UsY7/M8L/ua8K/N/jL5rl4P/W+73B/+3vFfi/HWrFSfwfHYc8nf+L7JU8hf8Taxn8 3z0R5ov8Hxkh2mwUZcShrQ2LAv+3UtTSagH+b8cZBfi//aLA/4H/mw2L6/F/Nfg/8H+3XyD4 v52iLsb/BQ/+7yBR4P/A/+VvEPzfflHg/+4f7B/O/7VjA/7v9rG6by9Y/498Pzfq/03RDfB/ N/m/GvzfLv6PuFrwf+tEZfyfEqjV7AL/d2sE3sf/BXc4/0erBfi/NS9wQdQi/+fIGDi2/l83 LMD/resV+L9D+T/rwf8tvMDd/J+VkwPwf/e8wI/i//zYgP/7sW4B/g/83w1R4P/A/90QlXVq ajJfh/8T5S3xqruV/5veYxR1Lf7vBer/PYD/m0B5T+L/fOo0aONqL27BjfxfnYamAv8H/g/8 H/g/XK9xKf/nHyljHf9nhf8LXxX4v8dfNMvB/633e4P/298r8H871Iqz+D97k/+TSIET+D8r tiv4vzuGxdP5vxCGZqOozqhPY8OiwP+tFLW0WizwfxL/AP4P/F92ZT8G/g/838KPgf+7xf+h /h/4P/B/hSjwf+D/Fn4M/B/4v6Vugf8D/7fwY4/l//TcFPzfVv4vHMH/aXilK0Qt838cP7+X /yt79bz6f27qungz/u92/T8NrAf/9w3/h/p/O+v/ufo0/q+6Iv+H+n8P4v+cN0fzf32v5h/r RP5PT2jA/33D/0X7UfwfPyj4vwXXz0fzf83h/F+8xf95XZiuxf+pcnYG/+eVnDqB/zMyAk/g /0wtY+AM/q/WeSV3eij/J8v4KfyfEqin8H/qN9zF/03uUVXg/yrwf9+IutEr8H93Qnng/w7k /6LW7uO9ZKOo7B7VUCnvWvzfC9T/c+IFvRb/53zL9f+8fKSt/F8cmko80k/n/8Tiuxr/J1su +L9P5P+8B/+Ha/Wl/F94pIx1/J8T/i99VeD/Hn/RLAf/t97vDf5vf6/A/+1QK07i/8jF/mz+ zwXwf+/C/7FGq81GUSZK9EmMgyjwfytFLa0WZ/B/bQT/d0CvwP+B/yt7Bf5vp6iT+D8KogP/ t1YU+L+D7QPwfztf4Fn8n03g/w4SBf4P/F/+BsH/7RcF/u/+wQ7+rwL/9+2xOvg/8H/yFab8 n9JX4P8283+1Q/2/laJy/q8B/7dytbiP//N1Opr/4ygm8H/rhgXq/4H/m0/hT+D/6Fs9l/+L 9vD6f7Rfgf/b+a3A/1WbDNTX4f/aS/J/UxZi6xq4zFOA/wP/d0vUjV6B/7sTygP/dyD/Fxpe biNPqI2isntclf9LFvzfIb0q+b/GGub/nN0qisA/PzTVi9T/A//3wfxfc0n+r+sV+D9cKy/l /+IjZazj/wLzf8F+VeD/Hn/RLAf/t97vDf5vf6/A/+1QK07i/9xN/s+KeX0G/+c02vYM/s9I r8H/fStqmf8jq16bjaJM5JM4bVgU+L+VopZWizn/x/F6x9b/8+D/DugV+L/D+T9Xiw/gQP4v WvB/e0U9nf9LMhCO4//IvQT+b60o8H8H2wfg/3a+QNT/2ykK/N9MFPg/8H/g/5ZFPZ//k/A8 8H/38BSL/F8fmLqH/5No0O/5Pzc2j+X/rIRGH8n/NeaC/F9lb/J/Wp3tUvxfDEfzf6YB/3cB /k+V++P4v3ga/+fqZf7POPa+2FpwgK38n+4OfI/P4v+IUDqa/2tegP/TDI3X4v8MLbDH8n8u fBb/14wN+L+p6+dz+b9geUKl0Copt43/M25sPo//E2PqDP4vKax/Bv8n970Y/9fHgsmdHsr/ iUZ1Of4vjc1m/i9NG/B/Ffi/b0Td6BX4vzuhPPB/x/F/pmaHhTbbROX3GEVdi/9rI/i/Q3pV 8H913a16xP/Vm0UR+FcPTQX+D/zfKv4vNpfk//iA+0j+j9zE4P9wrbyU/0uPlLGO/4vC//mv Cvzf4y+a5eD/1vu9wf/t7xX4vx1qxSfxf5qd9kD+L4L/exD/R7+tzUZRJvJr14ZFgf9bKWpp tVjg/3jMgf+744wC/N9+Uc+t/ydukZ38n8hQ/q9pwf/tFXU9/g/1/7b0CvzfwfYB+L+dLxD8 305R4P9mosD/gf8D/7csCvzf3m49n/+T6EHwfz8+VmdK5Hr8XwP+bxf/h/p/e/k/V1+R/6vO q/9nb9X/a4X/83L7jfyfvrnYi7oe/8dk9wL/F5rD6/958H/g//QrZA34P/B/5T3oh67I/9lL 8n/xs/g/WQNP4f90HzyF/0tjs5n/a6fNTf5Ppjj4vwWeAvwfN+D/7hV1o1fg/+6E8sD/Hcf/ kXrLTRO3i8ruQVruFfk/1P/bf9q4xP/5GJj/c8FuFWWiJRtOm+o1+L+mT3e1QxT4v6F5L/6P spxdj/9z4P9wrb+U/2seKWMd/5eE/4tfFfi/x180y8H/rfd7g//b3yvwfzvUirP4v/r5/J+N Gh9xHP9X3eL/vGanBf/3rahl/o88z9psFGUiv31tWBT4v5WillaLBf6PfvtQ/q+N4P8O6BX4 v4fxf2ot7+P/ZHEzEfzfXlHX4//IEQP+b60o8H8H2wfg/3a+wLP4P5vA/x0kCvwf+L/8DYL/ 2y/qY/g/MafA/93DUyzyf6pEywvayv/pG2wKURfi/65Z/8/4m/yf/Dv4vx/zfy6C/3tQ/b94 OP/Xgv8D/1eV/N+t+n8pHl7/D/zf+/B/PIXB/63q1X38H3+dQ/m/bme7Iv9XXbH+H7vawf/t +1bg/6pV2i34P/B/9KPg/5Z6Bf4P/B/4v6P4v5qX48Sq0lb+b3qPq/J/DvX/HsL/pbpOB/N/ 47AA/wf+b94r8H/b+D9yqIL/w7XyUv6vfaSMVfyfr4X/M18V+L/HXzTLwf+t93uD/9vfK/B/ O9SKk/g/62/xf+KCP4X/SxptC/7v22HxZP4v1HQLbTaKMlFwhRgHRwz4v5WillaLBf6PA4rA /91xRgH+b7+oi/F/qP8H/m+B/0P9vy29Av93sH0A/m/nCzyL/2sM+L+DRIH/A/+Xv0Hwf/tF gf+7f7CD/xteEPi/m8fqrb0g/3e7/l+S4Qb+78f8H+r/vRH/h/p/4P+q6l7+r4nt0fwfsS+f xP/pjnEG/0e6x6H8H2WK+yT+r+ZX9qb8X3NJ/u/59f+MtUfzf8RAL/N/+i3fk/+rbvF/Epxw Cv/XF9Y5gf/TZfwM/q+W+16M/xPt9xT+T/oB/q8C/zft1ONEgf8D/3dDVNapqcl8Gf4vCm6d WDnbKCq7B6lMV+T/Yg3+75BeFfxfQ7t7t1FF6c42/s9T2gptqteo/ydGz9X4P57i4P++jbiI Nfi/lb0C/3fRS/i/+FDUbh3/Z5j/8/arAv/3+ItmOfi/9X5v8H/7ewX+b4dacRL/Z5oX4P+C nk6fwf9JZhDwf1v5P1IztdkoqrNg6rFhUeD/VopaWi3m/B8fJIH/u+eMAvzfflHg/8D/zYYF +L+ZLPB/4P/A/90UBf5vR6/A/+0U9VH8n0Q1g/9bJQr831vyf0a9t+D/7uEpFvk/Pzk83sz/ KZDyHf83CY3czP+5aQP+byf/F+tb9f+kV+D/wP9Nrgfwf64G/7dSVMb/aQXKanY1PF9NKyFc O/k/iZOrP4n/C+R2NM6qJr2R/+PH1ebj6v+9M/9HNv4H8X81r7Pg/xZcPx9c/+8B/N/t+n+9 tfOW/N/N+n+qrJ/B/+kIPYX/kw9zCv8n++Ap/J8seCfwf6pBn8L/ySg/h//TCbWL/5vco6rA /1Xg/74RdaNX4P/uhPLA/x3I/yXxmEiztf7f9B6jqGvxf8mC/zukVwX/1xkqlvMWiVtwG/8X yFOqTcVRU+D/jujVnP+TLfda/F/yV+T/PP02+D9cz76U/zOPlLGO/7PC//mvCvzf4y+a5eD/ 1vu9wf/t7xX4vx1qxVn8n73F/0ls1Cn8X9T4CPB/3w6Lp/N/NAK12Siqs2Dc2LAo8H8rRS2t Fgv8n8Q/HMj/JQv+74Begf87nP9ztfgADuT/XAD/t1fU9fg/DkoA/7dSFPi/g+0D8H87XyD4 v52iwP/NRL0b/ydnmuD/VokC/wf+b3Cpgv+jP96Z/1Pw70D+jwzHs/i/4MH/rXyBz+L/CIn6 IP4vSFTukfxftOD/Voq6q/6fkXOlI/m/j6r/V/vWC/8X99T/C2ZsPo7/s/3Wyc178X80LD6K /+N9F/zf3PXzufyfT7Y+mv/7Qf2/N+b/KOTiBv8nK9Ip/J8Mm1P4P1kjT+D/qlYHO2u34P9e m/9LY4P6f3dCeeD/wP8tiLrRK/B/Pza7n8z/dYaIuDd5ud0mKr9H9Qr1/6z4Rnbyf/IL4P8e yf91um1n9BhnrapK2/g/ckppU6H+H/i/VfxfUx/O/3n/dP7v+Pp/JAr8H66Vl/J/9pEy1vF/ Tvi/+FWB/3v8RbMc/N96vzf4v/29Av+3Q604if+jg+5n83+u1iPjE/g/PcoE/7eR/+MjOG02 iuosmDg2LAr830pRS6sF+L8dZxTg//aLQv0/8H+zYXE5/o+DEsD/rRQF/u9g+wD8384XCP5v pyjwfzNR78b/6QoL/g/8301R4P/A/+kF/u8u/o9DIBb5PyUaDuT/jDmL/6Ow5Rv8n8aWg/8r ReX1/5rP4v+EfTmQ/7P1rfp/EjxyJP9X3eL/5FHelP9rbtX/U/5Pgt638n920pCoj+H/jDXg /z6Z/3MB/N/KXoH/O5T/M/bZ/F/kFwz+b0nUffX/TH0e/yfgH/i/BaPnTv4vjQ34vx/rFuD/ wP/dEAX+D/zfDVFZp6Ym82X4P1lnjYSubOT/snuQlntF/q+v6AX+71D+r9ugOlu426jauFmU iex206YC/wf+78n8n7UvwP+RQQD+D9ezL+X/3CNlrOP/PPN/of6qwP89/qJZDv5vvd8b/N/+ XoH/26FWnMX/VTf5PyGFzuD/+uy04P++HRZP5//IC63NRlGdBdOMDYsC/7dS1NJqscD/sef5 SP6vjeD/DugV+L834P8o3Az8305RF+T/LPg/8H+3XyD4v52iwP/t6BX4v52iPor/k8gj8H+r RIH/e0/+T7JMgf+7R+l8Pv+nEYjg/348BF3zfP5Py5qA//uG/7Ofxf/VcvMD6/817fP5v3Q4 /xefXv+vatzh/N8n1f/rBmYD/u9d+D/2BYL/WxR1F/9nanE3viX/Z/wl+b/q6fX/ovXg/8D/ PZP/M7oPXoz/SwIlXY3/a8dmM//XThvwfxX4v29E3egV+L87oTzwf8fxf516K/suL/AbRWX3 uCr/h/p/+08bl/i/biYl2qga6c5G/o9MDG2qF+H/xGlzMf6v5sMQ8H/fRFxck/9zEfwfrtWX 8n/+kTLW8X9B+D/7VYH/e/xFsxz833q/N/i//b0C/7dDrTiJ/3O36/+B/wP/N+P/LGmj2mwU ZSJ7y7VhUeD/VopaWi3m/B8f9B3K/1HyVPB/u3sF/u8N+D/U/wP/t8T/of4f+D/wf4Uo8H/g /xZ+DPzfS/N/okqD/1slCvzfW/J/lQaNgP+7h6dY5P80UHEf/6dv8Dv+z40SN/N/6j8aYh5P 4v/IcPyk+n/g/8D/ncL/+XiD/xMZ4P8WVosn8X+uviT/58IS/2e9O5z/63s1/1jg/16O/yMw +ZP4P4Ze3pP/u2j9vxfg/0xzIv8XJ8278X/VDf6vEl3zHP5PA+tP4P90bT2D/6vlvqfwf7Lg 7eP/JkluWNQn8X+tGZuta+D0HlUF/q8C//eNqBu9Av93J5QH/u9A/i+qb4Q3/I2isnvQD70M /8d32sv/qU8B9f8ewf/ZTkVytFGlYLeKMtHHdmgmosD/Hc3/RfB/d/F/Dfg/8H+4+FL+LzxS xjr+Lwr/578q8H+Pv2iWg/9b7/cG/7e/V+D/dqgVz+f/JFLgBP7PyhnGkfxfvMX/BbHiwP9t 5f8orkibjaJMbOzYsCjwfytFLa0WC/wf/Tb4v3vOKMD/7Rd1Nf4vWvB/e0VdkP9D/T/wf+D/ ClHg/8D/LfwY+L+X5v8kIA383ypR4P/ek//rnWbg/7byf17Ut338n/oTv+P/VBPkcOCt/N8s PvV69f/O4/+YU1rm/8RPAf7vx/yfi+D/9vF/yZ3G/8Vb/J8/nP9zp/F/OgKr2XUm/6cBVZfi /wJtGwfzf/EF+D/fF6xiUeD/bvB/ZON/FP/Hq8V78n+o/3cJ/k9GqKhKW/k/O21O5P9u1v+T Xp/D/8m/n8H/1TLcTuH/NECLtdvL8H9if53C/4kKf079P1FjRAHcWv9vco+qAv9Xgf/7RtSN XoH/uxPKA/93IP+X5Fgi8Ua1tf7f9B4jKQf+D/zfQq8K/i+41B7M/5m6eQH+T9Sxi/F/7JEG //ddxEU3FJ/O/3G87LH8n/Xg/3CtvZT/i4+UsY7/S8L/xa8K/N/jL5rl4P/W+73B/+3vFfi/ HWrFWfxffYv/Ewfom/J/Ffi/B/F/9NvabBRlopxZx2ZYmMD/rRS1tFqA/9txRgH+b7+oq/F/ qP8H/o9/K+P/KIgO/N9aUeD/DrYPwP/tfIHg/3aKAv83EwX+D/wf+L9lUeD/9nYL/N+sVwfw f7YVtf7A+n/RXpD/Mw34P/B/4/e+dv2/S/J/xFOA/5uJWsH/0cq+wP+laI/m/6x/Af5PHvQU /k93jDP4P3pbx9b/cwH838peof7ftfg/1zb2cP7Pgv8D/yc3mTY3+T/dB0/h/9LYbOb/2mkD /m/1Ggj+Txrwf/eKutEr8H93Qnng/x7A/7FesJP/U93CN1fk//pegf87lv+L5N4k/k9Uzq38 XzM0lSS/ezL/p+Af+L9vDirGDf9K/J+14P/A/+HiS/m/9EgZq/i/UAv/Z74q8H+Pv2iWg/9b 7/cG/7e/V+D/dqgVJ/F/dMx4g/8TfeIU/k+MqTP4Pzm+B/93T4T5Iv9HnmdtNooysYljw6LA /60UtbRaLPB/1KtD+b9kwf8d0Cvwf+D/yl6B/9sp6qz6f7UH/wf+7+YLBP+3UxT4vx29Av+3 UxT4v5XdAv/XN+D/Xpn/M7XCDeD/tvJ/Gqi4j//TNwj+7xD+zzUvUP9PugD+78f8HxmO4P9W fSvU/zuW/7On8X8kapn/04O59+T/btT/a4kaMt2auyMIp5EAf234BT6d/wt9UQkWBf4P/B/9 Yy2GIvi/uesn5/8i+L8H8X+yzr4n/2fsDf6vavjDnMP/KUB5Bv8nI/CU+n+qLrJ2exn+T7Tf U/g/MXrA/1Xg/6adepwo8H/g/26Iyjo1NZmvw/+JY0iarfzf9B70k1fk/5J9Pv9n6rFXx/B/ xj2b/2vr1nDeInUEbuL/As1GbaqX4P9sKyMQ/N8n8n+mBv8H/g8XX8r/NY+UsY7/M8L/ua8K /N/jL5rl4P/W+73B/+3vFfi/HWrFSfwfZXUG/7dS1Afzf45uoc1GUUaCrLVhUeD/VopaWi3O 4P9Q/w/8301R4P/A/82GxfX4vwj+D/zf7RcI/m+nqIvxf8GD/ztIFPg/8H/5GwT/t18U+L/7 Bzv4v+EFgf+7yf91huMF6/9Z8H/7+L8I/g/8XyX/ZdJcsv7fRfm/W/X//PH8XwP+7134v+6H wP+t7NXT+D8L/g/8XzW81xfi/6Su5kn8X5o04P/A/6ks8H/g/8D/7R4W4P/A/817Na//x/9z Z/2/yT1GUdfi/2J9Rf5vAuU9q/5f6ixT42xs9/B/tAtrU4H/A/8H/g/8H67XuJT/ax8pYx3/ Z4X/C18V+L/HXzTLwf+t93uD/9vfK/B/O9SKs/g/e4v/k1d2Cv/n9Mj4DP5Pgn3A/23l/0jN 1GajKBPZe60NiwL/t1LU0mqxwP+Rt/9Q/q+N4P8O6BX4P/B/Za/A/+0Uhfp/a0WVbxD83wEv EPzfTlEX4/9Q/w/83w9EPZX/k0gz8H+rRIH/e1P+T7sD/m8z/yfd5njFzfyfOnVcIepK/N+J 9f9O5P+aW/yfhpiD//uG/0P9v538n4/P5/+c+kOP4/9MuCD/Z6XM1gL/p71+T/7vRv0/l8LR /F/fq/nHOpH/kwc9hf9TN8Vb8n+fVv+P65S9K/93zfp/xl6R/2tu8X9C4V+M/1M/zzn8nzzR GfyfGFan8H+6D57B/9l6bLYaqNlxY3WT/5OPdA7/J8F0p/B/7dhs5v/aaQP+rwL/942oG70C /3cnlAf+70D+L3r+n7Hdwf9l9yCV6Yr8X+PB/x3Sq4L/65T2hvm/ZrMoAv/C0LB1+HT+T8G/ y/F/PPTA/30XceGfz/9xzO2h/F/3psD/4Vp7Cf+XHorareP/HPN/Pn5V4P8ef9EsB/+33u8N /m9/r8D/7VArTuL/6IwC/N9KUZ/M/9EI1GajKBNbNzYsCvzfSlFLqwX4vx1nFOD/9ou6Gv8X Lfi/vaLA/81lgf8D/wf+76Yo8H87egX+b6co8H8ruwX+r2/A/4H/A/9X/dgp/Qn834n1/8Ze PZz/u1n/D/wf+L+r8X/VefxfdV79Pwv+b+VqcR//F9w16/+B/7uP/6sb8H8re/Us/s/4S/J/ 1SXr/4H/A/8nN6mnzWfxf9GB/wP/B/7vEFE3egX+704oD/zfkfyf1FePYccamN1jFHUt/q+N z+f/5H9ei//zsW6Z/xPX3Vb+zw1N9RL1/8D/fTL/9wr1/8D/4XqJS/k/80gZ6/g/L/X/6q8K /N/jL5rl4P/W+73B/+3vFfi/HWrFSfyfv1n/T4bFKfyf6NhH8n/xJv/HXQD/d0+E+RL/58lZ rc1GUUaqzWvDosD/rRS1tFos8H/seQb/d8cZBfi//aKuxv+h/h/4P/4t8H8V+L97XyD4v52i wP/t6BX4v52iPor/k/BU8H+rRIH/e0v+T6PEwP/do3Te4P/asdnM/7lpA/7vbfg/8qne4P+k V+D/wP9Nrgfwf8ldsf7fJfk/1zS3+D91J8h7fjP+j5LbL/B/3jrU//tc/o9s/I/i/8Td+Jb8 35n1/6pP4v8ST6gU+pjHjfyfHZsf8H9R8TXwf99+qxv8X5o01+H/wths5v8yo+cV+D+xla/G /7VmbLaugdN7VBX4vwr83zeibvQK/N+dUB74vyP5P1Y5NUZhK/83vQf95BX5v1eo/3dJ/q/u LFPi/6Q7G/k/MjG04R96Ov/Xu/Qvxv+xSx/833cRFxfl/xrwf7hWX8r/2UfKWMf/BeH/7FcF /u/xF81y8H/r/d7g//b3CvzfDrUC/N9KURn/V4H/exD/14Sh2SjKRI6p0YZFgf9bKWpptTiD /6PDU/B/u3sF/g/8X9kr8H87RZ3F/0Xwf+D/br9A8H87RYH/29Er8H87RYH/W9kt8H99A/4P /B/4v+rHTumP5v/UsDyQ/6Noi6fX/wP/B/4P/N+KwQ7+71r8X50C6v99Lv9nogX/t7JX4P+u xv8FD/4P/B/4vxVTuJ424P9Wr4Hg/6QB/3evqBu9Av93J5QH/u9I/i/ychzZBNnK/03vUV2U /4s1+L9DelXwf3WdHPN/Yh5s5f/S0FQvUf8P/B/4P/B/u+yrZ3NLuI65lP9zj5Sxjv+Lwv/5 rwr83+MvmuXg/9b7vcH/7e/VU/k/VZ7A//2Y/3PxJv8nkQJn8H+1oojg/74dFs/m/wIZIdps FGUSn7xqw6Kez/9NR89l+D/enMD/3XNGAf5vvyjwf+D/ZsPievwf6v+B/wP/V4gC/3eL/4sB /N9BosD/gf/L3yD4v/2iPob/kzEA/u8enmKZ/5Nug//78bG6resr8n/R3+D/Wvl38H/g/ybX W/N/xl6R/3PxFfi/oC+Sm2vwf8G3R/N/rn4B/s/LcnsG/6c7xuP5P9827mj+r2k/if8zcn4H /m/u+nka/2fs0/k/34D/28f/pfP4Pw2AOIP/E+33HP5P9sEz+D/Tf8tqu4EK/g/8392iwP+B /7sl6kavwP/92Ox+Ov8X+L77+L/pPUZR1+L/fHNF/q+vlPc8/q/7n1L/T1WljfxfHJqJqGfy f4nVnKvxf/z6wf99F3HxCvyfbeXmx/F/3Z4H/g/X2kv5P/9IGev4vyT8X/yqwP89/qJZDv5v vd8b/N/+XoH/26FWnMX/1S/A/8Xz+L/+LAj837eilvm/FIZmoyiT6jA2LAr830pRS6sF+L8d ZxTg//aLAv8H/m82LK7H/9ka/B/4v5svEPzfTlHg/3b0CvzfTlHg/1Z2C/xf34D/A/8H/q/6 sVP6Xv7Pjc278X8Xrf8H/g/8H9/kafxfSKj/t1LU0/g/+0n8X9McXv+v79X8Y4H/ezn+77Pq /701/2f8efxfBP+3i/+j/ep6/B8NC/B/63oF/u96/J8bm838n5s24P8q8H/fiLrRK/B/d0J5 4P+O5P9iGpvN9f8m9xhJuWvxf8mC/zukVwX/18QmEv8XWrtVFIF/fmgqcX6D/zugV+D/NvJ/ Efwf+D9cfCn/Fx4pYxX/F2vh/8xXBf7v8RfNcvB/6/3e4P/29wr83w614iT+z/qb/J+MhxP4 PyOGL/i/O4bF0/k/8jxrs1GUSRwZog2Lej7/p48C/m9mWvlJA/4P/N/n8H/Jgf/bK+p6/B8H JYD/WykK/N/B9gH4v50vEPzfTlHg/2aiwP+B/wP/tyzq+fyf3Bf83z08Bfi/VePiafxf8Kfx f/VN/k/8FOD/fsz/OQ/+bx//13jU/1spKuP/vD2N/+ssqVv8n9cXyc1D+T/e44/k/yoKLVqq /3c8/0duJvB/a17ggqiT+D/ahT+J/5NAxIvxf649nP9z5/F/9K3A/61TpMH/gf/7xuipwP+B /yvuMRc17dbDRIH/A/93S9SNXoH/+7HZ/Wz+L4kiIc1GUdk96CevyP9ds/7fBMp7Vv2/Tr09 mP+zJoL/O6RX4P828n/XrP/nwP/hWn0p/xcfKWMd/2eE/3NfFfi/x180y8H/rfd7g//b3yvw fzvUipP4P9M8n/9T9R383x3D4tn8X3RhaDaKMqlux4ZFgf9bKWpptTiD/6OjK/B/u3sF/u8d +D/U/wP/x7+V1/9rwP+B/7v9AsH/7RR1Mf7PGPB/B4kC/3cw/ye/Dv5vlSjwf+D/Bpcq+D/6 A/zf9FidygGdxf+NvXo4/3e7/h/4v3v4Px/B/4H/q+S/TJsr8n+u+SD+z8Q6Hc3/kZsJ/N+a F7ggCvzfyhd4J//XjM278X+cwvJ6/N/z6//FIPxfkjVwK/9Xjw3vV+D/dn4r8H/VKu0W/N9J /F8Ym838X5g24P8q8H/fiLrRK/B/d0J54P+O5P/E9diwcbmV/5veo7po/T9zyfp/T+f/Op2s 6wfxfyluFUXgnx2aCvwf+D/wfw/g/2gNBP+Ha+Wl/F96pIx1/J8V/i98VeD/Hn/RLAf/t97v Df5vf6+eyv9pzDb4v2/4P/sK/J/ER5zB/4niC/7vngjzRf4vhqHZKMokPjHQhkU9n//TKQ7+ b2Za+UkD/g/8H/i/xwwL8H87RZ3F/1nwf+D/br9A8H87RV2M/0P9P/B/PxAF/m/PxwL/t1/U x/B/GrEH/u8d+D/VBB3f6c34vxPr/9n0/Pp/URZX8H/f8H81+L+34f/Gb5WvS+/N/zWn8X/e X5L/a80i/9cN8mvyf3pMJqLA/93g/7qBBv5vZa/A/4H/mx8N38v/KQv1nvxfdYv/00P1U/g/ meKn8H+ytp7B/9Vy31P4P3WO8Hh9KP8XGp6vp/B/EhcD/q8C/zft1ONEgf8D/3dDVNapqcl8 Gf5Po+gSWx8bRWX3IDXsivzfNev/ke/22fxfZx6Yrk/tHv4v2qGpwP89kP9jtRb83zcRF6Zf LS7F/6H+H64Nl/J/zSNlrOP/nPB/6asC//f4i2Y5+L/1fm/wf/t7Bf5vh1pxEv/nIvg/8H+L opb5vzYMzUZRJnHwlzYsCvzfSlFLq8UZ/F+y4P8O6BX4vzfg/8iTBf5vpyjwf3NZ4P/A/4H/ uykK/N+OXoH/2ykK/N/KboH/6xvwf+D/rs3/tWOD+n83j9Uvyv/drP8H/g/8H/i/N+D/6LDn rPp/9pP4v+jbo/k/SswJ/m/NC1wQdVb9v24X/iT+T/1KOq828n8lugH+b/4Cwf+B/9v7rcD/ Vau0W/B/4P/oR8H/LfUK/B/4P/B/h/F//KCJEJjt/N/kHqOoa/F/PdV4Lf5vAuU9if/rbGBH ZJFze/g/b4eGPxn4v0N6Bf5vG//X2Wjg/1b2CvzfRS/l/9pHyljH/3nm/6L5qsD/Pf6iWQ7+ b73fG/zf/l49l/9TFzz4v1KteD3+T/zp5/B/4qgF/7eR/0vkrNZmoyiT+DBKGxYF/m+lqKXV YoH/o98G/3fPGQX4v/2iLsb/kScL/N9OUeD/5rLA/4H/A/93UxT4vx29Av+3UxT4v5XdAv/X N+D/Xpv/03NT8H/g/yYX+L87+b/b9f/ETwH+D/zf5HoA/xfS8/k/OUB4T/6PXBcfxP/V/HUO 5f+SX+L/rGncNev/qW5R6yet+jXhjfm/wHDRsfxfYz6K/+Nd+HL8HyuZh/J/KZzG/9G3ei7/ l+r6aP6PB/v1+L8I/g/8H3+jetrc5P8C3/dy/F8cm838X5w24P8q8H/fiLrRK/B/d0J54P8O 5P8SO4Y7JWmHHpjdoxoq5V2L/4s1+L9DepXzf7bTlJj/U7fgRv7P2aGpXqL+n4J/V+P/OP4I /N93ERevUP8vhqP5P1oDwf/hWnkJ/9c8FLVbx/8Fqf9nvyrwf4+/aJaD/1vv9wb/t79X4P92 qBVn8X/18/k/V4P/exv+rwlDs1GUSbxoasOiwP+tFLW0WpzB/9HhKfi/3b0C//cO/F/Tgv/b Kwr831wW+D/wf+D/booC/7ejV+D/dooC/7eyW+D/+gb8H/i/S/N/ogJKs5n/K9/gDf5vghpu 5v/ctAH/97D6f+D/wP9di/+r/BX5v1v1/4yhkmidUqYvbSP/p9iCfIum/iD+r1ssDuf/XqH+ nzwo+L9SVMn/0RQG/7eqV+D/DuX/nl//7wH8n7lk/T/qFfi/db0C/wf+b2kTAf/HDfi/e0Xd 6BX4vzuhPPB/B/J/UcZcbHfogdk9qqFSHvg/8H8LvSr4v9A2EfzfsqjX4/8kGeK1+L9OSTqa /3OxviD/R1Yj+D9cKy/l/8wjZazj/6Lwf/6rAv/3+ItmOfi/9X5v8H/7e/Vc/k/tIfB/pVqR 8X/WP5//s3JKBv7vjmHxbP6PEt32zUZRJnGaYW1YFPi/laKWVosF/o8DisD/3XFGAf5vvyjw f+D/ZsPicvwfuZfA/60VBf7vYPsA/N/OF3gW/+ca8H8HiQL/B/4vf4Pg//aLAv93/2AH/9c3 4P9uHqufyf+NvXo4/3ez/p+QcuD/5qIy/s958H9vw/+NvcrXpQfwf/Hp/F/VMP9nGiVDNoYW SXeCmk4fxf/Vh9f/M69Q/0++5dX4v9aA/7tzXi3zf8LXvCn/Zy/J/1VXrP93m/9TkONi/J8s t+fwf/KRzuD/dBkH/7eV/5P5eg7/Jx/pFP5Phs0+/m9yj6oC/1eB//tG1I1egf+7E8oD/3ck /9fIvsunE1v5v+k9qovW/+upRvB/B/N/oXuU6/F/VmbS1fg/SbtzMf6v9lfk/0J7NP9HCdXA /+FaeSn/Zx8pYx3/l4T/i18V+L/HXzTLwf+t93uD/9vfK/B/O9SKk/g/OmZ8Ov8nuWvA/90x LJ7O/9Fva7NRlEmyaCU7LEzg/1aKWlotzuD/kgX/d0CvwP+B/yt7Bf5vpyjU/1srqnyD4P8O eIHg/3aKuhj/h/p/4P9+IAr8356PBf5vv6gP4f+GPJrg/8D/Ta735v9OrP8H/g/1/+R7P4v/ a/xp/F+8Iv9HrgvwfzNRK/g/nxb5vxDN4fzfK9T/09B2abbyf7PTsifzf8Y0B/N/pm7A/63s Fer/gf+bHw2D/6vA/90Tn7rM/5nz+D9bj82D+b8G/B/4P/B/h4i60Svwf3dCeeD/juT/pB/S bOX/pvegH7oi/9dTjdfi/8h3+2z+r7sF8X/ykbbyf2ZoJqLA/4H/W+jV4/k/cj0+nf9z4P9w vcCl/J97pIxV/F/3d+b/zFcF/u/xF81y8H/r/d7g//b36rn83yNCiS/I/9kX4P96vQ3837fD 4un8H3metdkoyiQeR9qwKPB/K0UtrRYL/J/EP6D+H/i/7Mp+DPwf+L+FHwP/d4v/a8D/gf+7 /QLB/+0UBf5vR6/A/+0UBf5vZbfA//UN+D/wf9fm/+TfT+H/JFBxH/+n/qMh5vEs/i+50/i/ 4E/j/+JN/k96Df7vG/4vgv97m/p/4P/A/1XVjP+7Uf8vpMPr//W9mn8s8H+vxv91BtpH8X8S iHg1/o8/0qH8n0vg/1aJKvm/5hb/ly1M1+H/xJg6g/9LMmzO4P+MjMBT+D8ZNqfU/+vDZ6rt Bir4P/B/d4sC/wf+75aoG70C//cDs/sV+D/xREY+39nK/03vwc4E8H9zUQfwf6JbHMn/Gfds /i/WMQn/t1kUgX/10ExEPZH/U/Dvcvxf4gb8348jLl6i/h/4P1yvcCn/5x8pYx3/Z4T/c18V +L/HXzTLwf+t93uD/9vfK/B/O9SKk/g/Mhifzf+p7gf+745h8Wz+r6UJpc1GUSbJ+WHSYB7w f+D/lnsF/m+3KPB/a+ZVdiBnTQT/t1fU9fg/ci+B/1srCvzfwfYB+L+dLxD8305R4P9mosD/ gf8D/7csCvzf3m6B/5v16uP5v/Pq/1Ue/N8u/s958H+o/1fJf5k04P/env9r6FzpWP6P4n3A /615gdWd/F9N1MCx9f+aFvzfyl6B/wP/Nz8aBv9Xgf+7Jz4V/N+6Fwj+jxvwf+D/lnoF/u9O KA/834H8XxKXtDQbRWX3GEVdi//riR7wf8fyfynW8WD+j6KmwP8d0Svwf9v4P9T/A/+HSy/l /8IjZazj/6zwf+GrAv/3+ItmOfi/9X5v8H/7ewX+b4dacVb9v+b5/J91emR8HP/nwP89iP+L YWg2ijKJX4M2LAr830pRS6vFAv9H3n7wf/ecUYD/2y/qYvyfiRb8315RT+f/jAyEA/m/Gvwf +L/bLxD8305RF+P/XAP+7yBR4P8O5v88D23wf6tEgf97S/6vahRuAP+3lf9TwusU/k81Qcd3 2sj/zeJTwf+tGhb31v8TPwX4P/B/k+ut6/8Ze4v/k3igI/k/dxr/5+Jp/J/1H8T/df+aKODb 2z38X8u/rA34vw3L7bP4P9qFP4n/U7/Se/J/Fvzf2/B/9or8H0Wz3+D/ZOidwv+lSfNg/k/W 1jP4v1rVxRP4P1uPzYP5P4m1uCr/Z6r9/N9kBIL/A//3A1E3egX+704oD/zfkfyfjDlptvJ/ 03tUQ6W8a/F/Ll6R/5tAec/h/5yNbUvui1a9c5v4v+Tj0FQvwf/ZVkYg+L9P5P/MNfk/C/4P 1+pL+b/4SBnr+D8n/F/6qsD/Pf6iWQ7+b73fG/zf/l6B/9uhVpzF/9kX4P/aw/m/CvzfQ/i/ yCcz2mwUZRIfpmvDosD/rRS1tFqA/9txRgH+b7+oq/F/TQv+b6+oC/J/qP8H/g/8XyEK/N8t /g/1/8D//UAU+L89Hwv8335R4P/uH+yfzf+JCgj+75tj9YvyfzX4v138n6/B/71//b935v+I KTuJ/yMvycfwf7bx7mj+jwBK8H9rXmAF/q86h//jlb8/UNrK/8VpcyL/h/p/4P+qaniv4P/A /902eirwf+D/invMRU279TBR4P/A/90SdaNX4P9+YHa/AP8X9djZ7lgDs3uMpNy1+L9OZ386 /yf/81L8n21IYyL+z9itokxMVL5Dm+ol+D/U//to/q+5JP+H+n+41l/K/6VHyljH/3nm/6L5 qsD/Pf6iWQ7+b73fG/zf/l6B/9uhVnwS/9dIfAT4vzfg/8gLrc1GUSaxe1kbFgX+b6WopdVi gf9jzzP4vzvOKMD/7RcF/g/832xYgP+byQL/B/4P/N9NUeD/dvQK/N9OUeD/VnYL/F/fgP8D /wf+r/qxU/pe/s+Nzbvxf9aY0/i/4M/i/yp/i/+LsriC/wP/N7kewP/F5un8n5Mgvffk/76r /5faHedKA/8nEZj2Bfg/vsWh/F/3rZbq/1Gs9xXr/0WlRMD/5aJK/o/WwA/i/zhW73L8H6s5 h/J/pgH/t0rU/fyfyLgY/6dhPmfwfxoAcQr/J104hf/TAK0T+D/twhn8n4RGn8L/idED/q8C /zft1ONEgf8D/3dDVNapqckM/m8i6iP4v1eo/3dB/s/VqVNJDUUINltFEfgXh4Z/6On8n5WZ dDX+j70I4P++i7gA/wf+D5deyv81j5Sxjv8Lwv+5rwr83+MvmuXg/9b7vcH/7e8V+L8dasVJ /B85o8H/rRT1wfwfa6PabBRlksSlp4nfG/zfvjUQ/N9KUeD/+gb8H/i/hR8D/wf+Ty7wf+D/ wP9t5v9cA/7vIFHg/8D/5W8Q/N9+UeD/7h/s4P/6BvzfzWN1qlP2SfX/wP+B/wP/t5n/q86r /2fP4/+aD+L/bBOvyf9dsv6foT3xWP4vePB/K3sF/g/83/xoOOf/aBcG/7fzW4H/q1Zpt+D/ wP/Rj4L/W+oV+D/wf+D/juL/xBuTeNvayv9N7wH+r3oj/q8n5Z5X/y+1tmb+T1x3W/k/NzQT UeD/wP8t9Orx/J/14P/A/+HiS/m/9pEy1vF/Ufi/8FWB/3v8RbMc/N96vzf4v/29Av+3Q604 i/+rXoD/S3o6Df7v22HxdP6P4oq02SjKJDFkkh88xOD/VopaWi1m/F/NpwSH8n/Bgv87oFfg /8D/lb0C/7dTFPi/taLKNwj+74AXCP5vpyjwfzt6Bf5vp6iP4v9ElQD/t0oU+L835f9kDID/ u4enAP+3alzk/F9Ip/F/Y68ezv/Fm/yf+CnA/4H/m1zX5P+8vBPwfwvD4mP5v+6FteD/Ppj/ s+mj+D9+UPB/C64f8H/n8H9ZYdI34/+Mvcn/SSjTGfyfPtEZ/J/6Xk7g/ypV1k/h/9Q5wuP1 ofyfnr2fwv9poNkZ/F+jG8Ae/m96j6oC/1eB//tG1I1egf+7E8oD/3cc/2esb8Zmm6j8HqOo a/F/lFAN/N8Bvcr5P2OS8n/ObhVlYiJ7QpvuZ0x8Ov+n4N/V+D8rWy74vzfg/9qj+T8SBf4P 18pL+L/2oajdOv4vMf8X4lcF/u/xF81y8H/r/d7g//b3CvzfDrXig/g/Jx5k8H93DIun83/0 29psFGUSH3Bow6LA/60UtbRanMH/dcY9+L/9vQL/B/6v7BX4v52iwP+tFVW+QfB/B7xA8H87 RV2M/4sB/N9BosD/Hc3/cTgQ+L9VosD/vSn/J/cF/3cPT7HM/8m/g/8D/zeVBf4P/B/4P/B/ Gf9nP4f/q5qa8iGC/1sWdX3+z0QL/m9lr8D/gf+bHw0X/F8F/g/8n9xk2oD/A/83u0dVgf+r wP99I+pGr8D/3Qnlgf87jv+ztQ1js01Ufo9R1LX4v/YF6v8ZN/bqGvxfZxvYTpE2zrbtDv4v cgCUNBX4P/B/T+b/KEDryfyfZ6cI+D9cz76U/zOPlLGG/zP03zvj2duvCvzf4y+a5eD/1vu9 wf/t7xX4vx1qxQfxfzayaQX+745h8XT+jzzP2mwUZZKPY8OiwP+tFLW0WpzB/1Ue/N8BvQL/ 9w78X92A/9sr6un8X5KBcCD/V4P/A/93+wWC/9sp6qn8H8fFgP+7RxT4v5mod+P/rCx74P/A /90UBf4P/J9eZ9b/U03Q8Z3A/70A/1ff4v+01+D/fsz/UV5i8H+rvtXr8X8uqj/0Hfk/0yzz f6aR8SDN1h1f/rM2L8D/2ZapxkP5PxOW+L/IrnbTCUrbtbOmZQ1Bm9fg/zLM5rH8Xz2FyMH/ vTT/V7NWtpP/k4/0Qvwfj4FD+b+q/SD+L7Yk6iT+TwN+H8//mVZe2YH8X3ezW/yfEA2n8H8y bK7G/+lgvxb/l3i+nsP/iXlwCv8nw2Yf/ze5R1WB/6vA/30j6kavwP/dCeWB/zuQ/5M4Tm02 8n/ZPUZRz+T/RGdxZkfssgntpHkF/s/K1zmS/zPuyfxfrGN03Rdoo+jT2/g/SwqeNhX4v8fx fxx/BP7vu4gL9pw9mf9rSJsA/4fr2Zfyf/aRMtbxf0b4P/9Vgf97/EWzHPzfer83+L/9vQL/ t0Ot+CT+z2m0Lfi/b4cF+L+VvQL/B/7vjjMK8H/7RV2N/4sW/N9eUdfj/yiyDfzfWlHg/w62 D8D/7XyBy/wfx96A/7tHFPi/mah34/9YzQT/t04U+D/wf4NLFfwf/fHW/F8zCex4MP+nkdfv yf/drP8nscTg/+aiMv7PxY/i/5TGO4X/UyflKfxfLRLfkf/zN/i/qhFL8cj6f80L8H9JXuDD +b/gPPN/3afaPgKblp9Am8/j/xRQOoH/o28J/m9R1F38Xy2G4pvyfxb834P4P+o1+L8lUeD/ wP99d9xYgf9bvQaC/5MG/N+9om70CvzfnVAe+L/j+D9nWOXUZpuo/B6jKPB/R/N/clp1Kf4v 1CGG7gsEk7bzfyH6NDQV+D/wf2v4P2vrC/J/gW0P8H+4nn0p/+ceKWMd/2eF/4tfFfi/x180 y8H/rfd7g//b3yvwfzvUikX+r+ZohCP5v25sPZ//qzWw/gT+T8A/8H/3RJgv8X+WbqHNRlEm 8dDThkWB/1spamm1AP+344wC/N9+Uc/l/+Rtgf+7R9QH8X883MD/3fUGwf8d8ALB/+0U9Uz+ L3DEo3ei3m7l/+pJU1kD/u8gUeD/jub/uA/g/1aJAv8H/m9wqX4W/yf/fjH+TySfwv/pMnQG /8c1es7h/7zMoovxfzWLAv+3MNjv4/8iv7lT+L9anJQH8n/uFv9nFW87gf9jDuAc/o9f/+X4 P45mP4H/84kK/xnnXNzB/zUcxq7Na/B/uq2dwP8piXIK/0ddAP+3KOo+/q+h5dj0asw+/m/4 Vsv8H62B5/B/cjR8Dv/XDwsZRNtCzKf3kG/1bP6PEN6z+D/5lmfwf6wHnsP/SR7kU/g/PXs/ hf+TD3MK/yer0Bn8n5D+5/B/8k5O4f+EqTmD/1OHYbOH/5veo6rA/1Xg/74RdaNX4P/uhPLA /x3I/4lSoc1G/i+7B/3Q8/k/gfYkn8Zm/i9Nmpfg/5I4VK/E/3mXUkubebKbRXV6HSkj2lQv wf/ZVhyuV+P/+DDkWvyfiXR6cDn+L7HfAvwfridfyv/5R8pYx/955v+C+arA/z3+olkO/m+9 3xv83/5egf/boVZ8Ev8nOiH4vzuGxdP5P1IztdkoysgJkekPisD/PYj/M3zCfSz/V4P/O6BX 4P+O5/8k/RT4v3tEfRD/V0uMKPi/O94g+L8DXiD4v52insv/0dN6Jy9tI/8n+Zq1Af8H/g/8 X/lI4P/A/y38GPg/8H9yncj/hUlgx6P5P7HoT+D/rAQTncP/yci+Fv8XZHcC/7cw2O/j/wQE O4P/c/KRzuH/ZPs4g/9j5uwk/o8j5q/G//EqdAb/Z62hgG+bdqRFbBrR9aV5Df4vTTGby/B/ pPqB/1sUBf4P/N89GtMS/9c0Fvzfja0x4//IGP4g/s/K0nAC/yeG9kn1/+RtncD/BSnlfjX+ b8pC7Kz/B/4P/N+dom70CvzfnVAe+L8D+b/I2oQ2G/m/7B6jKPB/R/N/akVcif9znU7hyDYw xm4VZXygD61NBf4P/N8q/q++JP/X0r4L/g/Xsy/l/8IjZazj/4Lwf+6rAv/3+ItmOfi/9X5v 8H/7ewX+b4da8Un8nziUTuH/5HQa/N89EeaL/B95urXZKMokPr3RhkWB/1spamm1mPN/RgJI wP+B/8uu7Meuwv9ZCXEC/wf+b3JJQS/wf3e9QfB/B7xA8H87RT2V/+PFFfzfPaLA/81EvRv/ x5sj+L91osD/gf8brOGP4v+mmuBm/s8Vb/Dp/J/08Qz+r0oKk0l3Hsr/Je41+L97otkX+T85 Twf/tzDY7+P/5COdwv/Jecg5/B/3+hT+r+bA4VP4P37B5/B/GlB1Bv/HS8Oh/F+Vlvg/14RO wTTOtHZH/b/Ew1eb1+D/VKk4g/8LMtxO4P/q1oH/u3NeLfJ/hmsLn8T/kaF4Dv/Hu/Sx/J+/ xf9NtNvN/N/kHvKtns3/Ua+vx/9Fxx/iDP5Ptt9z+D9ZTU7h/6QLp9T/U3XxWvyfvv4z+D95 gefwf3ZsNvN/dtqA/6vA/30j6kavwP/dCeWB/zuQ/2uY7NZmI/+X3YN+6Pn8n+wekoFsK/+X Bal2Wtfz+T9ROR0r0ltF6ZGwNlV8Nv/nm04rM8ZozqFN/J9r6XhSm+pF+D9Jfnc1/o8N7Wvx fzV5zi7H/8WaDALwf7iefSn/Fx8pYx3/F4X/C18V+L/HXzTLwf+t93uD/9vfK/B/O9SKj+L/ 5MTzQP4vgv97DP/nSEXUZqMok3jOacOiwP+tFLW0WpzB/9HhKfi/3b0C//cO/J8L4P/2iroe /0dhnOD/1ooC/3ewfQD+b+cLXOb/NB71QP5vCuWB/wP/V4h6Kv/XcDgQ+L9VosD/gf8D/wf+ 7/axenOr/p8Ea78n/0c+VfB/63qV8381+L9d/B/Nq7P4v+oG/+d7vO0t+b/an8b/2afzf66O 8gKP5P/qJf4vmlb4v+S2a2dN4jB2bYZezT8W+L9X4/94CoP/W9Wr+/g/Rw96LP8nSNQ/quKK UjTiWP6vPo3/M/bp/F9LG9VJ/J+CHI/n/2zN2u+h/F+8wf8ZDWW6GP/ntJTPHsfF6/F/th6b B/N/zTX5vzg2m/m/OG3A/1Xg/74RdaNX4P/uhPLA/x3I/wXeqFzgnX4j/5fdgzSi5/N/Aigd yf/1VOMT+T9XC1N2JP9XP5n/Cy2NObLn4mZRnXpHNpw2E1FP5P8U/AP/991BxQvwf86C/7uH /7Me/B+u1Zfyf+mRMtbxf0n4v/RVgf97/EWzHPzfer83+L/9vQL/t0OtOIn/q5oX4P+8Rtue Uf9PjnPB/23l/+gMQ5uNokwKaWxYFPi/laKWVosF/o9ufij/5yL4vwN6Bf7vHfg/1P8D/8e/ Bf6vAv937wsE/7dTFPi/Hb0C/7dT1Efxf7rsgf8D/3dT1HX4P3lb4P/u4SmW+b/eCVBV2/m/ Mur2evyfMf6z+D+NLQf/V4pC/b9T+D/vD+f/Ivi/XfwfDfZl/k9X/jP4P15gD+X/7GL9v7Y1 kfm/YLdrZ41MEW1Q/2/Dcnsf/8e3OJb/a8xn8X+8757B/3k2FI/k/4y9JP9XPb3+X+CcsIfy fwSR3+D/FF+7GP8nxtQp/J88yin1/2S4ncL/qf21i/+T8fBt/T/1JvB4fSj/F+VRzuH/JNDs FP5Phs0+/m9yj6oC/1eB//tG1I1egf+7E8oD/3cc/2dtS/e1YqBuE5Xfg8zGK/J/LoL/O6RX Of/XxtTpl6Zuk9hUG/k/eiXaVC9R/++q/J9sudfi/2w8nP+zT+f/gqUjv0P5P/IHgv/DtfJS /q95pIxV/J+phf+zXxX4v8dfNMvB/633e4P/298r8H871Iqz+D/7AvyfeKHB/90xLJ7N/3kT hmajKJP4jWvDosD/rRS1tFrM+T+Oej2U//MN+L8DegX+7x34Px/B/+0VdUH+rwb/B/7v9gsE /7dT1DP5v8ix7IfyfzaB/ztIFPg/8H/5GwT/t18U+L/7B/uH839xbB7N/01Ebeb/bogC/wf+ r6rO5/9Q/28f/0fzCvzfOlEZ/+f8C9T/ux7/Z2rbNMz/uR3wUJP4MbQB/7dhuX0W/2fqBvzf yl49jf9rXoH/a8dmM//XTpvn1/97BP/XgP8D/8c/Wk+bW/yfkRh98H8Lw8JlzSvwf2lsNvN/ adqA/6vA/30j6kavwP/dCeWB/zuO/zPiGzHRbheV34N1iwvyf9aD/zukVxn/16nZpmmJ/4v1 Hv6P/FTaVOD/wP89m/97fv0/z/Gy4P9wPftS/q99pIx1/J8R/s9/VeD/Hn/RLAf/t97vDf5v f6/A/+1QKxb5v87aqw7m/1TUU/m/RgJmT+H/9CwI/N+3opb5vxSGZqMok2IYGxYF/m+lqKXV AvzfjjMK8H/7RYH/A/83GxbX4/9Q/w/8H/i/QhT4v1v8X2PA/x0kCvzfsfyfRhaB/1slCvwf +L8P5f+k26fwf5Po5s38n5s21+T/CEh5Nv8nQcTg/xZi9MH/HVn/b4TyHs7/Vbf4P6f+0Hfk /86s/1ff4v+01+/J/wW/xP+ZVHvm/2y9fQQ2yaexGXo1/1jX5P/sdBN5KP9Xt+5g/o9iHj+J /2NH6Lvyfy9R/+9w/q96ev0/b11NbvyopNw2/q9ux+aq/F91k/+TFekU/k/+/RT+T9bWU/g/ eVun8H/qHGFFGvwf+L9HiwL/B/7vlqgbvQL/92Oz+9n8n2Pzwcjx/Ub+L7vHKOqZ/J/0A/X/ Fs7KXov/M5GipromBLtVlPEhtkNTiUca/N8BvfoM/i82R/N/kw3/afyfAf+H6xUu4f+6MfRA Gev4P0v8nzHg/065aJaD/1vv9wb/t79X4P92qBWL/J81R/N/pFY8m/9zejp9IP8Xwf89hv8L dAttNooy4mozaXRZgP9bKWpptVjg/zig6Ej+z0Xwfwf0CvzfO/B/pgX/t1fUBfk/1P8D/wf+ rxAF/u8W/xc8+L+DRIH/A/+Xv0Hwf/tFfQj/1wcHgv+7h6dY5v8mIceb+T83ba7J/3lzQf7P EDwE/m9Vr8D/Hcr/NekG/ycywP8trBZPqv9HWZIuyP8t1/8zKdVH838vUf9PS3mdwf815/F/ pFQcW/8v2o/i/3iUX43/cwH83x7+z3EE4kn8n5J0Z/B/jeMPcQL/V4mZcw7/p2T3CfzfQ+JT F/m/qtUArRP4P/Uo/f/Zu7sEV1UsDMM1FIYgqKizOvO/OoFFKibRXSKICb5cNN29q/wK4w8i T6jN/8n0gCL+T/49zf/NtqEU/k/h//6IWmkV/m8jysP/5fR/Tesr31Xa6//m23hIubr83xzl 1eP/7lLuRP/nhlC1MbbZHaX71s28CtWsVfi/7P7PH+V1+T/dm9z+zz3h4//iWoX/q7Tc/Z8+ MCPO/7Xi/+yPwv8dX9xZjv+LH/fG/6W3Cv+X0K0o5f/M+f7PTGG2bT7/p9b8n5WpGPi/vf7P 9r/Vzig9+LlJofJR+L/IqKWrxYL/c63K6v9Mh//L0Cr8H/7vtVX4v8Qo/F9s1OsexP9l2IH4 v8Qo/F9Cq/B/iVH4v8hmPfs/M+D/UqPwf4lR+L/YqG3+T7qAUu32f697cMX/yf9M839h/Oh3 ziPr/71Fbfd/qlvzf5O0Cv+H/5uV/P7PnVel/J+t0f99xvp/YThB9vOX+b/l9f+MNtnX/8P/ fY//c3fhS/k/f8yFO8te/9fNq4v5v/l7hr1TzN/w0Nn+r3E3qrz+z1zL/4WJ8yX8Xy83kUr9 n+/dJvq/38PiQv5Py7My6/8p/N+8UcdF4f/wfytRT42aPzJX4/+60T6qnf7vaRuPqLr8Xzfi /7K06sX/TXZqnf8z8niwz/8Z14kM1e1ntMX/ZWnVm//zg3/4v6VJqk/+bzzf/zXuOVHrIaxI uC9KXj2EqjUd/o8SW+7+zxyYEef/Ou//TPOj8H/HF3eW4//ix73xf+mtwv8ldCsK+T/3Pa3L /s/I43UJ/9eH0X7835+Hxdn+z38JSah2RunBP8GEykfh/yKjlq4WC/7Pjebj/7a8o8D/pUfh //B/b4cF/u8tC/+H/8P/rUZV5v/MgP/LFIX/+3j/p1j/D/+3GHW2/1PhMoT/2+Iplv1f/6h2 +785SJlF4f8+3f/ZZtn/3c0G/g//Nyvfvf4f/u+w9f++2f+NetH/tVOd/i8sLob/w//h/+L9 n131f7OO9G7/18+rOv1fnev/2VX/J1ekIv5PriYl/F8nH0wB/3f/ip8i/k9aleT/2vnTjFrz f708guD/3qPwf1Lh/7ZGrbQK/7cR5eH/Mvq/3j8XhGqn/3vaxiPqRP/3pK/2+r8n1IL/y/C2 ccH/GUczblU3SZdzn/+zevyt1Ef4P3mmx//99aLiccM/z/+NVa7/l9//GYv/o0SXu/9rD8yI 83+9+D/zo/B/xxd3luP/4se98X/prcL/JXQrSvm/5nz/18q4OP5vw2Fxuv9zg9Wh2hmlB3nl KpWPwv9FRi1dLRb8n9t4Vv/XWvxfhlbh//B/r63C/yVGlfJ/Fv+H/1vfgfi/xKjK/N+o8X+Z ovB/mf2fvDNg/b+oKPzfV/q/3xl7+L/d/i9ck5L8X9iD+D/838X8n8X/fcv6f24OSSn/Z4v5 v7Yr5v86s+r/gluR3V2H/+vcu6u8/s9dLfB/MTtQnef/bocF/i+uVWf5P9Ot+T+T3f+1q/7P Pqrd/s/Oq/P9n2ndnivk/6R3+6X+T+H/qvF//p1Qov8L1Sf4P7k0lPF/06Pa7f+meYX/U/i/ P6JWWoX/24jy8H8Z/Z8Vu2cnvTvqeRt+MKFC/9fa0/2fkWMup//T7en+b7j1LW43fXmi2+f/ rHa9hVD5n8T/ZWnVJfyfaZvc/u/3GliV/1Mj/o8SXe7+rzswI87/WfF/3Y/C/x1f3FmO/4sf 98b/pbcK/5fQrSjk/9zrkGX/F74KrIT/k9l5RfyfLDWI/9syw3zR/7lR6FDtjNKDfycVKh+F /4uMWrpaLPg/9+9Z/V834v8ytAr/h/97bRX+LzGqkP9zPSb8X2wU/i/z8wH+L3EHlvJ/fYf/ yxSF//t4/6dY/w//txh1vv8L703xf3v93329ghL+L2gcf5gn+r/HN2Pj/6IOi43+z+D/tvg/ 9+CI/4v6rE7zf7NWPV+Xvnr9PzOWW/+vWfV/YSRZ9nMd/k9PNrf/U5/g/8JtDf/3h/+72vp/ fu7/d/o/PX6C/5se1W7/N82rKv2f/6q9Rf8nv/2l/m91/T8rd48S/i9ImCL+T25OBfxfuJoU 8X/hglfC/8mhV8T/hf5LCf8XurW+2nsNnG9DKfyfwv/9EbXSKvzfRpSH/8vo/9rW36jaYX8/ 8Hkb7odq9H8fsP7fAf5vhvJO8n/aDQTqW28idJX2+T83KBWqWRT+D/+30KoC/u9xw6/I/7H+ H2VHufu//sCMOP83iP+zPwr/d3xxZzn+L37cG/+X3ir8X0K3opD/c190e7r/k7doOf2fxf8d 4/8GN9wQqp1Rt16xeVQ+Cv8XGbV0tSjh/9yrK/xfcqvwf/i/11bh/xKjSq3/1+D/8H/rOxD/ lxhVmf8zA/4vUxT+7+P9H+v/4f+Wo073fyY0B/+32//J/8L/4f/mrcL/bfJ/7sER/xf1WZ3n /2yN/q/g+n91+j/djIv+bxqzr//n1r7C/8XsQLXV/7mXf3n9nzuF8X9Rrbq0/5vfQfdOMX+7 C9fn/9wisvi/xM/qQv7vd1G+RnIP9X/Do8L//btvgf/D/61E4f/wfytRT42aPzJX4/+0PLxJ tdP/PW3jEYX/w/8ttOrF/43drSem28bI48E+/2dcJzJUt5/R9nT/93QE4v9WX1Q8bvjn+T8/ 67u+9f/8WxBtrUmIktHYULnxQPwfJbLc/Z89MCPK/5lG/J/+Ufi/44s7y/F/8ePe+L/0VuH/ EroVhfyf6ywt+z+ZG1XC/4W5Kqz/t+GwON3/ud8O1c4oPciQxfAYssD/RUYtXS3e/F8zyfwH /B/+76k8/Rj+D/+38GP4P/yfFPwf/g//h/97jcL/vUXh//B/+L/lqNP9XxMGzfB/u/1foBtJ /k9mIP7p/0JPMMn/hfmpNfu/R6tO83/PdAP/h/+T3Zvd/90ONPxfZBT+r4j/09bNo7s9Pib4 v9HvhlD9tur9wyro/8LUdvwf/m/u/7RMOf5K/+dW4V32f74JWf2f7ov5P23O9n/auO+Ezev/ xjX/F+41dfk/LY8gZfyfXE1K+L9w6BXxf7K3Svi/+7cJ+aidD6hPrxvVqv/rBSUV8X/yOF/C /8noX5r/m29DKfyfwv/9EbXSKvzfRpSH/8vn/9QkV9Apwf89b8P1cvF/C1H4v2X/NzT+e4vG KcH/daOVKoxLDKf7PzPdx6ASoj7P//lRhNr8n7XZ/d/jhn+W/7vddvF/lA8od/83HJgR5/+0 +L/2R+H/ji/uLMf/xY974//SW4X/S+hWFPJ/7Qf4v7bF/32N/3NjraHaGaWH0T4qH4X/i4xa ulqU8H+Dwf9laBX+7xv8X2fxf6lR+L/3LPwf/g//txqF/0toFf4vMQr/F9msJ//nJkjj/xKj 8H+JUfi/2Cj8X07/1+ka1/9T+D/8n/95/N93+r+uKef/7IX8X9vp1k347rqE1yLj5F9Khco7 JfxfzA5U5/m/vsP/RbYK/1eb/9P51//D/+H/ZCPNvML/4f/etqEU/k/h//6IWmkV/m8jysP/ ZfR/owwMjf4ytjPqaRvuJ/F/C1H4vyX/17b9rcd0qwIi3ef/BtcdDpX6iPX/8H/f4/+mpkb/ N4z4P8oHlLv/Gw/MiPN/Rvxf/6Pwf8cXd5bj/+LHvfF/6a3C/yV0K873fyKFSqz/JyivjP+z 0mr8359Ri/5vbPrfameUHvy73lD5KPxfZNTS1eLd/w1uND/v+n8d/i9Dq/B/3+D/WP8P/+d/ C/+n8H9bdyD+LzEK/5fQKvxfYtSl/F/rD1H8X1QU/u8r/Z8SHYL/29Lp/Kf/81eNVP/XvkSt +L/WbynN/722qqb1/wr6v9X1/yQK//cehf8r4v9a+ZBy+j/TVej/zIj/i7xabPN/xnRuwvft wWB/72ySXw6V+0n8X9QOVOf5P3Wx9f/8fRf/9z70c2X/17ge09D3Jsn/DY/qev5PREMJ/xf+ lCL+T+7uJfxfuA/i//B/+D/830LUSqvwfxtRHv4vo/+z8nhgx4R+4NM2HlKuLv9nG/xflla9 +D899c7/df1k9kbp25HX/VZKfcL6f09HYD3+T16G1OX/2sZk93+2Od3/+QlFef1f1+H/KLHl 7v+mAzPi/F8r/m/4Ufi/44s7y/F/8ePe+L/0VuH/EroVpfxfc77/azX+72v8n+tmhmpnlJbF A0Plo/B/kVFLV4sS/m+w+L8MrcL/fYP/Y/0//J//rWf/Z/F/+L/1HYj/S4zC/yW0Cv+XGIX/ i2wW/u9e4f/wf3X7v+lR4f9WX6vj//B/S/7P4v+S/J87r/B/cVFP/q/tivm/zlzK/1nr1/+b hv29s3Hyez9U/sUc/i9mB6qt/s81Iav/c2seXMn/yYHwnf7PnVf4v6hWnef/TJX+T32A/xP4 h/9beOjB/xXxf6Fbm+T/5ttQCv+n8H9/RK20Cv+3EeXh/3L6P1nm2PrezF7/N9+G6+XW6P/G Dv+XpVUv/s80Te/9n3Q5d/o/Pf5Wt/8yTvi/LK3C/+H/HhX+j7KjBP+nj7R2cf6vE//X/Cj8 3/HFneX4v/hxb/xfeqvwfwndikL+z30d4or/k5kCJfzffbS/hP+T17n4v73+z410h2pnlB5k oukw/Y4Q4/8io5auFqz/l/COAv+XHoX/w/+9HRb1+T/W/8P/4f9eovB/+L+FH8P/fbL/66VX n9H/uQcE/F9iFP4vMWrF/8njFP5vi6c4bv2/MKjTvkRV5P/UNJ7u/9o2t/+7/eSK/5OX3Pi/ 9yjW//vW9f8erXq+LuH/tvm/wGwq83+3HbXk/0zXZ/d/bu2r0/1f6FSU8H9y2CT6v3CulvZ/ t6P4Uv5P5sDW5v98Lz2r/1PDiv8LPdAuxf/Nt+Fq/N/CDvwq/6fkQCjj/4LsLuD/GvlgSvi/ JkzQ8r3bY/2fvj8Uqf0PqBv9n9B4/N/CTaSZV/g/hf/7I2qlVfi/jSgP/5fT/8ntV6q9/m++ jUcU/g//t9CqZ/9n2ul2X3L+TzpOe/1f+1sp/104Z/s/M8ngd2X+zw/+4f+WJqlewP+NDf6P Elvu/k8fmBHn/3rxf+ZH4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n96xP/h/xajFv3f5LqIodoZ pQf/0i9UPgr/Fxm1dLUo4f96g//L0Cr83zf4Pz3h/1KjKvR/rP+H/8P/vUTh/9b8X9/h/zJF 4f/wf897EP+XHoX/236wX9z/sf7fhf3fiP/D//mf/zT/F+Af/m/hanGW/7NX8n/jaHL7P/fF nFfyf2FW2/H+r5vcc0de/3d7xsf/xbXqLP/nzqvT/V+Xwf/NtyGf1bn+r2nbBv+3cmvE/+H/ /njdqPB/0ddA/J9U+L+tUSutwv9tRHn4v4z+b5KVXacxwf89beNhX070f2a8fwPQ/qgX/9eN +L8srXrxf7czaXTjFp18SDv9n+vghUrh//B/+L8D/J8bt8D/USLL3f+ZAzPi/J8V/9f9KPzf 8cWd5fi/+HFv/F96q/B/Cd2KUv7PrPo/OR4K+D8TXt8X8X9+gBP/t2WG+aL/c4PVodoZpQc/ 0BEqH4X/i4xaulos+D+3cdb/2/KOAv+XHlWb/+sH/F9qVIX+j/X/8H/4v5eoWvxfI/NRM/q/ OcrD/+H/XqLwfykfFv4vPeoy/i/MjMb/7fZ/YVog/u816gr+b3X9P5mBhP97j8L/5fR/Wncf 4P98q/F/C4fF3P85ulGf/9PNuOj/hqHL7f/c1eJ0/xemXxb0f83s5eRu//d44V3I/93uwlfy f/75F/+3MPRzZf9n3MUvr/8b8X/f7/9E0uH//njdqNb9n/w2/g//h//D/y1ErbQK//fvx+6z /d/Q+2urTITbGfW0DfeTNfq/1uL/srTqxf8NruPi/F9r9kY5+Nf9Vu6/mPP9n70PuCZE4f9+ K/zf+f7PDaji/yiR5e7/2gMz4vzfIP7P/ij83/HFneX4v/hxb/xfeqvwfwndikL+z3WWruT/ rD9f8X9bZpgv+j83Ch2qnVFhmsF9toHC/+H/lluF/0uOwv/FnFf4v98K/7fi/9wEEvxfbBT+ L/PzAf4vcQfi/xKj8H9vUfg//B/+bzkK/5farEv5P/uodvu/1wm++L+3KPxfMf/nHhzxf1Gf 1Xnr/9ly/s/W6P8Cs7mG/2ubZszt/9x8H/xfzA5UG/3f6NBLVv/nDgv8X1yrzvJ/ztWW8n92 1f+1j2q3/2vnlTY1+j/W/8P/yUaaeYX/w/+9bUMp/J/C//0RtdIq/N9GlIf/y+j/rPWX26FJ iHrahvpdKa8u/3cXPfi/vP5vuj0Ne/8Xuko7/Z/+rdRnrP+H/8P/nev/dHb/N+L/KNHl7v+6 AzOi/F/biP/TPwr/d3xxZzn+L37cG/+X3ir8X0K3opT/Ux/g//wQe1b/Z/F/B/k/N2kzVDuj 9DBNj8pH4f8io5auFiX832Dxfxlahf/7Bv/XNvi/1Kj6/F9r8X/4v/UdiP9LjDrV//m5UVn9 nxnwf5mi8H+Z/Z/MBMzp/0yD/0uNwv8lRq34v9Ac/N9u/xc4E/7vNer5tfpoivm/R6sO93/j mv/r5OKK//u3/2st/u9r/J9a9X9hqkk+/9d1pfyfGYv5P3ewn+7//BGY0//dzuRF/2d0fv83 foL/k6MH/4f/m4GexqO92vyf52t5/V/bFvN/qsr1/9b9n5wMX+n/3BdpLPu/0PMr4v/kFC/h /8KzQBH/J5fjIv5PLngl/J98v0oZ/ydz+Ev4Pxn9S/N/820ohf9T+L8/olZahf/biPLwfzn9 n9xYrX8E2ev/5ttQla7/Nxj8X5ZWPfu/VvdDm9n/6XE63f8F+Feb//PvTPB/S5NU5/7PvajA /8VF4f8qLXf/1x+YEef/tPi/9kfh/44v7izH/8WPe+P/0luF/0voVhTyf+0nrP+X3/8p/N8h /m9o2ua32hl165+bR+Wj8H+RUUtXC/xfwjsK/F96VG3+j/X/8H/+t/B/Cv+3dQfi/xKj8H8J rcL/JUbh/yKbhf+7V/g//B/+T/17UPoC/k+3tsL1/9x3quH/4lqF//tW/7e+/t8X+7+C6/9d yv+579Gv0v/dlQj+7znqxf/dfhL/F9kq/B/+7/3VMP5P4f+2zE+9kP+zGv+H/8P/ZYlaaRX+ byPKw//l9H/SDqn2+r/5NtwP1ej/WP8v/W3j0vp/43DrW9S3/l8bhruSZo4aPa/wf9/j/8z5 /q/r8X+UDyh3/2cPzIjzf0b8X/+j8H/HF3eW4//ix73xf+mtwv8ldCtK+b/mA/zffbZtCf8n 02Lwf3v9n/vtUO2M0qOfDxcqH4X/i4xaulqU8H/jiP/L0Cr83zf4P9b/w//533r2fw3+D/+3 vgPxf4lRlfm/vsP/ZYrC/+H/nvcg/i89Cv+3/WC/uP8L3TM/I3av/3ubNLrs/8IM6m/0fyXX /yvn/9bX/wuHG/7vD//X4P/wf9KQp6ph/b/YHfhZ/q817q/N6//urXr/sPB/if7PXdnzrv9n zbX8n7/vlvB/vleW1f+ZpsP/xbXqPP83Xsv/SQeqjP+Tq0UR/yeXhiL+T6KK+L8wmuCjjl3/ Tx5BKvV/vkr0f+Pvux78n8L//StqpVX4v40oD/+X0f+F187WG6OdUU/bcL3cGv1fN57u/wT+ 1eX/WmNu3dq8/u9xWJzp/2TQpjL/1/h24P8WJql+mv9r3TGX1f/d7uT4P0psufu/4cCMOP/X iv8bfhT+7/jiznL8X/y4N/4vvVX4v4RuRSH/Z7oP8H8D/u9r/J8beQ7Vzig9yoOMVD4K/xcZ tXS1wP8lvKPA/6VH4f/wf2+HBf7vLQv/h//D/61G4f8SWoX/S4zC/0U2C/93r/B/+D/8n/r3 oPQF/F/J9f8erTrc/xn8X5L/c0Pt+L+oz+rZ/2nd4f8io1j/r4j/uzU3t/+z+L9v8X+38wf/ F9kq/F9W/6fN+f7P7Tn831LUB/q/YVZV4//CfbCE/zPNo8L//btvgf/D/61E4f/wfytRT42a PzLX4//k00nzf/Nt1Or/PmD9P/zfchT+b1bh//B/ftP4P8pHlLv/Gw/MiPN/nfd/rf5R+L/j izvL8X/x4974v/RW4f8SuhWF/J/7VufT/V8vE2bxf5/v//wmQrUz6nbIjY/KR+H/IqOWrhYL /k8mkGT0f5PF/2VoFf4P//faKvxfYhT+LzbqdQ/i/zLsQPxfYhT+L6FV+L/EqEv5P3kCy+n/ NP4P/7cYdbb/0/J1Q/i/LZ3O8/2fTFT8Tv9nmgr9nydRi/5vCHPL8X+vUaz/x/p/S0fgBfxf cyX/p42pcv0/+UOL+D8re6uA/+v7Fv+38bxa9n+jv1rU5v/cYZHX/2l7pfX/tDuJsvo/N+dx 2f9Jt/Y7/Z/rWyz7P7l1FvF/YQJECf8Xvj6kyPp/st0i6//dLafa/4C60f+NxfxfuByX8X/S nDT/N9uGUvg/hf/7I2qlVfi/jSgP/5fT/8nImTUJ18CnbbifrNH/DQb/l6VVL/7PwY3M/k+P 0wf4v35W1eL/5Hsg8H8Lj91P/k91Hf4vMgr/V2m5+7/pwIw4/9eL/2t/FP7v+OLOcvxf/Lg3 /i+9Vfi/hG7Fhfxfq/F/X+P/XDczVDujtLxiC5WPwv9FRi1dLfB/Ce8o8H/pUfg//N/bYYH/ e8vC/+H/8H+rUfi/hFbh/xKj8H+RzXr2fwr/h/9bjML/pTYL//fWqo/0f2pqi/k/M5y//h/+ b5P/Y/0//N91/F+d6//ZbtH/Ne5gz+v/OoP/O8b/WXfu5vV/7hS+jv8TTIb/Wxj6wf/l9H+6 w/99v/9r5XDD/+H/5oX1//B/+D/832rUU6Pmj8zV+L9BOmfDlBD1tA1V6fp/3Xi+/wvP2yYl 6u7VpXJjt6f6PzNNt4ce7/92Rzn41/xWsyj8X2b/Z3v83xb/p5sa/Z97Fsb/USJL8H/mSGsX 5/+s93+m+1H4v+OLO8vxf/Hj3vi/9Fbh/xK6FaX8n/kA/yej/UX83/3tNP7vz6hl/+eeXUO1 M0qP8sZwfLx5wf9FRi1dLd79X5/d/w34P/zfWlRt/q8f8H+pURX6P4v/w/+t70D8X2LUmf6v l+kIOf2fbvB/maLwf7n9n99d+L+oKPwf/u93SPVa/s8+qt3+bwXlvfq/WRT+b/0Q7Lti/m9c 9X/yWgT/92//11r8X5L/07rD/0VGPfm/rlnxf1Ob2/85vnYZ/2fGocnu/8YP8H9dWK+gKv83 uA8mr/8zw7X8X+urAv7Pd86y+r/bEVaj/9OmQv+nLrb+X1fO/4UjtMj6f/LBFPB/airo/+Rq UsL/ya0R/7fgKfB/vsL/bY1aaRX+byPKw//l9H9WZHeTcA182obvW1To/z5h/b8a/d8wtFNm /6etwf9laRX+b6f/M02F/s99bxH+jxJZ7v5PH5gR5/8G8X/2R+H/ji/uLMf/xY974//SW4X/ S+hWFPJ/7oHxbP9n/BA7/m/LYXG2//PMJlQ7o/TofyFUPgr/Fxm1dLVY8H/u3/F/W95R4P/S o2rzf6z/h//zv/Xk/9wyDvi/2Cj8X+bnA/xf4g7E/yVG4f/eor7N/8n0VPxfVBT+7yv9331y IP5vi6fA/0UdF0+v1f0L6EL+79Gqw/3f+vp/0mr837/9H+v/Jfq/Gcqryf/ZD1j/b2D9vxT/ Z/vs6//pT1j/L7wjxP/92/85U3Yl/ycHAv7vfejnyv6vy+//3FftLfs/uXDV5v+k/1LC/8ma 3WX8n5x3RfyfXI5L+D/TPKqD/Z9MjS7i/0L/pYj/k+ak+b/ZNpTC/yn83x9RK63C/21Eefi/ jP4v8JDB30F3Rj1tQ/2ulFeX/6tz/b8ZyjvJ/1l3d8/r/4y2H+D/ZNAG/3dF//droKvyf6z/ R9lR7v7PHJgR5f+6Rvyf/lH4v+OLO8vxf/Hj3vi/9Fbh/xK6FYX8X/sJ/i+8vsf/fYH/cyPE odoZpUc9Piofhf+LjFq6WpTwf7bD/2VoFf7vG/xf0+L/UqPq839tg//D/63vQPxfYhT+L6FV +L/EKPxfZLPwf/cK/4f/q9v/TY9qt/9r51Wd/q/pLuX/bJhbjv97jcL/ZfV/44D/i4zatv5f fv/3Aev/mclPqMzq/xzKW/J/TaXr/+H/Nq3/566BF/J//upbnf/zXaWs/s+NCBbyf6ar0P+5 Lufp/s+z0Kz+b1r1f/IwVcT/yWFTwv9J77eE/5MHbfzf0mHRPlWf4P9Y/w//h//LErXSKvzf Px67P8H/yT3RDgnXwKdtPKLq8n930YP/y+v/+rap0//Vuf6ffzbC/y1MUp37P13l+n/4P8qO cvd/7YEZcf7PiP/rfhT+7/jiznL8X/y4N/4vvVX4v4RuRSn/15zv/8JclZz+z+L/jvF//pkq VDuj9OifqULlo/B/kVFLVwv8X8I7CvxfelRt/o/1//B//ree/Z/F/+H/1ncg/i8xqjL/p/B/ yXcR/F/yDsT/5YrC/32p/5Ppefi/LZ4C/xd1XJzm/8yA/4vcgWf5PzfUjv+L+qwu4f9kUb7K 1v+r1f8Ny/5vsrn9nxtmwv/F7EC11f/ZKbP/c3Mer+T/6lz/76v9n/us6vN/I/4P/+d/tJlX +D/839s2lML/KfzfH1ErrcL/bUR5+L+c/k/aMfgL/F7/N9+GYv2/L/J/bjDh5PX/jHxvkbz6 2+n/BjdEGiqF/8P/4f8O8H/uG37wf5TIcvd/3YEZcf6vFf9nfxT+7/jiznL8X/y4N/4vvVX4 v4RuRSH/576U+Gz/Z/wQO+v/bTksTvd/Xf9b7YzSo59QFCofhf+LjFq6WuD/Et5R4P/So2rz f/2A/0uNqtD/dR3+D/+3ugPxf4lRZ/o/6zsXWf2fGfB/maLwf5n9n0xywv9FReH/8H+/Q6qX 8n9h1q2vdvu/1z244v/kf+L/vsD/hadE/N8f/u8BvfB/e/yf1h3+LzLq8/xfcEpV+b+xy+7/ PmL9v2HObPB/+D//j/i/z/N/2tTo/9bX/5OD/Tv9n1rzf32YknF/16qO839hYmoR/yfX1iL+ T07xEv4vdElL+L/GN6GI/5N5MWX8n31Uu/2fnVf4P4X/+yNqpVX4v40oD/+X0//J5dYvSL7b /8234Xq5+L+FKPzfov8b+lsH0Pk/uUzs9X/jb6U+wv+ZSQa/a/N//tDD/y1MUr2A/xvxf5To cvd//YEZcf6v9/6v1T8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/3NfsXe6/+vCbNsS/i+s4YP/ +zNq0f91bf9b7YzSo38BFSofhf+LjFq6Wrz7P3+KZ/V/XYP/y9Aq/N83+L+mxf+lRp3t/+yY 2/+5mW34v9go/F/m5wP8X+IOxP8lRuH/3qK+zv/5vxT/FxWF//tS/yePU/i/LZ5i2f/1j2q3 /5uDlFkU6//tOgTbsZT/805pef0/aXVd/s/Ks29O/2dZ/+9r1v97oLzn69JX+z8zLvs/3fTZ /d94Hf93Oy5dFzqv/9Mf4f9kB5fwf2EA9Sv9nzNlV/J//uqL/1sY+mH9vzL+L6xEXpv/k5ez JfxfH67sJfyfXCOL+L/QXfS922r8ny3o/2QyXRH/J0domv+bbUMp/J/C//0RtdIq/N9GlIf/ y+f/tO30o9oX9bwN90M1+r/Jnu//Gv/p5PR/uj3X/93um93tIfjWQZsGuzfKebTht1L4P/xf lP8zTW7/d7vwnO7/pvz+z72txf9R4srd/9kDM+L8nxX/1/4o/N/xxZ3l+L/4cW/8X3qr8H8J 3YpS/s+s+T/p+Bbxf0OYWI//+/OwON3/2f632hmlR78bQuWj8H+RUUtXiwX/5347q/8zI/4v Q6vwf9/g/9oG/5cadbr/M7n9n5vGif+LjcL/ZX4+wP8l7sBS/m+O8vB/+L+XqFP9n1xv8X9R Ufi/L/V/YWY0/m+3/5NmF/F/96+z9lvC/53v/1yrlv1fePbF/+H/ZuUA/9e2+L/IqLPW/3OT cJb9X7gcf6f/c1Hv6/81Q2/qXP+vRv83uvtZVv/nWOil/F/rq6/0f24tkUX/1zb4P/zfm/+T gx3/t7QD8X/4vy19C/wf/m8lCv+H/1uJemrU/JG5Gv/Xj/6x2zYJ/u9pG4+ouvyfbWr0fzOU d876f83t4LGug9bJfX+f/7Nj+1sp/B/+72T/133A+n/4P8pHlLv/Gw7MiPN/g/i//kfh/44v 7izH/8WPe+P/0luF/0voVhTyf+7R6nT/N8qEWfzfF/i/qf+tdkbp0b8RCJWPwv9FRi1dLRb8 n593mNP/9Qb/l6FV+D/832ur8H+JUYX8X9d0+D/83+oOxP8lRp3q//wUHfzflij831vU1/k/ /5fi/6Ki8H/4v98h1Wv5P9b/2+L/1DgW839aF/N/dtX/yb/j//7t/zrb4f/iPqsPXP9Pppjn 9H/GVOj/1tf/K+b/2sZHFfB/etBh/b9+/xE4TtPwqLwWPt//yaFXl/+bXHcM/7cYtc3/+QsT /m9h6Af/l9X/jav+Lww6fKX/s2v+r/MfTBH/J4u1FPF/cjyU8X/SkSji/+5CVe1/QN3q/2Sf FPF/8jhfxP/Jn5Lm/2bbUAr/p/B/f0SttAr/txHl4f/y+b9bZ8L/9tQmRD1tw/duK/R/g6nR /92eGs/1f9oOtw6gbm8f1bg3yhkn+1vNos70fzKhGP/314uKOv3feL7/G4bc/s+1Cv9HiSx3 /zcemBHl//pG/F/zo/B/xxd3luP/4se98X/prcL/JXQrCvm/bnX9Py1DgSX8Xxdm2xbwf4Nv Ff5vywzzJf/Xu8HqUO2M0qPM6hrb3x2I/4uMWrpaLPg/d7Bn9X9dg//L0Cr83zf4v6bF/6VG 1ef/3CQ6/F9sFP4v8/MB/i9xB5byf32H/8sUhf/L7P9EbuD/oqLwf/i/i/q/8VHt9n92XlXp /7TuL7X+n6xPgf97j3r2fw3+L8n/ad2V8n+6qdH/hSNQvZUD/J9Z83+h1TX5P9O5m2Fe//cR 6//182W2avF/o5spldX/3f7qK/m/ZpLhxq/0f+6zOt//dY9qt//r5tXp/s9MvtVZ/V+36v9k 4KI6/yd3jxL+L0xMLeL/pAkl/F+4D5bwf6Z5VMf6Pxt+u4T/C48HRfyffVS7/Z+dV/g/hf/7 I2qlVfi/jSgP/5fT/0kHXZ6+9/q/+TZcLxf/txCF/1vyf6btb5vQtwf7cXeUtlY3v5X6jPX/ xMTW5v/8lzPU5v90l9v/tbbB/0VG4f8qLXf/Nx2YEef/tPg/86Pwf8cXd5bj/+LHvfF/6a3C /yV0Kwr5v3Z1/b9y/q8N8yPwf1/g/8b+t9oZpcd2elQ+Cv8XGbV0tVjwfzL/Af+H/3sqTz+G /8P/LfwY/g//JwX/h//D/+32f2bA/2WKwv9l9n9yTcf/RUXh//B/v0Oq+D/3H/i/+Wt13ZlL rf8nHx3+7z0K/4f/WzoCT/J/Jdf/u5L/u11lDf7va/yfQy+s/7cYhf8r4/+GR7Xb/w3z6gP8 X+uu/Fn93+3ituL/grkp4P8av8ZYVv/XfoL/k1Mc//cF/k+6nNX5v/FR7fZ/47zC/yn83x9R K63C/21Eefi/nP5PbjKjf7jc6//m21CVrv93Fz34v6z+r22tX/+va3uzN0rbwT3DhUp9iP+T wW/83xX9n+k+wP9p/B/lA0rwf+2R1i7O/xnv/0z7o/B/xxd3luP/4se98X/prcL/JXQrSvm/ Zs3/ydyoIuv/yXLdOf2fxf8d4/9s1/9WO6P06N+ahspH4f8io5auFgv+TyaQ4P/wf0/l6cfw f2v+r23wf6lR9fk/N40T/xcbhf/L/HyA/0vcgfi/xCj831sU/g//h/9bjsL/pTbrfP8XphyX 8H9hquw3+j81jsX836NVh/u/9fX/ZJwC/4f/m5X8/k+NQyn/pzr8X5r/G1f9XxhOkP1ch/8z psP/fYv/m1x3LK//6zv8X2Sr8H/4v/dXwy/r/3Wr/m8+6LDX/7XzCv+H//Mbwf/h/9yP4v+W WoX/w//h/zL5v3DMjb7nuTPqaRuPqLr831014v/y+j/d3rqkuu3CR7bT/7nld0Mlz1f4vxyt wv/h/x4V/o+yo9z9nz4wI87/teL/+h+F/zu+uLMc/xc/7o3/S2/Vqf4vdJ7wf//2f66zdLr/ s/L6nvX/vsD/Df1vtTNKj/49R6h81Pn+b3704P9W/V9v8H8ZWoX/w/+9tgr/lxjF+n+xUa97 EP+XYQfi/xKj6vJ/7n0I/i9PFP4vs/+z/hDF/0VF4f/wf9f0f71+VLv937wvPYuqaf0/3Rfz f24Oydnr/4Up5vi/f/u/tsP/fcv6f+4LBBf9X3ufjZHP/80+q6eo/P4vCFT1Vkad2/+1tkr/ 5y63C/6vHbz/64MK2HUETo3vkoTqM/zf0zJbtfi/wY1kZfV/epwu5f9GP6Zawv9pP8kip/+7 Hcz4v7hWbfR/Zsru/27XwCv5Pxvmr9bl/6T3W8b/9Y9qt/+bP/Sodf/XPqrd/k/Pq1X/Z4v5 v3CZwP8p/N+8UcdF4f/wfytRT42aPzJX4/+sPCsPTUI/8Gkbrpdbo/9j/b/0t41L/s+4ToVu u8HujtLWz+MMlfqI9f8C/MP//fGi4nHDr8n/6fF8/2f9C+6s/q/r8H+U2HL3f+bAjDj/14n/ G34U/u/44s5y/F/8uDf+L71V+L+EbkUh/+c6Syv+T6RQCf8no9Cs/7fhsDjb/w1uE6HaGaVH f+iFyked7//CZ1mZ/3P/zvp/W95R4P/So/B/+L+3wwL/95aF/8P/4f9Wo+ryf2rU+L9MUfg/ /N/zHsT/pUfh/7Yf7Bf3f7OXx7v93ziv1v0f6/992vp/6/5PLq74v3/7P9b/S/R/M5SH/9vj /9bX/yvp/+Qvqsr/NYOfR9f3CXhoanxGqGTO49n+765E8H/PURdf/++r/Z/+BP83Pqrd/m+c V7dWne7/Wvwf/g//F3EK4//wf1uj8H/4v7WolVbh//792H22/xtkJHLwF/i96//Nt/GIwv99 vv+bobyT/F/Thu8tGuzeKG3Hafit1If4Pxn8xv9d0f/9Xi3wf/i/q5e7/2sPzIjzf733f63+ Ufi/44s7y/F/8ePe+L/0Vp3q/8KcbfzfF/i/3o9KFln/z8ocfvzfXv9n+99qZ5Qe/RfIh8pH 4f8io5auFvi/hHcU+L/0KPwf/u/tsMD/vWXh//B/+L/VKPxfQqvwf4lR+L/IZuH/7hX+D/+H /1P/HpTe6v9kouJX+r+S6/8V9H8N/g//53/+LP83DqX83+0nl/1f13+x/+vslfyfmXxzsvo/ 3S76P2Pb3P7vI9b/w/9tW/+vGa/k/2Tj+L+FoZ8r+z89VOn/fMclq/+7PR6c7v+kz47/++Oh R+H/jvJ/oVvrq73XwPk2lML/KfzfH1ErrcL/bUR5+L+M/i/wkMHfQfeu/zffhqp0/b97q/B/ ef2fHm+d9bz+zz0L4/9ytAr/t8//Vbr+361V+D9KZLn7v+7AjDj/Z8X/tT8K/3d8cWc5/i9+ 3Bv/l94q/F9Ct6KU/zOr/k+GAkv4v0beTuP/Pt//uQfGe7UzSo/+PUiofNT5/i/8Kfi/t0er blYpM+L/MrQK/4f/e20V/i8xqpD/c9M48X+xUfi/zM8H+L/EHVjK/9ke/5cpCv+X2f/JXG38 X1QU/g//9zukei3/J7MHi/g/+6i+zf9Vuv7fqv+zYW45/u81Cv+X0/9p3eH/IqOe/V/zCf5P dmhV/q+Z+ir9Xx+USAn/F7pKBfyf8xR51/9zpzD+L6pV+D/83/ur4a3+zw6zxlXj/+SwqW39 v9BnKeH/mir9nxxuZfyfPM7j//B/80YdF4X/w/+tRD01av7IXI3/G+SSLtXe9f/m23A/if9b iML/La//p3vt/V8Yndvp/+xvpT7E//Wzqh7/5x+08X8Lk1Sf/J853//5l2P4P8rZ5e7/+gMz 4vzfIP6v/1H4v+OLO8vxf/Hj3vi/9Fad6/+k1fi/f/u/7hP8X3hrgv/7Av/X97/Vzig9+tfK ofJR+L/IqKWrBf4v4R0F/i89Cv+H/3s7LPB/b1n4P/wf/m81qjL/1474v0xR+D/83/MexP+l R13E/92PAfzfFk+B/4s6Lk7zf2Yo5v8s/g//53/+JP9Xcv2/x2f1fF3C/+H/FvzfOFXp/8LU 9sr8n5uomNf/3e7C+L+4Vp3m/4RE/adeCv5vtVX4vzL+T4epTPg//N/8o6rU/5lHtdv/mXmF /1P4vz+iVlqF/9uI8vB/Gf2flZ6YHRL6gU/bcF0m/N9CFP5v2f+5pTe8/9sd5eBf/1vdfkZb /F+WVuH/dvq/D1j/D/9H+Yhy93/2wIwo/2cb8X/Nj8L/HV/cWY7/ix/3xv+ltwr/l9CtON// yfFQZP0/mZJVxP/J61z8317/N/a/1c4oPfbTo/JR+L/IqKWrxbv/a90Oxv9teUeB/0uPwv/h /94Oi+r8X9vh//B/6zsQ/5cYhf9LaBX+LzEK/xfZLPzfvcL/4f/q9n/SffPf27Tb/03zat3/ heHbb/R/WvfX8n8yToH/+7f/cyQK/xf1WZ3m/25//Yr/G7/Y/7Xdxfyf7MCM/k/ZRf/XDW1u /3dv1fuHVdD/3ZUI/u856uLr/4VxpXBe7fR//bzC/0VPMf88/6fr9H/+mMvp/9SA/4ts1aX9 n0xBx/8t3ETwf77C/22NWmkV/m8jysP/ZfR//eQvt7ZLuAY+bcNdk/F/C1Hp/s9M4SE4JerZ /7kvEzrX/3W33npm//c4LPB/mf2f75Xh/5YmqX6c/3MXP/wf5exy93/DgRlx/k+L/zM/Cv93 fHFnOf4vftwb/5feqnP9X3idi/97fbR68n/uPe3p/k+eXfF/Gw6Ls/3fpPvfameUHv0eD5WP wv9FRi1dLfB/Ce8o8H/pUbX5P93h/1Kj8H/vWfg//B/+bzUK/5fQKvxfYhT+L7JZ+L97hf/D /9Xt/4ZHdbT/s48K//fPQ7CU/2vwf0n+z33VHv4v6rN69n9uQOb09f/wf9v8X3Mh/3dLyu7/ 9Ces/1el/xtdVF7/N+pL+T9/Fy7j/yb83yb/5z6rc/3f6Jdbzev/zLX8n3wPchH/FybWl/B/ h8xPXfF/0pEo4v/kgof/2+3/uke12/918wr/p/B/f0SttAr/txHl4f9y+j/5dGwz7Y962sYj qi7/d1eNdfm/Gco7x/+Zqb09+LL+32IU/u+3+jL/Z/B/+D+KL3f/Nx6YEef/jPi/7kfh/44v 7izH/8WPe+P/0lt1rv87Yiox/i+yVdv8X+t/u4z/a6XV+L8/o5b9X9f/Vjuj9Og/hFD5KPxf ZNTS1WLB/7nfzur/3Psk/F9yq/B/3+D/7Ij/S43C/71n4f/wf/i/1Sj8X0Kr8H+JUZfyf53/ S/F/UVH4v6/0fypMr8D/bfEUrP8XdVw8+7/O1Oj/1tf/k7MI/4f/m5XvXv/v0arn69JX+7+u Yf2/yKvFtvX/TIv/S/N/d/hXwP9Z9zCQ1//13bX8n/c1+L/3oZ/r+r+2H9vc/s8f7Iv+LzyJ 1OX/lPQ1i/i/kFHC/8nM3jL+L3QXC/g/Hb5NyE9lqMb/yQKK+D+F/5s36rgo/B/+byXqqVHz R+Za/J/u/ZU9VPuinrfxiKrL/w0G/5elVS/r/93u47n93+2HTvd/ZpLB79r8n9xy8X8f7/+s 9S+4c/o/F4X/o0SWu/+bDsyI83+t+D/7o/B/xxd3luP/4se98X/prcL/JXQrSvm/Bv+H/1uM WvZ/buQ5VDuj9Oj3fqh8FP4vMmrpavHu/7rs6//h//B/q1GV+T833Qz/lxhVn/8zI/4P/7e+ A/F/iVGV+b85ysP/4f9eovB/KR8W/i89Cv+3/WC/tP+7z3nUKf6vneaV6Vj/LzLq+RB0sy3w f3H34bfZ7GX8nyNR+L+oz+q09f+ULef/7LL/a4321sCE2c07/d+cW7vvkF7yf9PkRl90E0jU vjt+K3uulXECF3Wy/2sbf/HL6/+aRf/X2D63/+vwf0f5P3fu5vV/7hqI/4tq1Tb/Z3r83yb/ p83Z/m/Iv/6fqtP/Wfwf/s9/CPg//N/WKPwf/m8taqVV+L9/PHZ/gv+b7KPa6//m23hE1eX/ xg7/l6VVr+v/uUmB+L/FqM/zfx7+Veb/ev9tTFn9nx85O9f/jf6VOv6PcnYJ/q870trF+b/O +z8z/Cj83/HFneX4v/hxb/xfeqvwfwndigv5Pz2E2bYl/F94F4T/+zNqyf+NjdtEqHZG6VG4 wmh/O7b4v8iopavFu//z5xX+b8s7CvxfelRl/s9NN8P/JUbV5/9Y/29Pq/B/mZ8P8H+JO3DZ /40yHzWj/zMD/i9TFP4P//e8B/F/6VGX8X8yPQ//t8VTFPJ/dnX9P/zfp/m/sVnzf9Jq/N+/ /R/r/+H/Ivyfm0Ti/h6rU97AzH759whUb2X0MsHoIeWOf8dizT3qdP/nJV0B/2emfsjt/+6t ev+w8H9p/m9097O8/m/Ul/J/Iv6+1P/ZNf9nv9n/qdPX/xubvqD/62aNO9b/+VtuVv/Xtsv+ T8ufUsb/yclQwv/Jo14R/xe2W8L/hYeiAv6vn2T3F/B/YaQR/6fwf/NGHReF/8P/rUQ9NWr+ yFyL/zPyBe2h2hf1vI1HVF3+rxtP93+t3Afr8n/D1A7e/8kz1V7/p38r/wSP/8vSqnf/10jV JUR9mv9r2zG3/3Pfs3ey/+t6/4I7p/8zHf6PEl3u/k8fmBHn/3pZ/0//KPzf8cWd5fi/+HFv /F96q/B/Cd2KQv7Pzeo42/+ZFv/3Nf7PdTNDtTNKy0i2vg9o4/++x/+ZDv+XoVX4v2/wf53G /6VG4f/es/B/+D/832pUZf6v7/B/maLwf/i/5z2I/0uPwv9tP9jxf6qQ/5v92G7/9zrBt5D/ U+NYo/8z+D/8n//5k/yfGodS/k+bD/B/Gv/3af7PXW4X1v/rdFvl+n9hajv+79/+z815vJL/ k17Zl/o/Vc7/2Sut/zdqjf/7Gv8na3bj//546FH4P/zfyzbeo+bNOiwK/4f/W4taaRX+7x+P 3ef7Pz36PpKeGr076nkbrpdbo/+7twr/l9X/tcbIuIXcz3f7v+a3coNIFv+XpVX4v33+zw09 4v/iovB/lZa7/zMHZsT5Pyv+r/1R+L/jizvL8X/x4974v/RW4f8SuhWl/J/5AP8nJxH+b8Nh cbb/066LGKqdUXqUhcyl8lH4v8iopavFgv9z/57V/7UW/5ehVfi/b/B/rP+H//O/9eT/ugb/ h/9b34H4v8Qo/F9Cq/B/iVHX8n9+w4Pc5vf6v2Fe4f/wf8tR5/s/eZzC/23xFIv+r8nh/8LU wr/8X/f4sdT1/37nPFbo/x6tOs//ybRm/N/CwY7/+07/p1bX/+uz+7+2Rv/X2gv5v9v96daX 1e3Qmv1H4KT9hxCqz/B/rP/H+n9L6//5MdUv9X8F1//D/x3m//SscbX4PzXKy9ki/k/+vYT/ C5eGEv6vKef/dHgoatX+B9T768Y//N/gt1vE/4VnjyL+T/49zf/NtqEU/k/h//6IWmkV/m8j ysP/5fN/apQ++2j3r//3vA31u1JeXf7PdDX6PzeYcPL6f92g3WDtZHdHaTu5Z7hQzaLwf9n9 X/eo8H9Pk1Tn/s9JuZP9Xzu6i9/tOSSMD+30f8OscuOB+D9KZLn7v/bAjDj/N4j/638U/u/4 4s5y/F/8uDf+L71V+L+EbkUh/3d7Sjvf/w34v6/xf27MOlQ7o/Qor1yl8lH4v8iopatFCf/X jfi/DK3C/32D/2P9P/yf/y3W/1P4v607EP+XGFWZ/xs1/i9TFP4P//e8B/F/6VH4v+0HO/5P FfJ/X7z+n9b9iv+7P1hKc77L/3kStej/Bjnc8H/4v1nJ7//cFzLh/+Kinvyfe9mD/3uLivB/ fbe4/p+2+L+v8X+DmyrL+n+LUfX7P23wf/g/2RnzqqD/cw/D+L+4bkwzr/B/Nfg/+6h2+z87 r/B/Cv/3R9RKq/B/G1Ee/i+j/5vkRZJUO6OetoH/U/i/7f6vbezt+uD8n9kd5eBf81sp1v/D /53s/9woJ/4vLgr/V2m5+7/uwIwo/3f7797/NT8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/3Nf lnC6/7NhfkSS/wuPAPi/Y/2fm7QZqp1RevQzo0Plo/B/kVFLVwv8X8I7CvxfelRt/o/1//B/ /ree/J8Z8X/4v/UdiP9LjKrL/7m5gfi/PFH4P/zf8x7E/6VHXcb/hZnR+L/d/k8eSDP6v25c 83+zH/s2/6emqZj/c3NIzl7/z4a55fi/t4N97v9ai/9j/T9pyLwq6P/sv/1fI524NP9nfw/2 Cv3f8vp/bac7/N+F/Z811/J//phL9H+hq/Qx6/8Zv4JKVv9nukv5v6Gc/+vkZJAL017/Z+bV J/g/GTEs4v96uTCV8H/hMl7E/8l9sIT/uz8UtWr/A2qY8/yH/7NyEyni/6TzVsb/SavT/N9s G0rh/xT+74+olVbh/zaiPPxfRv83SDtGfwPYGfW0Dd8PrND/3VUj/i+v/7s1qvf+T5u9UdpO 4/RbKfwf/g//h/+jfEa5+7/+wIw4/6fF/5kfhf87vrizHP8XP+6N/0tvFf4voVtRyP/p8Xz/ 1xr837f4P9P1v9XOKD2O7aPyUfi/yKilqwX+L+EdBf4vPao2/8f6f/g//1us/6fwf1t3IP4v Maou/8f6f/g//N/rn4T/w/8t/Bj+D/+n3n7s2/zf7RCr0P+p1fX/8H+b/B/r/yX6v4Lr/2lT zv9NNfq/zlzI/5luxP9d2P+5Z3z8X1yr8H+1+T+vhgr5v2Bu8H/4P/zfl/o/+6hY/28jysP/ 4f8WolZahf/7x2P3B/i/UYZQRr/y9M6op208ouryf63F/2Vp1bP/M/6Y020/jrujHPzrf6tZ q/B/+L+FVhXwf/Z8/ze4R1L8H+Xscvd/9sCMOP9nxP91Pwr/d3xxZzn+L37cG/+X3ir8X0K3 opT/M+f7PyPj4plRHv4vMWrZ/7nfDtXOKD3KO+tx/L0w4f8io5auFu/+r3NXi6z+z+D/8H9r Ufg//N/bYYH/e8vC/+H/8H+rUfi/hFbh/xKj8H+RzcL/3Sv8H/6vZv+nwrQbv+t2+z87r9b9 n7Qqzf+F8aPfOY/4v7eo7f5Pr67/J8O3+L+Fgx3/953r/637P7ma5PR/XY//i92Bn+X/mqlp qvR/gl3xf69Rr/7vdlhcyv/5+264syT6v9/PCv/3vgPxf/i/1M/qfP8nH0wB/xc0cRn/F66z rdr/gLrR/zX+sMD/LdxE8H++wv9tjVppFf5vI8rD/+Xzf1oe9UK1L+p5G4+ouvzf2OH/srTq 2f81w3D7rJz/a83eKG2nYfqt1Ges/ydvFqvzf0aqLiHqCv7vA9b/s+4Uz+r/NP6PEl/u/m84 MCPO/7Xi/+yPwv8dX9xZjv+LH/fG/6W3Cv+X0K24kP8LGg//t+GwONv/tU3/W+2M0uM4PCof hf+LjFq6Wiys/+eePrL6P/c+Cf+X3Cr8H/7vtVX4v8Qo/F9s1OsexP9l2IH4v8Qo/F9Cq/B/ iVH4v8hm4f/uFf4P/4f/U/8elMb/4f+2HIH4PxVzXuH/8H9LUfi/4/2fGiYj6/+ZhEk4k8zg CRX+b8fl9iz/d7vd4f8iW4X/y+r/3GdVn/+z+L/v93+HzE/F/8XtQPyfr/B/+L+lVuH/NqI8 /F9G/zf5CVqh2un/nrbxiDrT/8k4UJr/66QzEvzfxPp/B/i/W+/PDM7/dcNg90ZpO7rPKlQK /4f/O9n/uaHHk/1f12Zf/89F4f8okeXu/8YDM+L8X+f9X9f8KPzf8cWd5fi/+HFv/F96q/B/ Cd2KK/k/6Xbg/zYcFqf7v7b/rXZG6XGcHpWPwv9FRi1dLd79n39ywP9teUeB/0uPOtf/NTIx C/+H/5uVXr4eD/+3ZQ/i/zLsQPxfYtSp/s8vmYz/2xKF/3uL+jb/J7MC8X9RUfg//N/v0/Cl /N+Yw/+FN6J/+b/wYwX8n3yVVRH/18i/F/B/RmYJFPF/nZxFdfm/fpILBP5vr/+Tw62X3t9e /zfOqnX/J5NHSvi/VkhUCf83dP54KOH/hlEmEY4pU4vmd6BP8H9m8qOoWf2fbpf8nzXNrfG6 HZphf+9s0r6HEKrP8H9PzOZQ/ycj3mX8nzuF8X+LUdv8n3/+rc7/9e4Pzer/tLmS/9PuUpTX /7Vr/s9KP7CE/xsL+j/pnBXxf3KKl/B/4W1aCf83hq+LKOD/QhPS/F8Y4/u3/+tlnKyM/xNT U8T/hRtAkv+bbUMp/J/C//0RtdIq/N9GlIf/y+f/jPUdiVDti3rexiPqTP8nQyTGX5wT/Z9U n7D+nwmLiyX5v/sr4XAnb0/2f/3UN27cQkurdvo/P9AXKvUR/i/Av9r8nz+TavN/jcnu/8bT /V/fuCES/B/l7HL3f9OBGXH+rxf/Z34U/u/44s5y/F/8uDf+L71V+L+EbsWV/B/r/32P/7P9 b7UzSo9+Jl6ofBT+LzJq6Wrx5v/kOwrxf1veUeD/0qPwf/i/t8MC//eWhf/D/+H/VqPwfwmt wv8lRuH/IpuF/7tX+D/8H/5P/XtQGv+H/9tyBOL/VMx5hf/D/y1F4f8K+L/euNmBurU24WsR J+3X+QkV/m/H5Rb/h/9bOIXxf/i/fzwe4P/wf/g/Kfg//B/+D/+3GIX/y+v/WuMHLEK1L+p5 G48o/B/+b6FVz/6vm5rbX6SNDbOmdvm/fvTWSSqF/8P/xfg/09oa/Z91v43/o5xdgv/rj7R2 cf7Pev/Xtj8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/+s+wf/JeYX/23BYnO7/pv632hmlx6l9 VD4K/xcZtXS1wP8lvKPA/6VHner/tEzUw/9tibqQ/zP4P/wf/g//9xq16P96NxqtulbmBu71 f+Osuu0a/F+mKPxfXv/XyRMY/i8qCv+H//t9Gr6U/wsZ/qqx1/+F2cFteLu+6v9CTzBleuX7 /NQl/6cDkZMx1Z1ziZ8nY49m2f+pUZqQ0f+5OSRL/k+Ha3o+/3fb1Wv+T7Zbmf+zuf1f0FdX 8X+tnAy9fD47/V9jZtWtX77s/4Lwyuj//MG+6P+aMB6az/8Zs+b/3J9Sxv/1/jqb0f+19gP8 n7/QF/B/XT+0k8M1TcIRODVD+6g+w/+F12Ql/F+4iaT5v/BC6fHCe8n/WXfMZfV/t67lpfyf +JoS/k87hZ/X/7Vr/s9/VoX83/3bL1SC/5ttQz6rs/2f23gh/ydTzIv4P3/YlPF/0qMq4//k alHC/4VngSL+T5pQxP+FwZGUB9Q2PM384f9sK20L++BI/xfoRgn/N06Pau81cL4NpfB/Cv/3 R9RKq/B/G1Ee/i+j/7O+QxCqnf7vaRuPqFP9n3wwaf4vdPg/x/+FcY00/xfGh8Od/HT/Z/TY 3j6Be3P2+T//HBgq9SH+T6xmbf7Pd2vr8n96aGr0f5O7luP/KGeXu//TB2bE+b9B/F//o/B/ xxd3luP/4se98X/prcL/JXQr8H+RUfi/zI9Wi/6vM/1vtTNKj/4teah8FP4vMmrpavHu//wb TfzflncU+L/0KPwf/u/tsMD/vWXh//B/+L/VKPxfQqvwf4lR+L/IZuH/7hX+D/+H/1N/TK/E /+H/NhyB+D8Vc17h//B/S1H4vxL+T2v3Pfpt3zb7e2dT4/8tVPi/HZdb/B/+b+EUxv/h/5Zu jfg//N9fDz34P/zfyzbeo+bNOiwK/4f/W4taaRX+7x+P3R/g/yZZu29KWf/vaRuuO4j/W4jC /y35v3Zob/2XW3dpsrujdOeH3UKl8H/4vyj/13QV+j9r8H+UTyh3/2cOzIjxf8b9/1pro38U /u/44s5y/F/8uDf+L71V+L+EbsWF/N/90Qr/9wX+r+9/q51RevQ92lD5KPxfZNTS1eLd//kX Sfi/Le8o8H/pUef6v/Dwn8//qWnE/6VGne3/ujBHNJ//Mwb/h/9b34H4v8SoU/2fH0XN6v/m KA//h/97iTrT//WNfz2B/4uKwv/h/36fhq/l/+RPSfN/sus+yP+1Mwew2//ZedVOK/7PBkwm zcnh/x6tep7aZmTwIKf/e0i5F/8nv12b/5O9ldP/Ndfyf/eRQ79r9vk/FebLhWrUK/5PpsTk 9H+PVj1fl0JnNqf/m31WT1H95G+87ZRyb5TdcN8bXbfi/2RW23i/RSb5P5l71az5v+CUSvi/ flKZ/Z+Levd/fe9ezOm2GxLeVYyT7+aH6rdV7x9WQf8XprYX8X9yuJXwf+5xJ6//M9fyf3K1 KOL/3Pcx5fV/as3/+ftZVv/nRgT/6f9cler/Hi+8T/Z/Xsrl9X+6X/F/0q0t4v/8XbiI/9ON 3D1K+L8hyO4C/i+cr0X8n2y3iP/rHtVu/zfOqzX/Z8Nvl/B/3SRtL+D/pvZR7b0GzrehFP5P 4f/+iFppFf5vI8rD/+X0fwE/t/u/B+J5G66X+wH+T+70/kNK9X9hnmZzvv+Tdsj3P+32f3Ze zVDeOf6v18OtVbcHOSvDgvv8XzOa38r/0Af4v35WVeP//ChnZf6vse7bLfL6P3O+/2tl4/g/ yrnl7v/aAzPi/J8W/9f+KPzf8cWd5fi/+HFv/F96q/B/Cd0K/F9kFP4v86PVov/zc19DtTNK T/6XQ+Wj8H+RUUtXi3f/Z2UCCf4P//dUnn4M/7fm/wbW/4s+r94OC/zfWxb+D/+H/1uNwv8l tAr/lxh1Kf/X+h/A/0VF4f/wf79Pw/g/9x8H+D/7qHb7v9cJvsv+r5c5jxn9X98t+z8dZskX 8H8yKz+r/7P4vyT/Zzr8X5r/M8Oy/+tEZ5Xwf20jtw/837/9nzvYT/Z/beNxUQH/N7V68v7P JuChcfITu0J1+zDwf9/j/wb8X2Srtvk/Y4r5P2lHIf83Pard/m+aV9qc7P/c/N/s/s+urf/3 zf7v9pMf4P/mozbV+D+ZKov/W781/rYK/4f/+2fUvFHHReH/8H8rUU+Nmj8y1+L/wv/s5KFn X9TzNmr1f/dWnen/pANYlf8bp7af3HrukzZ7o7QI1FCpD1n/D//3Lf7PE7na/N8w9fg/ygeU u//rDsyI839G/F//o/B/xxd3luP/4se98X/prcL/JXQrCvm/1n6A/xut/Cn4vz8Pi9P9X9f/ Vjuj9OSXnQiVj8L/RUYtXS3e/Z9/u5PV/2mD/8vQKvzfN/g/1v/D//nfwv8p/N/WHYj/S4w6 1f/5LhP+b0sU/u8t6tv8n4xe4f+iovB/X+r/QnPwf3v93/17Ufyg9E7/F+ROGFZU+L/Y6+1Z /s9NW8b/xbWK9f+y+r+++wD/10urvtH/meZK6/+1t+NblfB/uhk78X9tn7L+Xz88KnfenO// ZL3agv7v/qiT5v9+T+FS/s+dwhfyf4K08H/vQz+n+T919vp/Zf3fIEdobf4v0PkC/i9MgCjh /+Q6W8b/hfX/fG9mr/8z82rV/zVyEpXwfxJVxv/J40ER/ze7Aez2f683Efyfwv/9K2qlVfi/ jSgP/5fP/7WDf5xvB9+32Ln+39M23GPj+f5POto5/d8c5eH/cvk/3XTWuvX/dC9/0U7/1w2/ lcL/4f+i/F83tiqz/xvP93+jO+ay+j83dov/o0SWu//rD8yI83+t+L/hR+H/ji/uLMf/xY97 4//SW4X/S+hWFPJ/7ntal/2fdHxL+L+2K+f/hvGAqCv5v6H/rXZG6cnPoQiVj8L/RUYtXS1K +D/L+n/4v7Wo2vwf6//h//xv4f8U/m/rDsT/JUad6f+s77Tg/7ZE4f/eor7N/8mDN/4vKgr/ h//7HVK9lP+7T19I8X/myf9ps+L/wpSSTsjBTv9n51VB/2eGFf/XBkwmzcnh/x5R+L8P93+s /1eD/7PF/N8o/k+H3brT/82vFm5mzKL/m/z+1JNMek+bWiSz/1xUff5PN+PS+n/jYLXzf+1k U/yf3+Oh8l/Mebr/K7f+333hv7T1/95eeC/5v6HXmf2fOyzwf3Gt2uj/Rvzfhdf/U6v+b5xV e/1fO68K+r9xzf+FFwyVrf9Xzv/dh3lK+L+C6//ZOv3f+Kh2+79xXuH/FP7vj6iVVuH/NqI8 /F9G/6etXBr0/qjnbbiRktP9X6vHR7XX/8mgbKhuP3m6/wuvhGvyf2rsbNv557kwOrfL/42u 0xAqJSPS+L8MrXrzf77Tp4emT4h6ehJ53PBP9H/u7UJt6/9Z/7yd1f+5AVX8HyWy3P2fPTAj zv913v+1+kfh/44v7izH/8WPe+P/0luF/0voVhTyf24wetn/yZFdZP0/+UYL/N+Gw+Js/2fd JkK1M0pPfmA+VD4K/xcZtXS1WPB/fmgop/8bO/xfhlbh//B/r63C/yVG4f9io173IP4vww7E /yVGVeb/zID/yxSF/8P/Pe9B/F96FP5v+8GO/1NZ/d8j6hL+72nooh7/JxdX/B/+b1a+2//Z Nf8nO7CI//N3DDOFydg7/d8cOaz6v7HP7f8cX1v2f+HF3Ff6v1tPfHH9v3boxf8lvBYZJ7/b Q+WvFqf7vz4wG/zfc9Tr+n+3w+JK/s9fJr7U/7luTIX+T11s/b9+1rhj/Z+/TOT0f/4l6rL/ k6lMlfk/uQaW8X9yilfm/2QKegn/p2VueRn/FzqASf5vtg2l8H8K//dH1Eqr8H8bUR7+L5// 06O//d5aY3dHPW9D/Uq5uvzfiP87wP/dnqvG2z381l3qfav2+j/Xgw6V+oz1/xr/p9Tm//yk 5dr8X2tbVZ3/64YW/0f5gHL3f8OBGXH+rxf/1/4o/N/xxZ3l+L/4cW/8X3qr8H8J3YpF/yfP Qzn9X/cB/i9oPPzfhsPidP9n+99qZ5Se/BuDUPko/F9k1NLVooT/Y/0//N9qVGX+T5se/5ca hf97z8L/4f/wf6tRlfm/vsP/ZYrC/2X2f4N/PYH/i4rC/+H/8H/4v6cHxyf/d7vl4//iot6O QPyfijmv8H95/Z9a83/y6Xyn/2ttMf/XmSv5v8nI+n+j3d87Gyd/zoXKv5jD/8XsQLXR/3Vu u3nX/2t7/F9kq/B/Wf3f+ev/tU2X3f8p/B/+z/9oM6/wf/i/t20ohf9T+L8/olZahf/biPLw f/n8n+m9UwrVvqjnbTyiTvR/Rvr0if5POiP4v0P9X9/fetC37tIojwc7/Z/r6YdK4f/wf/i/ bphy+z8Xhf+jRJa7/xsPzIjzf1b8X/+j8H/HF3eW4//ix73xf+mtwv8ldCvO93/yeF3C/3Xh BQ3+78/D4nT/N/W/1c4oPflXLqHyUfi/yKilq8W7/7PuaoH/2/KOAv+XHlWZ/1PTiP9LjcL/ vWfh//B/+L/VqDP9X+/mm+X1f7rB/2WKwv/h/573IP4vPeoq/u8+aIb/+wb/J39Kmv+TPVPe /7Vjhf7Pjf2s+L8wtxz/9xr15P/a5lL+r9NhUobfNcf6P5n7UGT9v2/2f25mzOn+L7T6O/2f k93v/u+249rc/s9ZzfP9n/x7Xf6vdxl51/9zp/CF/J/4mu/0f0qt+b/hm/2fOnv9v9vBbQv6 Pz1rXDX+L+irEv4vTIAo4v+kCQX8X5gqW8T/NXISFfB/vbSqjP+Tx/ki/m98VLv93ziv8H8K //dH1Eqr8H8bUR7+L6f/8zMKQrXX/8234X7ofP83Sn87zf/Jvgj+r7X4vyytevZ/enA3/Nsd PjzK7fJ/3Tjp32oWdar/C0dgXf7PfxtTZf7vdia1Kq//m93wT/J/utH4P8onlLv/mw7MiPN/ g/i/4Ufh/44v7izH/8WPe+P/0luF/0voVpTyf+YD/B/r/32N/xvcu5ZQ7Yy6PW7aR+Wj8H+R UUtXixL+bzD4vwytwv99g/8bNP4vNapC/zfi//B/6zsQ/5cYder6f34YOqv/U/i/5LsI/i95 B+L/ckXh//B/+L88/s9NV8H/pR2Cp6//J/N98H8LE3zxf/i/hSOwfv/n+Npl/J9pm+zr/7mr Bf4vZgeqjf5vcDs47/p/zYj/i2wV/q82/9eagv5vnFX4P/xf+OeA8vz1Cf/32f5velS7/d80 r/B/Cv/3R9RKq/B/G1Ee/i+j/2t938NIz3Sn/3vaxkPK1eX/uvED/N/4qHb7v9d3Zef6P9MM t6NHm3v/ZZf/67XrB4RKfcj6f/i/b/F/Lf5vk/9zr1/wf5TIEvyfPdLaRfk/rb3/M+ZH4f+O L+4sx//Fj3vj/9Jbhf9L6FYU8n/uPe2y/5PDooT/68KULJMyRz+8FVW/j1Yr/k9Lq/F/f0Yt +7+x/612RunJXzRD5aPwf5FRS1eLEv5P4//wf2tRtfm/gPLwfymHxcn+z/bZ/V/X4P/wf6s7 EP+XGIX/S2gV/i8xCv8X2Sz8373C/+H/avZ/Wu6KUu31fwFShKob1/zf+Kh2+z87rwr6P9vX uP6fWvN/chepzP/ZKbf/cw+O+L+4z+rZ/426mP9T5/s/gWCtnV3Gdvi/+TVwzf/pVlyIaVP8 n5Xz/76DVv1fuFS2oZG///0b/N/tCHz3f2pq2uD/mv29s3Hy/xYqvwPP93/N7CPF/635P3cX vpL/E6SF/3sf+rmy/+u6Cv2fnvwfmtX/dWbN/4loKOL/ws26hP+Tm1MR/xcmaPne7cH+L5xX Bfzf6M9X/N/CTQT/5yv839aolVbh/zaiPPxfRv9nfTcnVDv939M2HlGf4P/M/qhf/xcGfrrz /Z+etWq3/5t3W3+jzvJ/ty5Ff7vq3W7mU8L6f71/tgiVwv/h/6L83+i6nFn9nxvlPNf/3Z59 dW7/594e4P8okeXu//SBGXH+z4j/634U/u/44s5y/F/8uDf+L71V+L+EbkUp/9es+j/pzpdY /y+8Ncnn/9yXJSz7PytfxYz/2+n/RjeaH6qdUeFrhu/fNqzwf4f5P3/M5fR/psP/ZWgV/i+7 /zPyQi6j/7v17fB/qVH1+T/3jQn4v9go/F/m5wP8X+IOLOX/+g7/lykK/5fZ//V+w/i/qCj8 H/7vkv4vMBz838KD45P/e6C8ivyfHtf8Xy+twv/92/8FfYX/2+3/Cq7/t+r/5C5SZP0/W8r/ hfX/zH1S+07/F+5Av98rueL/AoKQ/Xyo//NDFgXW/2u6Qfxf6Env9H9+wYRQfYb/C2d0Xf7P ug8p7/p/bX8l/9f462wR/9d2xfxf1+L/Uvxf41fKy+r/3DVwxf/pWeO+zf+5I3DJ/6lJpvmU 8H9PozYH+z85Agv4v/tSGSX8330uWAH/J8dAEf8XvqkE/4f/mzfquCj8H/5vJeqpUfNH5mr8 n8zjNAK8d/q/p224a3KN/u++quGp/s8+qt3+b5pXZ/s/ZzJuz1+3O/zYmr1Ruptcc0KlPsL/ GekQVOf//IN2Zf6vx//h/yhHlbv/MwdmxPm/Vvyf/VH4v+OLO8vxf/Hj3vi/9Fbh/xK6FYX8 n+tW1Of/3GMw/i8xatn/Df1vtTNKT/4NUah8FP4vMmrpalHC/3Uj/i9Dq/B/+L/XVuH/EqMK +T83vIT/i43C/2V+PsD/Je7AUv7PDPi/TFH4v8z+Tw5R/F9UFP4P/4f/y+P/3MSO+vyfUyKF /N+jVfg//B/+T+0+2K/g/0b8X+TVYsv6f1pPwyD+r9vfOxsn/yGFyu/A0/1fmNqO/8P/VeP/ LP7vW/yf/6q96vyf+3Ji/F9cq/B/+L+lmwj+z1f4v61RK63C/21Eefi/jP6vk8ccqXb6v6dt PKLq8n/mA9b/C8/bJiVKugn36nT/pwfTaXeHt+PuKN35HnKo1Ef4vwD/8H9/PIk8bvj4v0/3 f65V+D9KZLn7v/bAjDj/13n/1zY/Cv93fHFnOf4vftwb/5feKvxfQreikP9zszpW/J8cDwX8 X3hgzOn/FP7vGP83Nf1vtTNKT/6DDpWPwv9FRi1dLRb8n8x/yOj/Wov/y9Aq/B/+77VV+L/E KPxfbNTrHsT/ZdiB+L/EKPxfQqvwf4lR+L/IZuH/7hX+D/+H/1N/zHnc6P/CxPmv9H8F1/8r 6P/Mqv+7Iwj5afwf/k+V9X/yWeH//rgGFlz/z0Wt+D/ZoXX5v6nP7f/UJ/i/8JHW5f8Gt+p5 Vv/nDotL+T/Xqm/1f6pK/6cN/m9hB+L/VvxfeJ8r1V7/Z+YV/u8g/2dNjf5PN82j2nkNfNqG Uvg/hf/7I2qlVfi/jSgP/5fR/8n1wWh/gd/p/5624QYmzvd/0qfP6f/mKA//l8//jWbo3M3c DGZvlANc3W+l8H/4v5P9X9uc7/+aNrv/G/F/lOhy93/dgRlx/q8X/2d+FP7v+OLOcvxf/Lg3 /i+9Vfi/hG5FIf/XfYD/a7vs/o/1/47yf66bGaqdUXpqm0flo/B/kVFLVwv8X8I7CvxfelRl /k9NBv+XGlWf//OTEvB/kVH4v8zPB/i/xB1Yyv/NUR7+D//3EnWm/7PyKgn/FxWF/8P//Q6p 4v/cf+D/nvxfwfX/HtTwPP9n5SzC/+H/ZuW7/Z/F/yX5v3+s/yc79Dv9n7uyv/u/22PjJP7P 7D8Cx8n/Qqh+W/X+YeH/Ps7/uVMY/xd3Ze/mVTn/p82a/5vwf/g//F/EDsT/4f+29C2W/Z95 VLv932wbSuH/FP7vj6iVVuH/NqI8/F9G/6dHd201pknwf0/bUL8r5dXl/z5i/b/uUe32f3pe ne7/TDfdruWh2hl1+4jcvJhQzaLwf/i/hVa9+r/BDaFk9X+zG35N/o/1/yjx5e7/+gMz4vyf Ff/X/Sj83/HFneX4v/hxb/xfeqvwfwndilL+z5zv/4yMbLL+34bD4nT/50a6Q7UzSk++txwq H4X/i4xaulq8+7/e/XZW/9eN+L8MrcL/fYH/Y/0//B/+D/8XuQPxf4lRlfk/1v/D//0jCv+X 8mHh/9Kj8H/bD/aL+7/QnAL+L8xA9DNtd/u/fl4V9H8XW//Phrnl+L+3gx3/l9P/ddP56//1 2f1fW6X/a6r0f8vr/5lp7HP7Pz1+gP+TOUVF/F+4Y4Rqp/97HfpZ9n/uwZz1/xajNvo/f/fA /70P/eD/svq/Zs3/yVdOVOf/pHNWwv8N4cJVwv/JzamA/7v3X0r4v0ZOogL+r5cJwEX8n5wM Jfzf3Wqm+L+nbSiF/1P4vz+iVlqF/9uI8vB/+fyfNoO7tmp5sNoX9bwNd00+3f+1jW9Hbf5P Ro2l2u3/2nnlhonP9X/jeOu/3G5U99G5Pf7Pdu7LOEKlWP/vQP/nj/K6/J8Zsq//N7vhn+X/ Oj1l93+s/0eJL3f/Zw/MiPN/g/g/+6Pwf8cXd5bj/+LHvfF/6a3C/yV0Kwr5PzebHf8XGXVd /zc1rosYqp1RevIv00Plo/B/kVFLV4sS/m8w+L8MrcL/fYH/Y/0//B/+D/8XuQPxf4lRlfm/ vsP/ZYrC/328/zMD/i81Cv+XGLXo/6TzjP9bjPo4/ydTbPF/fx2Cn7D+3yjjFJX5vxb/92n+ z5jz1//L7/9Ulf6vzvX/lv2fey+X2/85+4L/i9mBCv+nivg/7Sf4fqn/Uxb/d4T/6wY95vZ/ bs5jff7PH4H4v7huTDOv8H/4v7dtKIX/U/i/P6JWWoX/24jy8H/5/N/tDu8vt3ZKuAY+bcNP 0KrQ/9mmRv83Q3nn+L/bHarRrrK22xulbeeGxEKl8H/4v5P9n3tRcbL/a3v8H+UTyt3/DQdm RPk/04j/0z8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KU/2s+wP+Fd+pF/J88m+L/9vo/93YnVDuj 9ORPylD5KPxfZNTS1WLB//kJJPi/De8o8H/pUfg//N/bYVGd/3OT6PB/sVH4v8zPB/i/xB2I /0uMwv+9RX2Z/+vD3PyM/k+3+L/UKPxfYhT+LzZqm/8bQ3OS/F/o4v3l/8Ll7yv93+2WfyX/ J3OJ8X8LBzv+L6f/Gyz+LzLq2f+N//Z/jU6ZWnS/A8lnYS7k/8zQ69z+r2P9v4P8n3WPO1n9 n5vzeCn/1/rqK/2frnP9P9PV6P/MpfzfrT8mH2UB/xcmQJTwf1qOwCL+T07xIv4vRBXwf/J8 hf9bmyGN/8P/bY1aaRX+byPKw/9l9H+DjDlKtTPqaRuPKPwf/m+hVS/r/1kZt7hdJ8zeKAf/ ut9Kqd9VDc/0f/cjEP/37yeROv3f+AH+r83t/9wXquH/KJHl7v/GAzPi/J8W/9f+KPzf8cWd 5fi/+HFv/F96q/B/Cd2KC/m/VuP/vsb/9f1vtTNKT34+TKh8FP4vMmrpalHC/3Uj/i9Dq/B/ X+D/bn07/F9qFP7vPQv/h//D/61GVeb/zID/yxSF/8P/Pe9B/F96FP5v+8GO/1NZ/Z/pWP8v Muos/+dJFP4vqlVP/q+1+L80/9dNp/u/rg3joV/p//5Y/w//946HnvyfbsZF/2d1y/p/3+L/ egfBWP9vMQr/96X+7/T1//rblSi3//MHe33+T+H/8H/+5/F/+L+tUfg//N9a1Eqr8H//fuw+ 2f/drg/S25n2Rz1v4xFVl/9zw8T4vwytevF/fdt07kbVy+D3Tv/nn9Gk8k/w+L8srcL/fa3/ G/wxl9X/adb/o8SXu/+bDsyI839G/F//o/B/xxd3luP/4se98X/prcL/JXQrCvk/032A/wsP U/i/L/B/Y/9b7YzSUzs9Kh+F/4uMWrpaLPg/P/LM+n8b3lHg/9Kj8H/4v7fDoj7/13T4P/zf 6g7E/yVG4f8SWoX/S4zC/0U2C/93r/B/n+z/VJg0gv/b4ikW/V+YA+vnqaT6vzDLcs3/tTn8 X5jgW/P6f4+oo/2fXl3/r79P/JCfxv8t+z/34Ij/i/usNq7/Z7P7vwn/l+b/xg/wf62Mfx/v /yY9ZV//z3yA/wtvaMKdfqf/ex2PWfZ/YZiixPp/7mTI6//cKXwl/+fn/uP/3od+nv2fvZT/ mxz0wv8tRW1d/09EQxH/J/9exP/J3b2I/5Mju4T/C60q4f/kFK/T/0mV5v/uFf5P4f/+iFpp Ff5vI8rD/+Xzf2qQGQWDn424d/2/+TZ836JC/9eN+L8srXrxf6N76NGtMbbbG6Vt7x5yQ+W8 nD3d/5lRPqvK/J+fm4D/W5qkOvd/sxt+Rf6vw/9R4kvwf8OR1i7O/7Xe/xn7o/B/xxd3luP/ 4se98X/prcL/JXQrCvk/97UCFfo/i/87xv9p3f9WO6P0JA8yU/d7WOD/IqOWrhb4v4R3FPi/ 9KhT/V8bpjjl839ubiX+LzGqPv9nDP4P/7e+A/F/iVGV+b/bXQT/lycK/4f/e96D+L/0KPzf 9oP92v5vrnHy+L/Wnr7+X6vHWbVzLrGs3HGvCq7/p/X56//h/zb5P20v5f/6tplV+/yflqlk oXLn1YX83+QfQrL6v3HF/02j2/2mDaNYO/3fHWneW3UZ/3f7W7Ov/+c+q9P9n/yhtfk/97iT 1//dnvHxf3Gtwv9V5/8G/B/+7zL+r3tU+L9/9y2W/d/0qHb7v2le4f8U/u+PqJVW4f82ojz8 X0b/F2bASbUz6mkbj6gT/Z+RPn2i/5Pjtr+POOP/srTq2f/dOkq9u1EZrc3eKG171wcKlcL/ 4f9i/N/tKtGqvP6vtc3Z/q+12f2faxX+jxJZ7v5PH5gR5/86Wf+v+VH4v+OLO8vxf/Hj3vi/ 9Fbh/xK6FYX8X7fq/6TjW8L/mT7Mts3n/xT+7yD/5347VDuj9ORfcITKR+H/IqOWrhbv/s+/ OMjq/1qL/8vQKvxfdv9nRt8Ty7n+38j6f9Hn1dthUZ3/Y/2/Pa3C/2V+PsD/Je5A/F9iFP7v Lerb/J9MOMvp/5TF/6VG4f8So1b8X2gO/m+3/5N/L+L/ghL5Rv/nHhzr8396ff0/GafA//3b /11s/b/8/s9NLVr2fyJQc/q/ds3/mfDapC7/53e/CTP39vo/2VODDBib8/1f41VjTv93+/Ul /9dMtk7/F+bVlfB/Df7va/yfv5p8qf/z+mrR/9ns/q/F/x3k/8Y5X9vr/16f5Qr5Py9Ql/yf aeRhqoT/Cw8sRfyfXBqK+L9wsPvebT3+T/YJ/g//h//D/y1ErbQK//fvx+6T/Z9u/WU8VPui nrfhe7ef4v+ahLnLv/4vDBaw/t8R/q8Z9a0/e7tRDVOC/+vciE+o1Ef4vwD/avN/fpSzNv/X 2Fbl9X9+5Oxk/zfo3P7PReH/KJHl7v/MgRlx/q8X/2d+FP7v+OLOcvxf/Lg3/i+9Vfi/hG7F lfxfeKdewv+FbwbB/+30f6bpf6udUXrqhkflo/B/kVFLV4sS/o/1//B/q1GV+T83koX/S4zC /71n4f/wf/i/1Sj8X0Kr8H+JUfi/yGa9+L8G/5cahf9LjML/xUZt83/j/duYlcL/Pb9Wb2dV nf5Pra//h//D/xXwf9qaYv5Pne//xq6Y/xut+D+5Mu71f3I8DOHRqUr/51Z2XfB/1r2Yw/8t R32a/+tdRlb/5y9MF/J/ciDg/96Hfq7r/2433ym3/3PXwAv5Pz34D6aI/5MrEv5v4aEH/4f/ U/i/eaOOi8L/4f9Wop4aNX9krsX/3fpmsrKrv9zujHraBv5PfZH/c4MJ5/q/W9dicDeqNozO 7fN/bqZwqBT+D/8X4/9uF4tWZfZ/pkb/556F8X+UyHL3f+2BGXH+z4r/634U/u/44s5y/F/8 uDf+L71V+L+EbkUp/2dW/Z/0Jwr4Py0Pvvi/DYfF6f7PdTNDtTNKT/6XQ+Wj8H+RUUtXiwX/ 54+5nP7PvTzF/yW3Cv/3Bf6P9f/wfwv+r+3wf/i/9R2I/0uMwv8ltAr/lxiF/4tsFv7vXuH/ Ptr/yQMC/m9Lp3PF/0lUEf8XJs5/o//zUyCq8396df2/MKCM//u3/3MPjvi/qM/qvPX/Cvo/ W8z/tRb/F3m12OT/dDNO4v8S8NA4+Ut6qPB/Oy63G/2f6wjmXf/PXS3wf1Gtwv/h/95fDb/4 P4P/O8j/9eNsB+L/Ptn/2TDciP/D/+H/8H8LUSutwv/947H7A/yftf7CNegE//e0DfeTNfq/ 1uL/srTq2f/d+tm3dui2mbpub9TtGuOunKFS+D/839n+7wPW/7M9/o/yAeXu/7oDM+L83yD+ z/4o/N/xxZ3l+L/4cW/8X3qr8H8J3YpC/s+9Ej7b/4XXzvi/DYfF6f7PjXSHameUnsRkTI8J JPi/yKilq8WC/5P5D6z/h/97Kk8/hv/D/y38GP5vxf+x/t+eVuH/Mj8f4P8Sd2Ap/2cG/F+m KPxfZv8nHR38X1QU/u8r/Z++vzfF/32D/+sf1bH+z0y+1az/tzAFop1V+L/U9f8s/i9t/b/b eYX/i4t6Xv/P4P8irxbb/N806Nz+r20+wP+Fu3Bd/s+fUPi/xSj835f6P/dZVef/3OSEZf83 hInUnXx0u/rsH+j/ZCpTEf9nZzvwWP8XztcS/i/cB4v4v+FR7fZ/07xa83+9v0MV8n9iavB/ +L95o46Lwv/h/1ainho1f2SuyP/5/zk07f6op22o35Xy6vJ/rP+X/rZxyf9Nrlem22aYzN6o 2zXGPYKESn2I/5PPqjb/5w6b2vzf6E4G/N9SFP6Pklru/q8/MCPK/7Va/J/5Ufi/44s7y/F/ 8ePe+L/0VuH/EroVpfxfs+b/ZJcV8X8y4F3E/8kwPv5vywzzJf/Xui5iqHZG6cmfc6HyUfi/ yKilq8WC/3OtYv2/Le8o8H/pUef6P3m9j//bEoX/ixsdwf/h/7buQPxfYlRl/o/1//B//4g6 1//54w3/FxWF//tS/yejt/i/LZ5i2f/Jn1LE/4XLX2X+T/79K/2fd0rL/i/MLcf/vR3sc//H +n9f5P9sOf+nPmb9P92GJXJT/J+sR1Cp/7s9zC34P6O7Prf/u7fq/cMq6f/kLlyZ/3OHW17/ dzssruT/BL3U5v/8t2Vm9X+6x/9FRW1e/6+c/xv9LT6n/3Nr9Jzu/8b5DsT/fbT/k452Ef83 4P/wf/i/5MMC/4f/e2/Vmv/zt8NE/xdGOe8r5eH/cvs/GR/O6f90e7L/M9qYyfu/ptsbdbvG uN5CqPwTPP4vS6ve/J+8DMH/LUxSffJ/Bv+H/6P4cvd/9sCMOP9nxP91Pwr/d3xxZzn+L37c G/+X3ir8X0K3opD/M90H+D95dYX/23BYnO7/3LuWUO2M0pP81tT/7kD8X2TU0tWihP8bO/xf hlbh/77B/1mD/0uNwv+9Z+H/8H/4v9Uo/F9Cq/B/iVH4v8hm4f/uFf7vk/2fmmR6Hv5vi6fA /0UdF8/+7/bgWMr/tSP+L3IHsv7ft/q/23lV4fp/5fxfOALVW8nv/1pbpf9bXv/PdE2b2//5 bzE/2//JH4r/e4168X+6GfF/ka06y/9pU87/Kdb/+3r/N/nPIKv/Ux+w/l+l/q9/VLv939ND zwf4P6vxf/g//F+WqJVW4f82ojz8X0b/N8jTjlQ7o5624X4S/7cQhf9b9H+tu7vrtumT1v/z E6CkUqz/h//D/7W+j5TX/xn8HyW63P3fcGBGnP9rxf/ZH4X/O764sxz/Fz/ujf9LbxX+L6Fb Ucj/6XHN/8lhUcT/tWG2Lf7vz8PidP/nJm2GameUnvxRHCofhf+LjFq6Wiz4Pz/vMKf/Gwz+ L0Or8H/4v9dW4f8So/B/sVGvexD/l2EH4v8So/B/Ca3C/yVG4f8im4X/u1f4P/xf1f4vvDX2 l6O9/i8M8oVKdWv+r39UX+f/Cq7/V87/uYnzK/5Ptov/+7f/Y/2/RP/nphad7v+aMB76lf6v wf9FXi22+b+pz77+30f4vy68JpMo/N+K/7va+n/+Gvil/k8VXP+voP/T5lL+L0COyvyf3N2L +L+AyYr4P7k5lfB/TTjYS/g/+WBK+D+ZrFLE/3UyPQD/h/+bN+q4KPwf/m8l6qlR80fmevyf zICTaq//m2/jEVWX/xtMjf5vhvJO8n/jMLXuRmXl0Nvn/zr3YBUqhf870P/5oxz/tzBJde7/ 2qZK/8f6f5T4cvd/44EZcf6v8/6va34U/u/44s5y/F/8uDf+L71V+L+EbkUp/2c+wP/JQC3+ b8Nhcbb/69x0jlDtjNKTf1IMlY/C/0VGLV0tFvyfe/rA/215R4H/S4+qzf+NE/4vNao+/+em ceL/YqPwf5mfD/B/iTsQ/5cYhf97i8L/4f/wf8tR5/u/MDMa/4f/mxXW/9vo/8Y1/2fndAP/ h/+Tf/7q9f/smv+zYTwU//cadQX/d3uYW/R/Q/71/8y1/F87R+TH+j93MuT1f6PG/0W26grr /9lr+b8W/7dp1q3F/1Xg/4ZHhf/7d98C/4f/W4nC/+H/VqKeGjV/ZK7G/00y5ijVzqinbTyi 6vJ/da7/90H+bzB7o9yydNNvpT7E//Wzqhr/5/uJ+L+Fx+4n/2e6Gv2fU434P0pkufu/6cCM OP/Xi/8zPwr/d3xxZzn+L37cG/+X3ir8X0K3opD/69bX/5PB6CLr//leUhn/F94F4f/+jFr2 f+63Q7UzSk9+t4fKR+H/IqOWrhYL/s+PPOf0f+7VFf4vuVX4v2/wf6z/h//zv4X/U/i/rTsQ /5cYVZn/a0f8X6Yo/B/+73kP4v/So/B/2w/2i/s/+VPS/J/suj/9X5g4/5X+r+T6f20p/+dJ 1KL/k4kf+L+FCb5P/s+M+L+4zwr/V9T/NeK9Ev2fRI1V+r+V9f+s1XWu/3c/GXwU/g//5/6x kQfFL/V/Y5X+z3QV+j+HyJf9Xz/MGrfX/7XzqqD/U2v+L1yRSvg/KzuwhP8LU6SK+L+A8kr4 PzncavN/MoO6iP8LN4Ak/zfbhlL4P4X/+yNqpVX4v40oD/+X0f8N0nEZxgT/97SNh5Sry//d eren+z8ZNa7L//XD7cnU+T/b7Y1y8G/8rRT+7zj/J91a/N/CJNW5/3NPjfi/uCj8X6Ul+L/x SGsX5/+s939t+6Pwf8cXd5bj/+LHvfF/6a3C/yV0K0r5v/X1/+R4KOH/ZDwd/7fhsDjb//Vu E6HaGaUn4QqT/R2Iwf9FRi1dLRb8n/t31v/b8o4C/5cehf/D/70dFtX5v87i//B/6zsQ/5cY hf9LaBX+LzHqUv4vXPbwf/i/1ah6/F9oDv5vr//rcqz/J128v/xfmIGY5v/Ch1Xz+n/KFlv/ z6z5v2FON/B/a/6v6/B/af5vnPB/kVFn+b/19f+CU/pO/7ey/l9nhir9n/yhtfk/d7jh/xaj Nvk/mfTwrf6P9f++x/81+D/8n+yaefUR/m94VAf7P7l7VOf/WP8P/4f/yxK10ir8378fu0/3 f/J4IO9f9vq/+TZcL7dG/3dv1Zn+L4widClRYz+vzvd/bX97mHL+Tz6kvf7P/lb+Cf4D/J98 VpX5P79d/N/SJNUn/9d1Nfo/i/+jRJe7/9MHZsT5v0H8X/+j8H/HF3eW4//ix73xf+mtwv8l dCsK+T83xH66/wvdtyL+T54M8H97/Z/tf6udUXoa9KPyUfi/yKilq8W7//MvFrL6v7HD/2Vo Ff4P//faKvxfYhT+LzbqdQ/i/zLsQPxfYlRl/k9r/F+mKPwf/u95D+L/0qPwf9sP9ov7P3mb 6QfPdvu/8Fo9PHnj/2Kvtx/o/+S1CP7v3/6vHfF/Sf7PfbV4Kf+nyvk/i/9buLJ/k/9r2+Z2 tdC3i227/wgcJzs9KvzfjsvtWev/eZh8Jf8nw434v8/xf+6zqs7/uS8nrtD/Wfwf/s///Cb/ NzT4P/wf/i9L1Eqr8H8bUR7+L6f/kw6BVHv933wbj6i6/N99RS/8X1b/1xrTuRtVp5/6gZH+ bxja30p9xvp/jRyB+L8r+r/ZDb8i/+eehfF/lMhy93/mwIwo/9c14v+aH4X/O764sxz/Fz/u jf9LbxX+L6FbcSX/J2/J8H8bDouz/Z91XcRQ7YzSk58wFCofhf+LjFq6WpTwf6z/h/9bjcL/ 4f/eDov6/F+D/8P/re9A/F9iFP4voVX4v8SoS/k/uQzh/6Ki8H/f6f9GuY7j/7Z4ikX/F6YF Jvm/AFKMeYl68X/hxWma/+vnFf4P/ycbeZvNjv+LOoVZ/w//txD15P86s+b/wou5mvyfmdyh h/9bjqrf/91+6FL+T5AW/u996If1/7Ku/2fX/F8YW8P/fYH/C5f0Ev4vbLeE/zPNo9r7gPr0 ulHh/6Kvgfg/qfB/W6NWWoX/24jy8H8Z/Z+VAYvBD0jujHrahvtJ/N9CFP5vcf2/cegHN24R Dr2d/s89WIVK4f/wf1H+b3JDKFn9n3vCx//FReH/Ki13/9cemBHn/7T4P/Oj8H/HF3eW4//i x73xf+mtwv8ldCsK+T/TfYD/a+SNZwn/Jy9X8X9bZpgv+j/3/BuqnVF6kleuUvko/F9k1NLV Av+X8I4C/5cehf/D/70dFvi/tyz8H/4P/7cadar/82dSVv83R3n4P/zfSxT+L+XDwv+lR+H/ th/s1/Z/dw6Q4v/CNPU//V//qPB/64dg25byf94pLfo/G+aW4/9eo/B/1fk/OfSq9H96Ctev NP/nt/ER/s9vN6v/a4dF/9eNukr/F5bZqsz/uccd/N9i1AX837jm/3R2/9fi//B/fl+8zrq9 kv87ZH7qhfyflaMc/7dwE8H/+Qr/tzVqpVX4v40oD/+X0/9J581O4/6op22oSv3fvVX4v7z+ 79ZFst7/yYe00/+5Ll2oFP7vOP/nn9vwf0uTVOf+71cL1+X/RvwfJbrc/V93YEac/zPi/7of hf87vrizHP8XP+6N/0tvFf4voVtRyP+51yGn+z/pYxfxf/Lohf/bMsN80f+5HRiqnVF6GqZH 5aPwf5FRS1eLBf8n33+c0f+NHf4vQ6vwf9/g/8YJ/5cahf97z8L/4f/wf6tRlfm/vsP/ZYrC /+H/nvcg/i89Cv+3/WC/tv/rA1gp4P/aMLv5K/1f21e4/t+6/5PDAv/3HoX/w/8tHYFPExG7 7lL+795q2c9f5v90s+T/2qZt8X/X9X/uho//i2sV/g//9/5qGP+n8H9b5qfi/+J2IP7PV/g/ /N9Sq/B/G1Ee/i+j/+tlSNq2Cf7vaRuuy1Sj/+tG/F+WVr34v8k97Tj/15q9UQ7+db+V2zUj /i9Lq/B/+/yfbrrT/V834P8oH1Du/q8/MCPO/7Xi/+yPwv8dX9xZjv+LH/fG/6W3Cv+X0K0o 5f/MB/i/8Poe//f5/m/Q/W+1M0pPvp8eKh+F/4uMWrpa4P8S3lHg/9KjavN/rP+H//O/hf9T +L+tOxD/lxiF/0toFf4vMQr/F9ks/N+9wv/h/6r2f10G/xf60n/6v9DpTPJ/4cNi/b8c/s+N FK/4P3ktgv/D/83Kd/s/hf9L8n+OblzG/xk7Dbn9n7vc4v9iduBCVKn1/9zV4kr+z/fKvtT/ Gfzft/g/0635v8DX6vJ/KvRfivi/0JwC/k8ufmX8n9wHS/g/fZ8+o/Y/oG70f3I1KeL/5Eml jP+b3QB2+7/Xmwj+T+H//hW10ir830aUh//L6P/s6C+3gz+h9q7/N9/GQ8rV5f/uqhH/l9f/ WffdAs7/yePBXv9nfiv1Iev/hSH9uvyff0DF/y08dn/c+n+teyDI6v9ud3L8HyW23P2fPTAj zv913v91zY/C/x1f3FmO/4sf98b/pbcK/5fQrSjk/7pP8H/hG09L+L8hfLEg/u/PqGX/50ae Q7UzSk+jfVQ+Cv8XGbV0tVjwf65VWf3fYPB/GVqF//sC/+dGsvB/iVH1+b+2w//h/9Z3IP4v MQr/l9Aq/F9i1KX8n4wj4P+iovB/+L/fIdVr+b/QiS7h/8LE+ST/Nx8/mkUd7v+GtkL/p1bX /7Nhbjn+7zXq0v6v8YdNTv9nzYr/k4nz+L+Fq0WU/zOByCT5v/DotOr/wnCC7Oc6/F8/1rn+ X8BFJfxfGKb4Tv9nL7X+X+Mn+Fbn//zxkNX/6b6Y/3Of1bn+b9R9bv/nbiLL/i9M+K3N/4lo KOH/BjlsSvg/6f0W8X9NONhL+D853GRO9s4H1LDIfft7Ci/7P+lBl/F/sreK+D+5yUwJ9uVp G0rh/xT+74+olVbh/zaiPPxfTv8nN1aZo7DX/8234X6yRv/H+n/pbxuX/F9/e4jz/i90lXb6 P/1bqQ/xf/JZ1eb//C0X/7cwSRX/h/+jLJS7/xsOzIjzf734P/Oj8H/HF3eW4//ix73xf+mt wv8ldCsK+T/3Pa1n+79WerT4vw2Hxdn+b3SbCNXOKD0JSJvG34EY/F9k1NLVYsH/+XmH+L8N 7yjwf+lRlfk/1v/D/y34v87i//B/6zsQ/5cYhf9LaBX+LzEK/xfZLPzfvcL/4f+q9n9hNkaa /5Mt/un/5N/T/J80p7z/62wx/6eH89f/k48O/7cwwRf/l9P/6bX1//L7P1vO/80+q6eo/P6v 7Yr5v3+s/1eh/xv77P5P4/+O8n/uZMjq/9ycx0v5v9Z/Yvi/z/F/56//V9b/dbPGfZv/s2v+ T1Y1LOL/wvvcIv4vTOVPGbjY6v+kI1HE/w2P6mD/J73fIv5PPuky/s8+qt3+z84r/J/C//0R tdIq/N9GlIf/y+n/5E5vpxT/N9+GqnT9v0/wfzLc1Yb5JDv93zivzvd/YztM4v92Rzn41/xW syj8X3b/549y/N/CJFX8H/6PslDu/m88MCPO/1nxf92Pwv8dX9xZjv+LH/fG/6W3Cv+X0K24 kP8zfRjtL+H/Wmk1/u/PqGX/57qZodoZpSc/eh0qH4X/i4xaulos+D8/gQT/t+EdBf4vPao2 /9f2+L/UqAr9X4P/w/+t70D8X2IU/i+hVfi/xCj8X2Sz8H/3Cv+H/8P/qX8PSsf5Pz9/PtX/ vbaqpvX/uq6Y/xvxf2n+z+D/kvyfaRr8X2TUWev//cP/yWXiO/1fOyz7v6mvcv0/+UPxf69R r+v/3Z7xL+X//Nx//N/70A/r/+X0f+4msuL/2lnj6vF/cveozf/JeVfE/0lUZev/yd2jjP+T jjbr/+H/5o06Lgr/h/9biXpq1PyRuRr/N8h9UKqdUU/beETV5f9a+wH+zz6q3f5vmldmON3/ 6anJ7P8+Yv0/2W5t/k+ejfB/C5NU8X/4P8pCufu/6cCMOP83iP+zPwr/d3xxZzn+L37cG/+X 3qpT/V/oPOH//vB/zQf4P/99kvi/LYfF6f7PdWxDtTNKTzLRdJp+R4jP93/zowf/h/9baBX+ 72L+j/X/8H/+t578n/sSffxfbBT+L/PzAf4vcQeW8n9mwP9lisL/4f+e9yD+Lz3qIv5P39+b 4v92+z95m4n/+8P/3R4cV/yfHA9fuf6fJ1GL/m+Qswj/94f/Y/2/xPX/+qGU/3NKBP8XF/Xk /zpzIf93S6rT/4Wp7VLt9X9vb8vO9n/ucQf/txi10f/5uwf+733oh/X/yvi/MLaG/8P/4f8y +r+xoP+bzW7e7f/mM6QV/k/h//6IWmkV/m8jysP/5fR/MiQ9+JvsXv8334aqdP0/0+H/srTq xf9NdujxfyuD3/i/e/Vd/s894Vfo/wz+jxJdgv+bjrR2Uf6vb7z/a5sfhf87vrizHP8XP+6N /0tvFf4voVtRyP+Z7nz/10qPtoz/k8k++L+d/m9yb3dCtTNKT36eRqh81Pn+L3yWlfk/9+/4 vy3vKPB/6VG1+b9xwv+lRtXn/1j/b0+r8H+Znw/wf4k7sJT/GzX+L1MU/g//97wH8X/pUZfx fzJ6i//b4ikW/V8XRs2S/F/QC3/5v/ZR1eP/woNlRv/3aNXR/s+TKPxfVKvwf1/q/2atwv/t 8X//WP8vTFSU/Xyo//MHcVb/56KW/F875fZ/bgfi/2J2oML/qSL+T+xLbf6v9X9KVv+nBvxf VNSr/2vW/N8TX9vr/1470qX8n7qW/ztkfur5/m94VMf6v6HB/+H/8H9ZolZahf/biPLwfzn9 32ge1V7/N9+G+l0pry7/d1eNdfm/vjvd/7m+hW7bye6O0nZw3eFQqQ/xf/LEh/+7ov9TrP+H /6NIufs/fWBGnP/T4v/Mj8L/HV/cWY7/ix/3xv+ltwr/l9CtKOT/9Ljm/6TjW8T/Sd8vp/+z +L+D/N/Y/1Y7o7TMqQmVjzrf/4VTvIT/mx+ouaKW/Z9/0ZfV/3Uj/i9Dq/B/+L/XVuH/EqNY /y826nUP4v8y7ED8X2IU/i+hVfi/xCj8X2Sznv2fGfB/qVH4v8Qo/F9sFP4vp/8b2mL+z5y/ /t/dbOD/8H+zgv/7OP/nhi5OX/8vOKWa/J9pe9b/+x7/5w63rP7v9lfj/yJbhf/D/72/Gt66 /l9B/+czcvo/fwTi/+K6Mc28wv/h/962oRT+T+H//ohaaRX+byPKw//l9H+2eVR7/d98G4+o uvzfXfTg//L6P2Mb7f1f1+2NcvCv/a0U/g//h/9j/T/KZ5S7/zMHZsT5PyP+r/tR+L/jizvL 8X/x4974v/RWner/wjwT/N8f/s+c7/9uvT9XlVn/TwZq8X+7/F97u503v9XOKNP4Ae1Q+Sj8 X2IU/i8yCv93r/B/a/5vaPF/qVH1+T/W/9vTKvxf5ucD/F/iDsT/JUbh/96i8H/4P/zfctTZ /k/JKBP+b0unc9n/hYmKvfux3f5P/lw9vES9+j/5Md/33O3/3uanlvF/pmmK+T+tz/d/wWng //B/s/Ld/s/W6P/W1/+TqUXjlIKH7neg8A2LV/J/dmhz+z91sfX/nhD5l/k/fwpfyP/JgYD/ ex/6Oc3/uc8K/5f2LFfI/7krO/4vrlX4P/zfXzOkFf5P4f/+iFppFf5vI8rD/2X0f1b6idY/ du+MetqG+0n830IU/m/R/9n+dgV3/i8MBO70f+a3mkXh//B/C6063v+5J3z8X1wU/q/Scvd/ 7YEZcf6vFf9nfxT+7/jiznL8X/y4N/4vvVX4v4RuRSH/54bYz/Z/rbyQwP9tOCxO93/uPUio dkaZxj/BhMpH4f8So1b8nz/m8H8b3lHg/9Kj8H/4v7fDAv/3loX/w//h/1ajKvN/fYf/yxSF /8P/Pe9B/F96FP5v+8GO/1P4v6XX6u2sKrn+XzuW8n/utTr+L65V+L+s/q9tSvk/f7AX8n8W /7dwZf8q/zf0Q27/1zYf4P8CRazM/7nHnbz+b9SX8n9hXCmcVzv9Xz+v8H/RU8w/zv9NU27/ 5w92/F/aZ4X/U1G9W/wf/s/9KP5vqVX4P/wf/i+T/xulVzb6rtLOqKdtuBt6jf6vG/F/WVr1 6v9G3Wb2f6z/h//D/1n/gjun/3NR+D9KZLn7v+7AjDj/13n/1zU/Cv93fHFnOf4vftwb/5fe qnP9X5gfgf97fbTa6P+0zOwp4f/CxHr83+f7P7+JUO2MMk0YGWh+B2Iu5f/aA6JW/J8fec7p /1qL/8vQKvwf/u+1Vfi/xCj8X2zU6x7E/2XYgfi/xCj8X0Kr8H+JUZfyf4M/vnP6P3fLx/+l ReH/EqNW/F9oDv5vr//rwsvjJP8XxhP/8H/3JzGZW77T/71+WPi/t6gI/+fw0KL/u+ss/N9r FP7vS/2fqnP9v278AP8nra7K//Um+/p/3fgB/q/O9f/wf4n+L6z/V5v/85vI6v/aFf8nc/Wk 2jvFfL4N+azwf2nPcvi/yB2I/yvh/6ycwvi/DTOk8X8K//evqJVW4f82ojz8X0b/Z+UKalOu gU/b8BO0KvR/91UNz/R/9wHVMSFqHOaVbs72f12nmxr9XyNfoVSb//O3XPzfwiTVuf9TtqnR /1n8HyW63P1ff2BGnP/rxf+ZH4X/O764sxz/Fz/ujf9LbxX+L6FbUcr/Nfg//N9i1LL/cyPd odoZZRp/NobKR+H/EqNK+T/T4f8ytAr/h/97bRX+LzEK/xcb9boH8X8ZdiD+LzEK/5fQKvxf YhT+L7JZ+L97hf/D/1Xt//rhUe32f9O8Wvd/5lHh/9Zb9Qnr/+H/8H/4v+z+b7LZ/d/YLPu/ yZ9XerBygO+cWjS7O9wu3Bfyf7rTU5Xr/1Xp/3q3/EJW/6ebEf8X2Sr8H/7vLQr/57PkL8L/ 4f9cwf+t7kD8n1T4v61RK63C/21Eefi/jP5vkhGTyT+C7Ix62sZjpby6/N8nrP9Xof/TbRvW /2u6vVHaDq63ECqF/8P/xfi/tnXDxFn9X/cB6//5l2NZ/Z8bD8T/USLL3f/ZAzPi/J8V/9f9 KPzf8cWd5fi/+HFv/F96q871f+HOi/97fbR68n+mW/N/MjeqiP8zod+G//vzsDjd/7kXdqHa GWUaf26Gykddyv8dgUSW/Z+W+Q8Z/Z82+L8MrcL/fYP/0xP+LzUK//eehf/D/+H/VqPwfwmt wv8lRl3J/8kbJfxfXBT+7zv93yjXcfzfFk+x7P8C/Cnh/8LlD//371Z9gP8LL6jxfwsTfJ/8 n8H/pfm/friS/wvr/4lL2XtvlN0QKjczZnn9P1vQ/4UpfbKfq/B/R6z/5y63p/u/0KnA//3b /11t/T9/Ocb/LQz9XNj/2UHn9n/Oq+P/Ej8r/J+K6t1+nv+Tqwn+748Z0gr/p/B/f0SttAr/ txHl4f/y+T8t3TEtL0L2RT1v4yP8XyujNaz/9x717P9mKO+s9f/ci27dtqM8Huz0f+7/DpXr Qkz4vyytevV/vXe1+L+Fx+5n/zfW6P/cuAX+jxJZ7v5vODAjzv8N4v/sj8L/HV/cWY7/ix/3 xv+ltwr/l9CtKOT/9PgB/u/+vQ35/J9d838ywIn/2zLDfMn/GfeuJVQ7o0zjnzZD5aPwf4lR pfwf6//h/1ajavN/rP+H//O/hf9T+L+tOxD/lxiF/0toFf4vMQr/F9ks/N+9wv/h/+r2fzPh gf97eq3ezirTNMX8n9al/J8nUfi/qFax/l9W/zd2+L/IKPxfCf/Xuqlmef2fn8WE/4s7LM7y f7dnfPxfXKvwf7X5P9tn93/mWv5Pxnnwfxvmp+L/4nYg/s9X+D/831Kr8H8bUR7+L5//uzXE 35xG2+6PetqG6+Xi/xai8H+L/u9W/Pp/Y+gq7fR/9rdSrP+H/4vyf8YNoWT1f62t0f+5VuH/ KJHl7v/GAzOi/J9txP/pH4X/O764sxz/Fz/ujf9Lb9W5/u+IqcQV+j+z6v+kO1/C/0l3vcj6 f/i/RP/nRqFDtTPKNHp8VD7qUv6vyRDVvEQt+z//VI//2/KOAv+XHlWZ/3PTOPF/iVEV+j+L /8P/re9A/F9iFP4voVX4v8Qo/F9ks/B/9wr/98n+TzrP+L/FqG3+rwsvj5P8Xxht/sP/zSfO 7/Z/YfzoQTfwf1GHxcb1/8JoNP4P/zcrX73+nzY1+r/WFvN/LmrZ/4ULVwn/1/uZ1wX8nzV9 bv9nuk/wf3LoVeb/XEZW/+fWPLiQ/2sm16pv9X/jmv/zl/S8/k8X83/aVOj/2uYD/J9sIqf/ a/F/+D//89v8n/SgK/N/WsYepdp5DXzahlL4P4X/+yNqpVX4v40oD/+X0/8JepFqr/+bb+MR VZf/u/VuT/d/cpeuy/9ZrbX4v91RDv71v9Us6kT/Z+TNYnX+zz924/8WJqnO/Z/71hj8X1wU /q/Scvd/04EZcf5Pi/9rfxT+7/jiznL8X/y4N/4vvVX4v4RuRSH/d4861f9Z/N+3+D//TBWq nVGm8c9UofJR+L/IqOYlqpT/60b8X4ZW4f++wP+x/h/+b8H/tR3+D/+3vgPxf4lRlfk/M+D/ MkXh//B/z3sQ/5cehf/bfrDj/1QZ/ye9Tdb/+6tV7Yj/i9yBp/k/g//7Fv+num7F/8nB/p3+ z60pd/r6fxX6v9Y0+df/M/i/g/yfGynOu/6fO4Xxf1Gt+rz1//B/+D/8H/5v/tCj8H/4v5dt vEfN23VYFP4P/7cWtdIq/N+/H7vP9n928n/K4Dq5e6OetuEnaFXo/+6rGuL/svq/26Pb7aqn 23aYzN4oB/+630p9xPp/+L8r+7861/9z44H4P0pkEf9nmiOtXZz/M97/GfxfkeLOcvxf/Lg3 /i+9Vfi/hG5FqfX/xlX/J8dDAf9n7j2cfP7Prvk/eR2C/9syw/zd/ylrXBfR9E2z/2qhrZ9m ECr/kueK/i/rNXDF/7nfzur/Wov/y9Aq/N83+L/O4v9So+rzf12D/8P/re9A/F9iVGX+b9T4 v0xR+L+P939mwP+lRuH/EqPwf7FRG/2fNDvN/4W+dMX+zz04Vuj/xlX/JycW/u8P/8f6f/g/ 2crTRERbzv+ZD/B/KpzCsp8P9X/+MlFi/b/WHXp5/Z+73J7u/8LU9sr83zhl9n/amiv5P3ma 0uHOstf/dfOqnP9z62pW6P9Mh/9b2IH4P/yfj91+XuH/8H/uR/F/S63C/+H/8H+Z/N8gj/ND n3ANfNrGI6ou/3dXjfi/rP7v9ix0u+E7//fUD4z2f+1vNYvC/2X2f9a/XcD/LTx2P/u/rqvR /434P0p0ufs/fWBGnP9rxf/1Pwr/d3xxZzn+L37cG/+X3ir8X0K34kr+b/C9pCLr/+H/0vxf 6wajs/o/F4X/i4xaulos+D8/oYj1/za8o8D/pUdV5v/cMg74v8So+vwf6//taRX+L/PzAf4v cQfi/xKj8H9vUfg//B/+bzkK/5farPP9X4A/+L/XqGf/N7QV+j/vlBb9n/w2/m9hgi/+D/+3 cATW7//cl3Cv+D9pdVX+b9LZ/d+9Ve8fFv7v0/yfsj3+L7JVZ/k/zfp/X+P/nNWs0P9N+D/8 n//5bf5v9Nutzv+1j2q3/5ttQyn8n8L//RG10ir830aUh//L6P+sdEkHneD/nrahKl3/7xP8 nwx3tWE+yU7/N84rM5zt/8apE/8XRud2+j/9W81adaL/a5swpF+X/5NZPvi/hUmqc//XWfwf /o/iy93/mQMz4vxf7/1f2/wo/N/xxZ3l+L/4cW/8X3qr8H8J3YpS/s98gP8bw9vpEv5PXufi //b6PzfynNX/uSMQ/xcZtXS1wP8lvKPA/6VHVeb/3DRO/F9iVH3+zw0v4f9io/B/mZ8P8H+J O7CU/+s7/F+mKPxfXv/XyxeR5vR/usX/pUbh/xKjFv2fCpNG8H9bPMWi/2tnwmO3/wt7EP/3 Zf7vdhSv+D8RP/i/hQm++L+c/s+O+L/IqA/0f2E4QfZzHf5vsNn9X8f6f9/j/2534Uv5P+9r qvN/7g/N6/+aK63/N065/Z8/2M/2f83kd29G/6fW/N9Qzv/JVy4X8X/C20r4vzBVtoz/kyaU 8H9+0k99/q9/VLv932wbSuH/FP7vj6iVVuH/NqI8/F9G/zfI085gE6KetuF+CP+3EJVj/T95 2sno/7rT1/8bmttDcF7/d3uCx/9laRX+b6f/a2r0f+67cPB/lMhy93/tgRlx/s+K/zM/Cv93 fHFnOf4vftwb/5feKvxfQreikP9zb5/P9n+t9LHxfxsOi9P9n9tzppsS5hXdHmTaR+Wj8H+R UUtXC/xfwjsK/F96VGX+j/X/8H9L/q/B/+H/1ncg/i8xqjL/x/p/+L9/ROH/Uj4s/F961GX8 X5gZjf/b7f+k+1bC/4X++lf6P/fgWJ//8yQK/xfVKvzfl/o/j13xf1FRT/6vM1X6P/fl9gv+ rzMD/u9r/J/r+mX1f27O44X8X+PRHv5vYejnNP/nPqtz/d/tHoL/w//h/7ZH4f/wf5uj8H/4 v7WolVbh//7x2P0B/s/KNMRBJ1wDn7ah8H/4vwj/19rbJpz/683eKG0H10MIlf9J/F+WVuH/ vtb/df6BIKv/c8PE+D9KZLn7v+7AjDj/N4j/634U/u/44s5y/F/8uDf+L71V+L+EbsWF/J+R wegy/i+8C8L//Rm16P98H9t0U7s/6vYgYx6Vj8L/RUYtXS3e/F8z+WMup/9z75Pwf8mtwv99 gf/TY4f/S43C/71n4f/wf/i/1Sj8X0Kr8H+JUfi/yGbh/+4V/u+j/d990Az/l+j/fE8w1f+9 orxX/yet8lMjd/u/dl6V83/+K5AX/Z88hVTn/0xotfw0/g//p6r1f312/9cW83+tLef/xlX/ J39RTf6vaaZK1/+TD0kG//f6v9cXc/X5v9tRfC3/51qF/1sY+sH/lfF/4dVxmv8Ljwef4/+k A1XG/+nZDjzW/4X5JgX8332Yp4j/Gx7Vwf5PLnhF/F/4ApsC/k9N6f7vaRtK4f8U/u+PqJVW 4f82ojz8Xz7/d7tD2Ue1L+p5G4+ouvzfZPF/WVr15P/UNPXT4PyfNd3eKG0HN9AXKufl7On+ z8h7zer8n28H/m9hkuqT/7Pn+78xv/9T+D9KdLn7v/7AjCj/d/vvzv+Z4Ufh/44v7izH/8WP e+P/0luF/0voVlzI/7WNvPHE/32+/+vdgLfpxj5l/T8/RSBUPgr/Fxm1dLV4X//PyAQS/B/+ 76k8/Rj+D/+38GP4P/yfFPwf/g//h/97jcL/vUXh//B/+L/lKPxfarNO939z4bHb/01PlVnx f+F18Feu/3c5/9eEVstP4//wfwr/96+DfZP/m/yIlpnCZOyd/q+dVc6ULfq/yQ9tmGZI8n9h l3yO//NXi+P9nxpa/N961Kf5Pz9NLKv/c3MeL+X//N0D//c+9HNl/zf0+D/8H/5vexT+D/+3 OQr/h/9bi1ppFf7vH4/d5/s/o/31IVT7op638YjC/+X2f/LbVfm/4XYiGXejGuXxYJ//69yo UagU/g//F+X/GjdMnNf/jc3p/m9wUwSy+r/bjsL/UWLL3f/ZAzPi/J+W9f/0j8L/HV/cWY7/ ix/3xv+ltwr/l9CtKOX/1Pn+L4yelvF/MtkH/7fX/7n3IPi/TVGn+z8/aQH/t+UdBf4vPepc /9fLwz/+D/83K/LyFP+3aQ/i/zLsQPxfYtSp/s8fevi/LVH4v7eob/N/MmU7p/9TFv+XGoX/ S4xa8X8BN+D/8H+zct94Cf8n/YkS/s/IEHER/9cNodUhWVXh/6TfjP9bONg3+b9OJukV8X8y ql/E/0nfr4j/83eMIv5v9Ct6mUYnTS0K71T6e9SK/5Mderz/M9Mo33+X0f/pdsn/9bf95/1f O6b4v356VJ/h/56YzaH+T8lduIj/c487+L/FqI/zf67vUcj/WfdZlfF/XZiF6Tayd4r5fBvy WZ3t/9zNqZD/k2tkaFyi/2vvUYv+b/SX9EL+T0RDEf8nh00R/yd7q4j/k2OgiP8LUcf7v142 XsT/dZO0vYT/C2MjSf5vtg2l8H8K//dH1Eqr8H8bUR7+L6P/G/wVNFQ7/d/TNh5RJ/o/M/o7 RqL/k1/4HP9nRnmK6LqEqNHOK3O2/+utuf0p2gx9GJ3b4//6qbO/lfoQ/ycDFpX5P98rq8z/ mc4NsFfn/yY3qsT6f5Szy93/DQdmxPk/I/6v/VH4v+OLO8vxf/Hj3vi/9Fbh/xK6FRfyf62M pRbxfzJXBf+3ZYb5kv/z02JMN5ok/9c/Kh+F/4uMWrpa4P8S3lHg/9KjzvV/cj/D/22JupL/ 8++p8H9b9iD+L8MOxP8lRp3q/3xXCP+3JQr/9xb1bf5Pnobxf1FR+D/83+/TMP7P/ccB/i9c /gr4P1lvqYz/k38v4f9kf5bxf2FueV3+r5G+H/5vr/+TXksR/xfWnCvg/9pBbh8l/J8/xQv5 P/dZ1uf//MzrAv6v0YPzf+2UtP6fmR4V/m/H5Rb/h/9bOIXxf/i/v26NCv+H//Mbwf/h/9yP 4v+WWoX/w//h//L4v1b7AYtQ7Yt63sYj6kz/J6+CEv2f7IYP8n9h5Yia/F83uB6TNqZ/6gdG +j95RpNK4f/wfzH+T49thf6vbyf8H+UDyt3/jQdmxPm/Vvxf/6Pwf8cXd5bj/+LHvfF/6a3C /yV0Kwr5P7es8Nn+L4xm4v82HBan+z83THbbiwlTLbT106RC5aPwf5FRS1eLd//nJ2bh/7a8 o8D/pUed6/9koKaVe8nOaTFPL+TwfxX4v96/0cT/bdqD+L8MOxD/lxh1pv8TEdWZSebL7vR/ w6y67Rr8X6Yo/F9m/ydT9fB/UVH4vy/1f7Jd/N8WT7Ho/wR65fR/t8vFsv8LmCzN/4UJvr8f 1qL/C5OJWrmo7/V/zbya9LL/U+N86CKL/9PTsv/T4Tk4o/8zZs3/yXbr8n+9TJHA/y0c7Nv8 n5x+9z7GTv8nb9zuU166Zf/XyoBNRv93+/cV/xcmfmX0f7pf9n+jFaxRwv/5A0EPNhD5XXf8 MAtQkPhH+D+/vHUB/9d19rbndHsrCf5v9OsmhOoz/J/Mwizi/0QeFPF/7r0T/m8xapv/80do Ef+nh0nl9X+3O9uK//Pnaxn/12bwf/NtyGd1sv+z7rMs5f/srHHH+j952ini/+SFeBH/FwBl Cf8Xzt0i/k/2VhH/J7fcEv5POlZF/F+Yw1/C/42hA5ji/+bbUAr/p/B/f0SttAr/txHl4f8y +r/ed1xCtdP/PW3D/dAH+L8woJrk/+QG90H+T3pMif4vdCI/xf9pt/SG1qPWZm+U7gbXUQ2V +hD/J3PBKvN/8qBdmf8z7omqOv83yMbxf5Rzy93/TQdmxPm/Tvzf8KPwf8cXd5bj/+LHvfF/ 6a3C/yV0K67k/0TjlfF/8ioT/7fT/w0a//c1/i/Mf8D/4f+eytOP4f/W/F/b4P9So+rzf22H /8P/re9A/F9iVGX+z7D+X/JdBP+XvAPxf7mi8H/4v9+nYfyf+w/8XzOvCvq/R6sO938PKYf/ 2+X/tMH/xX1Wz/7v9pMr6//1+f1fU8z/qZX1/w7wf7KqoXorB/g/c7r/axt//Gb1fy5qYf0/ O3bO/5lh3N87G0d/QoXq1jv+AP93X8Je9gH+b8X/6WbE/0W2apv/M212/6fW1v8b8H9J/m8c ugr936Txf/g//F9EFP7viCj8H/5vLWqlVfi/fz92n+3/Bv+2sR380nI7/d/TNtxP1uj/BlOj /5uhvHP83+1Kfusx3bpLOmH9v66dxt/K/xD+L0urLuH/mslk93+mOd3/TRr/R/mAEvyfPtLa xfm/Xvxf86Pwf8cXd5bj/+LHvfF/6a3C/yV0K073f9LxLeL/tDy0l/B/YdIS/m+n/xvdXBbT pbzo1ta/GgqVj8L/RUYtXS3e/Z/F/+H/8H/bz6tn/9eM+L/UqPr8nxnxf/i/9R2I/0uMqsz/ zVEe/g//9xJ1rv+Ty15O/9fi/1Kj8H+JUfi/2KiN/k/+Pc3/hfHEv/zfbOL8bv8Xxo8+xv/p cBYV8H8B/mX0f7efXPF/8tv4v4XxBPxfTv836hX/J4MHZfxfmGpSo/+zg+zuNP8nWMyu+b/g lEr4P/8UV8D/jY023v/Zdn/vbBw786j8DryS/7NzRP5l/s/NebyU/5PhRvxfov9LWPfleRvu h073f1Nbzv+F2e4l1v8bs/u/ds3/hWk+RfxfaE4J/ydNKOD/VOisl/B/TTivjvd/tvFHdhH/ J39KEf93vwGk+L/5NpTC/yn83x9RK63C/21Eefi/jP5PeEjby0Pw3vX/ZttwvdzP8X8JUc+o RdnmfP8nrw/CO/VE//d8vzrN/w1Df+vm6FtPqTV7o3Rn3L+FahZ1ov8L8K82/+cfemrzf2OD /9vk/yz+jxJd7v5PH5gR5/+s+D/zo/B/xxd3luP/4se98X/prcL/JXQrCvk/053v/1o5r4r4 v17eWeH/9vq/oZW3IfujtPW/HCofhf+LjFq6Wrz7v8FdLbL6P23wfxlahf/7Bv/X9vi/1Cj8 33sW/g//h/9bjTrT/1nfucD/bYnC/71FfZv/k0U3svq/Bv+XGoX/S4xa9H9a5nvj/7Z0Oov5 v6ZG/2e7Yv7PfdtyIf83rvm/Icwtx/+9jSc8+b8B/5fm/xyzWfR/U3b/Z9f8332qCf7vNerj /J+WpRFy+j93uX33f9PQWe//wsG+0//5i2aoZBbT2f4vjPrj//7wf25hUvxfVKu2+b+2z+3/ tFnxf11bzv+Fd1dJ/m++DfmszvZ/7rPE/y1F4f/wf3+9blSr/s/i//B/+L8sUSutwv9tRHn4 v4z+z/guadv6V7Q7/d/TNmr1f/dVDfF/Wf3f1OlbP1DrtpNDb5//066HHCo3bdie7//ka5ja hG9jcmNt8wr/d5D/Gzr83xb/1+L/KPHl7v/MgRlx/m8Q/9f9KPzf8cWd5fi/+HFv/F96q/B/ Cd2KQv7PvQ5Z8X/Snyjh/8KULPzf5/u/yc2Mxv9tijrf/7l/z+r/Wtb/w/+tReH/8H9vhwX+ 7y0L/4f/w/+tRuH/ElqF/0uMupT/E7mB/4uKwv/h/y7q/8ZHler/7EvUsv8Tl5Lo/x5v8Ovz f49WHe7/Vtf/C2oI//eH/7vo+n9+1yT6v1CNH+D//G/j/xZAyjb/Fy7H3+n/+m7Z//Wy/l/K jLNx9FPNQnXbm5/g/2QH1+X/evcwkNf/uVP4Ov5PN62vvtP/jfi/7/d/dpo1rh7/Jy8YSvi/ gMlK+L9OPpgC/k+H+2AJ/ycvg4r4P7l7lPF/8nhQxP/1j2q3/+vnFf5P4f/+iFppFf5vI8rD /+Xzf2byz1dt0+6Pet6G64ad7/+kHTn9nzb4vyytevV/3a2Xrm93Km32RunOf2lAqNRn+D9Z Mbk2/+cfCGrzf3as0f+N7nk7q//rug7/R4ktd//XHpgR4/9a9//r2/2m+VH4v+OLO8vxf/Hj 3vi/9Fbh/xK6FYX83z3q3f/JLivh/4wM45fxf+HLFPB/f0Yt+b+hsa3C/22LOt3/2ezr//Ud /i9Dq/B/3+D/mhH/lxpVn/9rO/wf/m99B+L/EqNO9X9+YBz/tyUK//cWhf/D/+H/lqPO939y DOD/tniKZf8XZrPj/16jrrD+36r/C/d3/B/+b1by+z+/zNbJ/q+TQw//twBStvm/0Orv9H+j XvB/uhnb4P8S3lWMox/BDNVn+L/Qqa/M/7lzN6//cwuTXsj/aRlu/E7/V+f6f7e+xcn+b9Ia /4f/O9f/9Y/qYP9nmke19wH1jfDi/+J2IP5PKvzf1qiVVuH/NqI8/F9G/6f985WRp/qd/u9p G+oj1v/L7/9sg//L0qon/6cb21jn/8wkLwJ3+j9H5EKl8H/4P/xf7+cD5vV/I+v/UaLL3f91 B2bE+T8t/s/8KPzf8cWd5fi/+HFv/F96q/B/Cd2KRf9ndI3+r5Xzqoj/8xwA/7clatH/6bFV +L9tUef7P3/M5fR/ncH/ZWgV/u8b/B/r/+H//G+x/p/C/23dgfi/xCj8X0Kr8H+JUfi/yGbh /+4V/g//V7f/Gx/V0f7PPir83/ohWND/OTy06P/G++Oy/DT+D/+nDvF/jtkU8n9qzf/Jq5c6 /V8/puChu/+TcbjmSv5vsl1u/2e6S/k/bYr5P+8psvo/bQ3+L7JV+L/q/N+Q3f/ZNf8nUL06 /yedsxL+LwDKEv4vPPjWtv5f6G/7jnQ1/i9M+ini/6Q5af5vtg2l8H8K//dH1Eqr8H8bUR7+ L5//00PfPqp9Uc/b8P3ACv3fXTXi//L6v7G5PaA6/9ebvVG68z2EUKkP8X8yBoX/u6T/G0/3 f50d8H+UDyh3/9cfmBHn/4z4v+5H4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n/uPe2y/5PDooj/ C1Oy8H+f7/+Mu+rh/zZFne//ZP4D/g//91Sefgz/t+b/WP8P/+d/i/X/FP5v6w7E/yVGner/ /JmU1f/pFv+XKQr/h/973oP4v/Soy/i/8N4U//cN/m/2JLbb/71O8MX/vUVF+D+75v8G+Xf8 3x/+b8D/pfm/UeP/IqNO83/r6/+F4QT5w+rwf7bN7v8+Yv2/8JqsLv+Xf/0/PU6X8n9+eQX8 38LQz2n+z31W5/q/0U65/Z+7Bq6s/9fOGleP/5O7RxH/JzfrIv5Prq0l/F9Tbv0/Hb5NyHek j/V/Qg2L+D+ZOF/E/40Z1v+bb0Mp/J/C//0RtdIq/N9GlIf/y+j/Rv84H6qd/u9pG4+ouvzf YPB/WVr14v+6W2/9dofvbLM7Snet6/CHSp6Fz/Z/oXuE//vrSeQT/J/J7f/0B/i/zv12Vv/X mg7/R4ktd/9nD8yI83+t+D/7o/B/xxd3luP/4se98X/prcL/JXQrruT/5E0c/m/DYXG6/5vw f9/j//yEIvzfhncU+L/0qNr8H+v/4f/8b7H+n8L/bd2B+L/EKPxfQqvwf4lR+L/IZuH/7hX+ 75P9X5hqjP/b0ulc8X9hNjv+7zXqyf9pPRbzf32H/4vcgaz/963+bzLF/J/F/yX5v85U6f8c t373f7qdbG7/5wAl/i9mB6rT/J+7C+P/4lp1lv9T9hP8n35Uu/2fnlfnr/+H/1vfgc+zbqc1 /ycdiSL+L7zPxf/h/2YF/6fwf/g//N9iFP4vs/+b/MiZabwx2un/nrbxiKrL/3Uj/i9Lq579 nzauj3R7Ngj/9z7/17uOaqjcNcfg/7K06iL+L/v6f+4Jvz7/d3tUw/9RYsvd/w0HZsT5v877 v7b5Ufi/44s7y/F/8ePe+L/0VuH/EroVhfzf7QngfP8n51VO/2fxf8f4P/dFt/i/bVHn+z/X KvzflncU+L/0qNr8H+v/4f/8bz37P4P/w/+t70D8X2IU/i+hVfi/xCj8X2Sz8H/3Cv/32f5P pufh/7Z4itP9X3hxmuT/wvjR75zHUuv/TbrC9f9Ut+b/7P3rcuSn8X/L/s/0+L80/2d7/F9k 1BNyaLt/+78u5b3S0+qw/1r/Ty4T3+n/HLd+93+mq3T9vzBNDP+H/3vyf/6+i/97H/o5zf8p 1v87yP/5czer/+v6Ff/XSz+xhP+T7+wo4v/CZbyI/5OORBH/F2Zh+470of6vl2sk/m/VU+D/ 8H8bo1Zahf/biPLwf/n8n2n88KZppFOxK+p5G+6H8H8LUfi/Jf9njB6NqwZ5EbjL//V+Smio bj+j7fn+L3xWlfk/OfTq8n+6s9n93+OGX5P/Y/0/Sny5+7/xwIw4/9eL/zM/Cv93fHFnOf4v ftwb/5feKvxfQreikP9ziyWf7f/CaCbr/204LM72f12D//se/+fnHeb0f32H/8vQKvzfN/g/ 1v/D//nfevJ/bhId/i82Cv+X+fkA/5e4A/F/iVH4v7eob/N//gtC8H9xUfi/L/V/YWY0/m+3 /5sJD9b/e3qt3swr2xXzf49WHe3/1tf/C4cb/u/f/u/25+L/4j4r/F/e9f/GBv/3HpXu/1o7 5vZ/+iP8n/x7Xf7PupEs/N9iVP3+T5tP8H/do9rt/7p5hf87yP9NTXb/p9bW/8P/4f8W/J8M z+H/Vj0F/g//tzFqpVX4v40oD/+Xz//pwd8a9eC7SjvX/3vaxiOqLv/X2tP9X3v/CqWUqM/z f03vhi+m3uyN0n03db+V8t+afr7/k7lglfm/Vs70uvyf7bL7vyrX/2vxf5T4cvd/04EZcf7P iv/rfhT+7/jiznL8X/y4N/4vvVX4v4RuRSn/Z1b9n8wUKLH+n7yJK+P/5NkU/7fX/7mNm24w +6Oky3+vfBT+LzJq6Wrx7v/8a+es/q/F/+H/1qLwf/i/t8OiOv9nRvwf/m99B+L/EqMq839d g//LFIX/y+z/ZMP4v6go/N93+r9RruP4vy2e4nT/F2Yg4v/+fQiWW//vdhSv+L9ejmz83x/+ T+P/0vzfZPB/kVHP/s8U83+dWfV/wa3IH/Zl/m/Uy+v/jabO9f/wf/g//N/mqCv7v2nM7v/8 wY7/S/us8H8qqnf7ef5P5qxU6v/GDP7vxVPg//B/a1ErrcL/bUR5+L+M/s9o2YRtd0c9b0P9 rpRXl/+7ix78X17/1/a3w+Z27Mj9fKf/G9y3iIZKfcT6fwH+1eb//EyO2vzfVKX/G/L7v6bB /1FiS/B/5khrF+f/Bu//TP+j8H/HF3eW4//ix73xf+mtwv8ldCsK+T/XWTrd/7XhlTH+78/D 4mz/12v83/f4Pz/yjP/b8I4C/5cehf/D/70dFvi/tyz8H/4P/7cahf9LaBX+LzEK/xfZLPzf vcL/4f+q9n9hWrPsoL3+b5xXq/5PeptS7fZ/rx9WKf836WL+rx3PX/8P/4f/Y/2/3f7Pnr/+ 3+R38O0MlzN9p/+Tc7P/jbqM/7vdQrrc/s8toIj/i9mBaqv/s1Nm/6etuZb/80jrS/3f+An+ zz6q3f7Pzqs6/Z+9mP+TzlkJ/2fnV/Zj/Z886pXwf2oKB3sJ/xcGR3xHGv+3w/9Nj2q3/5vm Ff5P4f/+iFppFf5vI8rD/+X0f834qPb6v/k23E/W6P8Gg//L0qpn/3d7Fro9X+nbJyWPB7v8 nzWupx8q9Rn+L/vg9+OwwP9l9X9mzO7//Ddnnev/2sm/4M7p/9wXquH/KJHl7v/0gRlR/k83 4v+aH4X/O764sxz/Fz/ujf9LbxX+L6Fbsez/huz+T635P3kNWcL/GdF4+L8Nh8Xp/m/Q/m1I s/9qoa1/Lx8qH4X/i4xaulos+D/371n9n27wfxlahf/D/722Cv+XGFXI/7Ud/g//t74D8X+J Ufi/hFbh/xKj8H+RzcL/3Sv832f7vzBohv/D/83Kd/s/rT/A/8m/4//wf7PC+n+X9n91rv/X d4vr/5kxu/+72vp/Ig++0/+5VXjxf3GtusL6f3bV/w2Parf/G+bV6f6vbyd3ErH+31IU/g// t3QKN/Nqzf/ZBv+H/8P/ZYlaaRX+byPKw/9l9H+dvzVq6S7u9H9P21CVrv93b1Vd/u/21Hjy +n+3x223/t80yoe00/+5x8xQ3f7LOH2A/5MnPvzf5/u/Yczu/8zp/q8f3ANBVv/novB/lMhy 93/mwIw4/6fF/5kfhf87vrizHP8XP+6N/0tvFf4voVtRyP+1q+v/4f/wf+/+z7b4vwv7P2Pw fxlahf/D/722Cv+XGIX/i4163YP4vww7EP+XGIX/S2gV/i8xCv8X2Sz8373C/+H/6vZ/w6Pa 7f+meYX/+571/xr8H/7P//xZ/q/c+n9OiVzI/42eHGgbFM9O/yd/Zx+0TZX+b3n9v7axt0NP t50eEvzf5K/VoXL3I/xf1A5UW/2f61TkXf+vGfF/ka26gv9TV/J/Fv+H/8P/RZ3CzbzC/0Vf A/F/UuH/tkattAr/txHl4f8y+j/Tyt1j2H8NfN6G+y81+r/7qob4v7z+b+q1+96iNpxQ+/yf dVNsQqVkiAT/l6FV+L99/s8NqJ7s/waT3/9Z/B8lutz9X3tgRpz/M+L/uh+F/zu+uLMc/xc/ 7o3/S28V/i+hW1HK/zWr/k/6EyX8X3hrgv/7Av/nxlrxf5uiTvd/3jFl9X9th//L0Cr8H/7v tVX4v8Qo/F9s1OsexP9l2IH4v8SoU/2f7wpl9X+mxf9lisL/4f+e9yD+Lz3qMv5Ptov/2+Ip lv1fgD8F/N+807nb/4UJvsX9n+0utf6fTMbG/y2MJzz5vwH/l+b/2vH89f/67P6vLeb/WlvM /33E+n/+8M7p/xz0WvJ/re5z+z/W//se/3e59f9aX+H//vB/Bdf/0+Z8/zdk9392zf/JXbg2 /yfjMEX83yCtLuH/Dpmfuuj/tDzDlfF/YRa270jvfEBt508z6gP8n5JLURH/N7WPau81cL4N pfB/Cv/3R9RKq/B/G1Ee/i+j/2v8JV3LJXan/3vaxiMK/4f/W2jVs/9rjTbaDV+YlPX/rOvS hSoMkZzt/+QrJ/B/G55EKvR/jxt+Rf7PdPg/SnS5+7/uwIw4/9eK/7M/Cv93fHFnOf4vftwb /5feKvxfQreikP9z3Yqz/V+r8X/f4v+GDv+H/8P/pbUK/4f/e20V/i8xqpD/MyP+D/+3vgPx f4lR+L+EVuH/EqPwf5HNwv/dK/wf/q9u/zc8Kvzf02v1Zl7V6f9W1//D/23yf6bH/33L+n91 +r+C6/9dy/8Zp4ZuF71p2t87mxr/eYcK/7fjcov/w/8tnMLP/m+s0v+pD1j/L7v/a/F/+D/Z SDOv8H/4v7dtKIX/U/i/P6JWWoX/24jy8H85/V8vD28p6/89bUP9Sjn83+f7vxnKO8n/aYf2 bs/cYVhwn/+bXGc9VLef0Rb/l6VVl/B/bcP6f/g/ylHl7v/6AzPi/F/n/V/b/Cj83/HFneX4 v/hxb/xfeqvwfwndikL+z70OWfZ/ssuKrP/XhVfGBfzf/V0Q/u/PqEX/N7pBddPZhBfd2nqE GSofhf+LjFq6Wiz4P5n/gP/D/z2Vpx/D/+H/Fn4M/7fi/1j/b0+r8H+Znw/wf4k7sJj/G/B/ maLwf/i/5z2I/0uPwv9tP9iv7f/C+1Vf7fV/ZniquhX/N6eGu/3fCjU83P+1Q43+b3X9P7n0 4/8WxhPm/o/1/1L932Rq9H9qxf+JPGjDiNZe/9fPqlX/N/kLlx5tyh2/n8Keu0fV5/9ut74l /2cGjf+7sP9zLPRC/q+RB8Uv9X+s/3eM/+tGndv/uWvgiv+zs8ZV4//kCC3i/+z8yn6s/+vk cCvh/8JVqIj/Gx5Vov9rfx9QT/d/4yRtL+D/Qg86yf/Nt6EU/k/h//6IWmkV/m8jysP/5fN/ KpCpyd8Td0Y9beNhX+ryf7feLf4vR6ue/Z/ph9sD7O2ZW9vdUdqObtgtVOpD/J/MBavM/8lK n5X5v67L7f/cV4+d7P/a0V38svo/9yyM/6NElrv/swdmxPm/Xvyf+VH4v+OLO8vxf/Hj3vi/ 9Fbh/xK6FaX8n8H/4f8Wo5b9n8X/4f/wf2mtwv/h/15bhf9LjGL9v9io1z2I/8uwA/F/iVH4 v4RW4f8So/B/kc3C/90r/B/+D/+n/pheuc3/2eZR7Z1eaZp5VdD/FVz/rx3PX/8P/7fN/2n8 H+v/Kfl/5tXa+n9ddv9n1tb/a/3xMFg5wHdOLZLPROR2nev/rfo/0+L/ruv/bj+J/4tsFf4P //f+avjF/5kq/Z/F/+H//M/j//B/W6Pwf/i/taiVVuH//v3Yfbb/G+WeOE771/973oZ7bKzR /7H+X/rbxiX/Z9t2cM/c4UPa6f/c+4BQKfwf/i/K/7XZ1//7BP83uMsE/o9ydrn7v+HAjDj/ Z8X/dT8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/3OD0cv+Tw6LIv7Pv33G/205LM72f5P7kPB/ m6JO93/+fpXV/xmL/8vQKvwf/u+1Vfi/xCj8X2zU6x7E/2XYgfi/xKhT/V/v9lZW/zdHefg/ /N9LFP4v5cPC/6VH4f+2H+zX9n9iXxL9X1Bi4XKxuv7ffXTSb+nL/N+ka1z/b9X/hZlz+L8/ /B/r/7H+n2ylfv/X2kv5v/zr/93uR+f7vzBfujL/5+an5vV/ZriW//NXC/zf+9DPaf7PfVYn +7+hx//h//B/26O2+b9+lN/G/+H/8H/4v4WolVbh//792H22/xvkUW/096udUU/bUL9Sri7/ d1/VEP+X2f91tzuU839Niv9zT9ChUh/i/6Q7hv+7ov9rbXO6/7P+BTf+j3Jyufu/8cCMOP83 iP+zPwr/d3xxZzn+L37cG/+X3ir8X0K3opT/U/g//N9i1LL/G/F/F/Z/7Yj/y9Aq/B/+77VV +L/EqEL+r+3wf/i/9R2I/0uMOtX/+RlF+L8tUfi/tyj8H/4P/7cchf9LbRb+761Vl/d/n7D+ H/5vm/9j/b+vWf9Pmxr9X2vxf5FXi03+r9VuFYbM6/+ZD/B/YdQf//dv/6ebEf8X2Sr8X23+ z07Z/d9Yo//zRyD+L64b08wr/B/+720bSuH/FP7vj6iVVuH/NqI8/F9G/2cHf+EajNkf9bQN 18ut0f+NH7D+XxhFqMn/tdo9F+i2myazN8rBv+63Up/h/7IPfj8OC/wf/u+9Va/+z78cw/9R zi53/zcdmBHl/0wj/k//KPzf8cWd5fi/+HFv/F96q/B/Cd2KQv7Pfc3oiv+TmQIl/J+Wh/Y0 /xceAf7wf314EY7/+zNqyf+NjRsaNp1NeLTS1veKQ+Wj8H+RUUtXiwX/53Yw/m/LOwr8X3oU /g//93ZYVOf/WP9vT6vwf5mfD/B/iTuwlP/rO/xfpij8X2b/J2MA+L+oKPwf/u+i/i9MGk3y f+G1+h/+zzaPCv+3fgh+wvp/w5xu4P/W/J/p8X/f4v/U6vp/bRgPzef/LOv/LVzZv8r/GQf/ Mvu/Ef93kP9z51Xe9f9uh8WF/J9u/Pu77/R/Sq35vya7/2vxfwet/yet+k7/54/ARf8XOmcl /F+4WRfxf7K3Svi/pqD/kz5LXf4vWM0i/i+gvST/N9+GUvg/hf/7I2qlVfi/jSgP/5fT/8nA kPVyaq//m2/jEVWX/xsM/i9Lq178n2mbDv+3YfD7cVjg/z7d//lvzjrb/7mLH/6PcnYJ/q89 0trF+T/t/Z8xPwr/d3xxZzn+L37cG/+X3ir8X0K34kr+b8D/fY3/m/B/F/Z/xuL/MrQK//cN /q8Z8X+pUfX5P9b/29Mq/F/m5wP8X+IOLOX/Ro3/yxSF/8P/Pe9B/F96FP5v+8F+bf9n7whC qVz+r8H/RUY9H4JmKOb/LP4vyf/d/lz8X9xndWX/p+2Y2/+Fz0q9lt76h8RQ7X2vFHqp4+8p fB3/12rTO1zT2P1H4NT462io/GFxJf8X7hj4P/zfsf7PfoL/Gx/Vbv83zqvz/Z+d3EmU1f/5 gx3/l/ZZ4f/UrgfU38MC/xcZhf87Igr/h/9bi1ppFf7vH4/dn+D/QsfFr7q61//Nt6EqXf/v vqIX/i+z/xt65/9uPYxub5S2k+uFh0rh//B/Mf6vM9n93+yGf5b/6zr321n93+0n8X+U2HL3 f/rAjDj/14r/638U/u/44s5y/F/8uDf+L71V+L+EbsX5/k+OhxL+L5iNvCgP/5cYhf97i/oy /+efXbP6P/c+Cf+X3Cr83xf4P7dyE/4vMeps/2dtbv/nBmLwf7FR+L/Mzwf4v8QduOz//DzP rP6vHfB/maLwf5n9n+wu/F9UFP7vS/1feG+K/0v0f75Lner/wuRbs+L/enkE+07/Z7sa/d/q +n92Tjdq8X9W5/Z/2jT4v7jP6sX/TeZ8/9eE8dB8/q9dWf9vsrn9X2uX/Z82kyfdbRjF2nfH D+9UhrCN6/g/NQ1Tk9v/fcT6f4N8SPg//B/+D//36DEt+T+/BE3e9f/GVf9nZ42rx//Jw1QR /xfuZ/N53wf5v0Pmpy76v/tU2SL+b3hUFfk/2Vsl/F/oQSf5v/k2lML/KfzfH1ErrcL/bUR5 +L98/k930nWWal/U8zYeUXX5v7HD/2Vp1ZP/U5MdB+2euTv5yHb6Pze8GapZFP4P/7fQqtf1 /3qb2/+1tjnb/7XWPRBk9X8uCv9HiSx3/2cOzIjzf534v+FH4f+OL+4sx//Fj3vj/9Jbhf9L 6FYU8n+mO9//tbLdnCjP4v+O8X+6x/99jf/zkxbwf1veUeD/0qMq83+67fF/qVH1+b8O/4f/ w/+9ROH/1vyfbvB/maLwf/i/5z2I/0uPwv9tP9jxfwr/t/RavZlX+L8K/N+Q2/91+D/8n2zl dSLisv9rcvs/5ymW/J+a/IXptnU503f6P2mOmDEXVaH/67tF/2e1Ff+XMAlnanw3PFSf4f/q XP/PfTBZ/Z8bKcb/xbXqCv5PXcn/jV329f/clxPj/xI/q2X/F5bKwP/h/2YF/6fwf/g//N9i FP4vs/+z/k7v6NTuqOdtuJ+s0f9NFv+XpVUv/q9zfXbddqPcSPf5v9H1UUOlWP8P/xfl/7ou t/9z4+wn+7++y+7/3ER9/B8lstz9X3tgRpz/673/a/WPwv8dX9xZjv+LH/fG/6W3Cv+X0K0o 5P/0uOb/xFMUWf9PhvFZ/2/DYXG2/zMa/5fo/+bvw3NFLfs//yHh/7a8o8D/pUfh//B/b4cF /u8tC/+H/8P/rUbh/xJahf9LjML/RTYL/3ev8H+f7f9k9Bb/t8VTFPJ/jyj836f7P7vm/4b7 47L8NP4P/6cO8X+2X/F/Ycm0jP6v65b9XyuXohL+b+yy+z+z4v/GIbv/W13/L1yOS/g/I+Pf R/s/rcemqdP/yWeF//u3/3NzHq/k/+RA+E7/p02V/k+b0/1f2+f2fx+w/p9pTG7/549A/F9c N6aZV5/g/0zzqPY+oIZX2N1vq67k/wJYSfJ/820ohf9T+L8/olZahf/biPLwfxn93yQPb1Lt 9H9P2/D9wNP9X3hcTPJ/ndx17gOqDf4vS6ue/N+tnzSNg/N/Xbc7StvRPTiFSn2G/wtzwery fwL/avN/flQpr/8ba/R/7hqI/6NElrv/6w7MiPN/Vvxf+6Pwf8cXd5bj/+LHvfF/6a3C/yV0 K67k/+R1Cf5vw2Fxuv8b8H9f4//8RL2s/k8b/F+GVuH/vsH/NSP+LzUK//eehf/D/+H/VqPw fwmtwv8lRuH/IpuF/7tX+D/8X93+b3pUR/u/MAfW92Dwf/g/KV/t/0b8X5r/G3Ux/6fW1v+T Qw//9x715P9aW6X/c1FL/m8Yc/u/e6vePyz8X5r/83Ozsvo/dxfG/8W1ivX/6vJ/1ozZ/Z8/ 2K/j/7T8Kfi/DfNTF/2fbuTIxv/h//B/+L+FqJVW4f82ojz8Xz7/Z2Tio5Gr+b6o5208pFxd /u++qiH+L6//G27HjfN/JsX/Dd46SaVkRBr/l6FV+L+d/u/89f9Gnd//KfwfJbrc/V9/YEac /xvE//U/Cv93fHFnOf4vftwb/5feKvxfQreikP9zD4yn+z/ReGX8X3tA1IX8n/+SR/zfpqgK /V9r8X8ZWoX/+wb/x/p/+D//W8/+z3b4P/zf6g7E/yVGVeb/FP4v+S6C/0vegYv+T67p+L+o KPzfl/o/mZ6H/9viKc5e/6/75vX/Jl3M/z1adbj/68Y1/xfmluP/3sYTnvyf7fB/cZ/VB/o/ 2YE5/Z8t5v9au+b/NP5vk/9zk9ve/Z/pm+z+7zPW/+tmVS3+r3cPA3n9n7taXMj/+YHQb/V/ as3/Wfxfiv9rjDuJSq3/N86qb/N/I/4P/+c/o2ZeXc3/zW4Au/3f600E/6fwf/+KWmkV/m8j ysP/ZfR/WoicPKfu9H9P23BdpvP9n7SD9f/eoz7M/5m2ufUvdduFuYE7/Z97HxAq17ud8H9Z WnUJ/9f5XnpW/ze74Vfk/9y3xuD/KJHl7v/sgRlR/q9txP81Pwr/d3xxZzn+L37cG/+X3ir8 X0K34nT/FwajS/g/GcbH/204LM72f50ffsb/bYla8X/tAVEr/k8mkGT0f92I/8vQKvwf/u+1 Vfi/xCj8X2zU6x7E/2XYgfi/xKjK/J8Z8H+ZovB/mf2fvLLD/0VF4f/wf79Dqlfyf1r2mVR7 /V/oTd47leOK/7PNo8L/rR+CBdf/W/V/Vi6u+D/836x8t/+zH+D/Rjnm7tPs9/m/+Rz9sAKl eiuj772ZYX4QRd/x74vFhZc5a/4v/EU1+T89NF2V/k8sZ23+z52vrP+3GLXR//lj7kv93+r6 f1/t/9xndar/64cu+/p/6/7PDrPGVeP/GumclfB/AZOV8H+hz1LE/4UJWgX8n76v5aj2P6Bu 9H+9b0cR/xe+9Bv/h/+bN+q4KPwf/m8l6qlR80fmavxfY2R6r3/63un/nraB/1P4v+3+77Z7 b5+VbtvJ7I7Sduia30qpT1j/zwiZqs7/NVLV5P/qXP+vG7P7P/csjP+jRJa7/xsOzIjzf1r8 n/lR+L/jizvL8X/x4974v/RW4f8SuhWF/F/7Cf5PXpeU8X/mgKgr+b8B/3dh/zcY/F+GVuH/ 8H+vrcL/JUYV8n+ux4T/i43C/2V+PsD/Je7AUv6v7/B/maLwf/i/5z2I/0uPwv9tP9jxfwr/ t/RavZlXtruU/2P9v23+zzT4v7jP6sX/OWZT3/p/qkb/5w72Cv3f7WFuaf0/22b3f/dWvX9Y +L9E/+eO0Lz+73ZYXMr/+fd33+n/tKnS/52+/h/+7x87EP+H/1s6hZt5ter/Or8Dq/N/9lHt 9n92XuH/FP7vj6iVVuH/NqI8/F8+/6dHj170OO2Pet7GJ/k/MyXMXb77P6lu3ZQa/d9dyp23 /l83au//RtPtjdLWjxqF6vYz2n6A/5O5YHX5PysjFZX5P2Nr9H+D+238H+Xscvd/44EZcf7P iP/rfhT+7/jiznL8X/y4N/4vvVX4v4RuRSn/16z5P5kbVcT/icYr4//0AVFX8n+2Vfi/bVEr /u8IJLLs//xAbd71/xr8X4ZW4f/wf6+twv8lRuH/YqNe9yD+L8MOxP8lRuH/ElqF/0uMwv9F Ngv/d6/wfx/t/6YwaIb/2+n/1CgPpGn+L3TxpCdo1vxfL09i+L9v8H9zuoH/W/N/rcX/fc36 f3X6P1PO/41r/i9Mq6vJ/7V6GnP7P+eU8H8xO1Bt9H/WfTBZ/Z8bKb6U//N3D/zf+9DPdf2f baYpt//zB/uy/7OzxtXj/6T/UsL/9feJ9f5/HOv/5Npam/+TK39t/k8+JPwf/m/eqOOi8H/4 v5Wop0bNH5mr8X+9vLeXaqf/e9rGI6ou/zcY/F+WVj37v7YZevF/oau00//Z30qehfF/OVqF //ta/+dGl1Re/+ei8H+UyHL3f9OBGXH+rxX/Z38U/u/44s5y/F/8uDf+L71V+L+EbkUh/2e6 8/1f24QXNPi/Pw+Ls/1f756H8H+boir0fz3r/+H/1qLwf/i/t8OiOv/nhpfwf7FR+L/Mzwf4 v8QdWMr/mQH/lykK/4f/e96D+L/0KPzf9oMd/6ey+j/3ZcH1rf/XDsX836NVJ/o/aRX+79/+ L6y+hv/D/z1NRLRV+r+mu5D/u/UmvP8LXdq9/m96VJfzf0FnhWqn/3sdZSrk//zCpBfyf34G 4pf6P3e5xf9FtWqb/9OmLej/2lnjvs3/mRX/F2Z6FvF/4X1uEf8nl4YS/i+MdRfxf3dNrPY/ oG70f205/yevuMr4P7nJpPm/2TaUwv8p/N8fUSutwv9tRHn4v3z+T02jnwjX+AHJnVFP23C9 3Br9331VQ/xfXv/XmltHWrd933R7o7SdXG8hVOoz1v+TMajq/J8/9PB/C5NU5/7Pfb/K2f5v yu7/3Ngt/o8SWYL/6460dnH+r/P+zww/Cv93fHFnOf4vftwb/5feKvxfQreikP9znaUV/ydD gSX8n5xXOVGeXfN/dsgddTH/5165mM62+6O09a9DQ+WjLuX/mgxRzUvUiv/z8w5Z/2/DOwr8 X3oU/g//93ZYVOf/WP9vT6vwf5mfD/B/iTsQ/5cYhf97i8L/4f/wf8tRZ/u/32/sx//t9X+h j57m/yTjPr+sW1v/L7TK92C+zf9Vuf6fGtf8n4yp4v8WDva5/2P9v1T/13fF/J+tcv2/cc3/ +aGN29NPytSiu/+TC0+zuv6f/EXf6f/c5XbB/7VDdv/njkD8X8wOVPg/VcT/NR7t1eb/xK3h /zb1mBb8X9cNXTH/J63C/234rPB/Kqp3e2n/N+D/8H/4v+TDAv+H/3tv1ev6f9o/gmjt55vs XP/vaRuPqLr839jV6P9mKO8s/9d0gxus7QazN8rBv+63uv2XccL/ZWkV/u9r/d/gHwjyrv9n 8X+U6HL3f/rAjDj/18v6f/pH4f+OL+4sx//Fj3vj/9Jbhf9L6Fac7v+k41vC/4XRTPzfhsPi bP9nW/xfov+bvw8/eP0/P++Q9f82vKPA/6VH1eb/mhH/lxpVn/9j/b89rcL/ZX4+wP8l7kD8 X2IU/u8t6tv8n7ypxf9FReH/vtP/NWHGHv5vp//T0j2Taq//C5Nb73NcmzX/d/93v6Uv83+T rtD/ra//F25P+L9/+7+w+hr+D/8X4f9aHXbrTv83v1qs+r/Jz74xTSeb3zm1KLxTkR1k1vxf Gzq2sp+r8H+mmbrc/s99Vvi/mB2ozvN/7sJ0Hf8nXWj838LQD/4P//fXrNur+b/w4FuZ/zPN o8L//btvgf/D/61E4f/wfytRT41S06PaHTU9VR/g//xTZaj2+r/5Nh5R+D/830Krnv2fafTt wdf5vzbF/7nniVAp9buqIf4P/7fQqlf/1ze5/V93vv9rp+z+z7UK/0eJLHf/Zw7MiPN/Vvxf +6Pwf8cXd5bj/+LHvfF/6a3C/yV0K0r5P7Pq/+T1WAn/14UXNFlR3rL/66cDoq7k/8ZJ4f+2 RZ3v/9zTB/5vyzsK/F96VG3+T0/4v9Qo/N97Fv4P/4f/W43C/yW0Cv+XGHUp/yfHG/4vKgr/ h//7HVK9lP8LE/JL+L/uvgiS3xL+b+0Q7Lvz1/8TJYL/WxhPwP/l9H+jvpT/M9n9n1lb/28s 5//up7Ds5y/zf+5yu+D/bJ99/b+P8H9hvnQJ/xe6R1/p/4y21/J/MuX4K/2fNvi/b/F/7rO6 lP+TqUxF/J+c4kX8n1xbS/i/Jry4K7H+3336jNr/gIr/w/9tjsL/4f/WolZaVZP/C59ckv+b beMRdab/s/5GZfzTx17/N9+G6+XW6P8Gg//L0qoX/9d3twdU3fYBzO30f26GQajkWRj/l6NV 1/B/XZfd/5ka/V/L+n+U+HL3f+2BGXH+bxD/1/8o/N/xxZ3l+L/4cW/8X3qr8H8J3YpC/u8e dar/k2F8/N+Gw+Js/zd0+D/8H/4vrVX4v2/wf53F/6VGVej/Rvwf/m99B+L/EqPwfwmtwv8l Rl3K/w3++Mb/RUXh/77U/4Xm4P++wP/Z5lHh/9YPwXY8f/0//B/+j/X/8H8b/Z9cJqryf0Of ff0/N98H/xezA9Vp/u9y6/91UuH/Xod+nv2fxf/h//y+eJp1a/F/+D//GTXz6mr+zz6q3f7P ziv8n8L//RG10ir830aUh//L6P8aLb0du/8a+LyNh5Sry//Zpkb/d18p7zz/Z4fbs4Dzf4PZ G6Xt1Ey/lZIhEvxfhlbh/3b6v09Y/8+/4Gb9P8rJ5e7/ugMzovxf14j/a34U/u/44s5y/F/8 uDf+L71V+L+EbkUh/+deMy77v0POq2X/J5isjP/rD4i6kP8bHbMxnW32R2l5XxMqH3Up/9ce ELXi//zIc07/1zX4vwytwv/h/15bhf9LjGL9v9io1z2I/8uwA/F/iVH4v4RW4f8So/B/kc3C /90r/N8n+z81ynUc/7fFUyz6P13O//1OlfVb+jL/Z7ti/k/r89f/C4cb/g//Nyus//dx/q+1 H+D/wkdXlf8bu9sxkNf/6U9Y/y+M+uP//vB/7hS+kP8T8VeZ/5O7R1b/117K//XuGpnV//mD /UL+b5TOWQn/FzBZCf8X+ixF/F+YoJXk/6Q5f/o/6bOU8H+yyl0R/yfPwvg/hf+bN+q4KPwf /m8l6qlR92flmvyfmqTPPtmEfuDTNnw/sEL/1401+r8ZyjvJ/w3j1Hj/J2M3e/3f8FupD1n/ L/vg9yf4Pz86h/9bmqT65P8+YP2/0b1Nwv9Rzi53/9cfmBHn/7T4P/Oj8H/HF3eW4//ix73x f+mtwv8ldCuu5P8aK38K/u/Pw+J0/zfi/y7s/1j/D/+3GlWZ/1OTwf+lRtXn/1yPCf8XG4X/ y/x8gP9L3IH4v8Qo/N9bFP4P/4f/W4463/+FQTP8327/Jw+kGf1fa1n/LzLqA9f/C3PL8X9v 4wlz/9da/B/r/yn5f+bVxfxfuAHIfq7D/w3NiP+7sP+72Pp/3+z/vL4q5P+ma/k/91nm9X+2 Rv/nBSr+L64b08yrVf8Xtlti/T/TPCr837/7Fvg//N9KFP4P/7cS9dSo+7NyVf5vDL/tb/I7 o5628Yiqy//dVzXE/+X1f67T7v2ffEh7/Z/9rVx3usf/ZWkV/m+f/2ttg/+LjML/VVru/s8e mBHn/4z4v+5H4f+OL+4sx//Fj3vj/9Jbdar/C50n/N8f/q9Z9X/Snyjh/3SgiPi/Pw+Ls/3f 5GwM/m9T1Ir/OwKJrPg/t0/wf1veUeD/0qNO9X+tTOfIuf7fOOH/UqPq83+s/7enVfi/zM8H +L/EHYj/S4zC/71F4f/wf/i/5ajz/V/ADfi/b/B/7aPa7f/0vFrzfwH+ZfR/2ppL+T8rZxH+ 79/+72rr/8mHlNH/6WYs5v/Utfyfye3/Wrvq/0LHVvZzHf6vsU12/2c+wP8N8iEV8H9qut86 ffVl/k/rS/k/QVr4v/ehn9P8n+nwfws7EP+H//OxEU+Nr/O+T/d/VnY//g//h//D/y1ErbSq Qv83pkS9Pnaf7v+a6VHt9X/zbfgeU4X+b+xq9H9mONv/NbcHLO//TLc3ysG/9reaRZ3q/+SJ rzb/588X/N/CJFX9VJ3v//xnldf/dR3+jxJb7v5vODAjzv+14v/sj8L/HV/cWY7/ix/3xv+l twr/l9CtKOT/THe+/9NTeDuN//vzsDjd/7kvo6vQ/81fUuP/8H8LrcL/fbL/M/KCNqf/s6z/ F31evR0W+L+3LPwf/g//txpVmf/rO/xfpij8H/7veQ/i/9KjLuP/wntT/N9u/yfbLeH/+uBr Wr8l/N/aIag1/i9yB7L+35f6v1s/qMb1/2yN/m99/b+w/MJ3+j83ZW/B/7WTze3//LeYX8f/ 6bB6QAH/17vzNav/M9ri/yJbdZb/06ac/2sv5P/6qcvu//xQ+6L/e1qYdK//e32Ww/9F7sBL +7/2Ue32f3peXcv/6aZ5VDuvgU/bUAr/p/B/f0SttAr/txHl4f9y+j953pZqr/+bb+MRVZf/ myz+L0urXvxf2/SDG6wNJ9Q+/ze6IdJQybMw/i9Hq/B/O/2fOd//9e6+m9X/ufFA/B8lstz9 33hgRpz/67z/65ofhf87vrizHP8XP+6N/0tv1bn+L7x6x/+9PVpt839yWBRZ/0++OaSM/+sO iLqS/3PvKPB/m6JW/F+TIap5iVr2f3LM5fR/t4d7/F96q/B/+L/XVuH/EqNK+b8R/4f/W9+B +L/EqMr8H+v/4f/+EYX/S/mw8H/pUZfxf2HGHv5vp/9T4msS/Z908f7yf2E6S5r/C9ea4v5v nCr0f2pc8389/m+L/3MPjvi/qM/qEuv/lfN/YQVK9VbE/+mpD7fIJP/X3qNW/F8YTpD9fKj/ 863O6v9c1JL/a7Kv/+e/xfxs/xfmS9fl/8yU2/+5G/6F/J9MVP5S/6cKrv93Mf/nrpF5/d94 uv/Tk7/l5vR/7rNa8X9yRSrh/56u7Mf6P3ltUsb/yX2whP/Tob+d8oC60f/JTaaI/5PDosz6 f3IMpPi/p20ohf9T+L8/olZahf/biPLwf/n83+2WOD6qfVHP23hEnen/5JgTBrjb/80nqarB nO//ZOglp/+bobyT/J/uWvF/T/3AaP83/lbqI/xfKxO4qvN//tDD/y1MUv00/zdm938uCv9H iSx3/zcdmBHn/3rxf+ZH4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n96/AD/J6+M8X8bDouT/d/k vyIY/7cpCv/31ir8H/7va/zfOOH/UqPwf+9Z+D/8H/5vNQr/l9Aq/F9iFP4vsln4v3uF/8P/ 4f/UH3Me8X/f6f/W1//D/+H/alv/r6D/U/i/hSv7V/m/qcX/Xdj/+VP4Ov5Pi/jD/70P/Zzm /9xnVZ//O3/9vyP834j/w//5z2iT/7Py9dj4v4WbCP7PV/i/rVErrcL/bUR5+L+M/m/wzwWh 2un/nrbhfqhG/9eN+L8srXrxf8PtCdb7vzA6t9P/2d9K4f/wf2f7v/F0/9dpPykQ/0c5uQT/ 1x9p7eL8n/X+r21/FP7v+OLOcvxf/Lg3/i+9Vaf6P2kC/u+PR6vbT674P+n4FvF/vf93/N+G w+Js/+c3UaH/C59lCf93RNSK//MTivB/G95R4P/So/B/+L+3wwL/95aF/8P/4f9Wo/B/Ca3C /yVGXcn/2cZvGP8XFYX/+1L/J49T+L8tnmLR/wnt0L5Hsdf/teGsDF3qNf8XnsT8yODe6ZVP 3fZZq2ryf7fexfn+T45s/N8f/s/g/w5a/0/mAef0f7ZG/9faYv6vtWv+L3DsqvxfN9o6/Z98 pHX5v949DOD/FqO2+T9BL1/q/1SV/k+bCv2fu4ng/xI/q0v5v/5R4f+eDov2qcL/4f/+iHr6 sA6Lwv/h/1ainho1f2Sux//55209DPv7gc/b8OMW+L/3qAz+L4wiZPR/buz2XP/Xmtvd3fm/ rtsb5eBf+1vNos70f9kHvx+HBf4P//feqlf/55/h8H+Us8vd/+kDM+L83yD+r/9R+L/jizvL 8X/x4974v/RW4f8SuhWF/F/3Af6v1eX8X5jqiP/b6//cSDf+b1NUhf6va/B/GVqF/8P/vbYK /5cYVcr/Gfwf/m99B+L/EqMq839zlIf/w/+9ROH/Uj4s/F96FP5v+8GO/1Nl/J98JRj+b8Mh uOz/wqdjUy4XYQaMVO6b4vB/ca3C/+H/lo7AC/i/pkr/56bsvfu/1pgO//ct/s+6kay8/s8t TIr/i2rVFfzfhP9L8n+mq9L/Gfwf/s9/Rhf2fwHtJfm/p20ohf9T+L8/olZahf/biPLwfxn9 n7x2DtVO//e0jUdUXf5v7PB/WVr17P/axt46Z87/yTPVXv+nfyv1Gev/4f++xv/52al5/Z+p 0f+5AVX8HyWy3P2fOTAjyv/1jfi/5kfh/44v7izH/8WPe+P/0lt1rv8Ld1783z8frdb93yHn 1fL6f2G5bvzf5/s/4656Ffq/cIqX8H/tAVEr/k/mP2T0f2bE/2VoFf4P//faKvxfYlQh/+e/ lBj/FxmF/8v8fID/S9yBy/7PfzD4vy1R+L+3qG/zf9KVxv9FReH/vtT/hZnR+L+9/q+XsyjJ /4Ut4v++zv+Nq/5PWoX/w//NygH+r7Ol/J82Nfq/cASqtxL832hT7vh3/3e/8Kz4vzADrSr/ 1zZjdv9nPsD/PTGbWvxf/vX/3JzHK/k/f7h9q/+za/7Pd96y+r+uL+b/THey/7O3Pl+X2f/5 g33R/w1yXlXm//qgHuUvOtT/9XPZfaz/C+drCf/XlPN/YVH0Av6vlw5BEf8nhx7r/yn839OH dVgU/g//txL11Kj5I3M1/m/wnTc9DO3uqOdtuF5ujf7v3ir8X17/d2uHwf+tDH6/9gPxfzla dQn/1xvXDtb/o5xd7v6vPTAjzv9p8X/mR+H/ji/uLMf/xY974//SW4X/S+hWFPJ/7j0t/i8x 6kr+b8L/Xdj/sf4f/m81Cv+H/3s7LKrzf+6L2fF/sVH4v8zPB/i/xB1Yyv+ZAf+XKQr/h/97 3oP4v/Qo/N/2gx3/p/B/S6/Vm1lV0v+5OSSnr/+H/9vk/0b8X5r/0xPr/0VGneX/XFSF/q/v lvyfmaamyvX/8H/b1v+7HRb4v7hW4f+y+r/T1/+zunMnEf5vKQr/h/9bOoU3+T/b1uj/WP8v Mgr/h/9bi1ppFf7v34/dJ/s/Nfhnj9vTd78/6mkbrjtYo/+7twr/l9X/3boRt3bg/xaj8H+/ 1Xf5Pzel/ez1/8bs6/+58UD8HyWy3P1fd2BGnP8z4v+6H4X/O764sxz/Fz/ujf9Lb9W5/u+I qcQV+r9m1f9Jf6KE/+tCvw3/9+dhcbb/a91hg//bFLXi/45AIiv+z20c/7flHQX+Lz0K/4f/ ezss6vN/Bv+H/1vfgfi/xCj8X0Kr8H+JUfi/yGbh/+4V/u+z/V9oDv5vr//r5PFIJnbs9X/y 595fmI4r/u8+NdLP5Nzr//p5Vaf/e7TqcP+3vv6fNAH/94f/Y/2/NP+nbF/M/6k1/yevXvB/ C4fF3P+tr/8XWl2T/7slZfd/91a9f1gF/V/4Uyrzf+5+ldf/3Z7xr+T//Gf1rf5P4f8O8X+d Hrpi/i98lrX5P7l7FPF//WwHHuz/5O5ewv+Fq1AJ/6fHR+MO9n+yt4r4P3lSYf0/hf97+rAO i8L/4f9Wop4aNX9krsX/3a5b+lHtXP/vaRuPqLr831304P+y+r+2sXrI7P/8EMnZ/s/IhOLK /J/vleH/Fh67P83/9dZdA1n/j3J2ufu//sCMOP/Xiv+zPwr/d3xxZzn+L37cG/+X3ir8X0K3 opD/M935/q9t8H/f4v/8oDr+b1MU/u+tVfg//N+3+D/3TVb4v8Qo/N97Fv4P/4f/W43C/yW0 Cv+XGIX/i2zWs/+7He34v8Qo/F9iFP4vNgr/96X+r+D6f2v+T4cm4P/wf7NS6fp/+f2f/QD/ N+b2f+vr/6lv9n/ucrvg/9reVrn+H/5vm/8bNf4vslUXWP9PN5fyf8ZdI/F/S1H4P/zf0imM /8P/bY3C/+H/1qJWWoX/+8dj9/n+T42NrOzaJ/QDn7ahKl3/D/+X/rZxyf8ZN5O4wvX/6vR/ E/7vW/zfkH39v9tP4v8oseXu/+yBGXH+r/P+r2t+FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FIf/n ZnUs+z85LGrzf7Y9IOpS/s8dCPi/LVEr/q/JENW8RK34Pz/ynNP/9Qb/l6FV+L8v8H+s/4f/ W/B/bngJ/xcbhf/L/HyA/0vcgaX8X9/h/zJF4f8y+z8Z0GL9v6go/B/+73dI9VL+L8xbSPN/ j8FzV9k1/zeb3bzb/9l5VdD/WVOj/zNr/s/IOAX+D/83Kwes/zeZUv5Pmw/wfz7j9igS3s/t 83/trHKmbNH/Tf4UNr1OwUNhHnSYi7Pu/8JwQhuSf//7N/i/5fX/zDjU6f/CfOm6/F/n+i9Z /Z+b83gh/9f4mZ5f6v+0WfN//hjIuv6fGxHE/0VEvfo/u+b/ejlCK/N/969k7sIeVcf5P/nt Iv4vXIWK+D+JKuH/gmos4f+acv5P+oll/F8YG3HVbv8324ZS+D+F//sjaqVV+L+NKA//l9P/ Sa9Mqr3+b76NR1Rd/m8w+L8srXr2f7dPyvr1//qu2xul7eQegkOl1Ees/ycnQ3X+z7ejMv/X N7n9nxt6PNn/tX329f/ceCD+jxJZ7v5vODAjzv/14v/Mj8L/HV/cWY7/ix/3xv+ltwr/l9Ct KOX/DP4P/7cYtez/LP4P/4f/S2sV/g//99oq/F9iFOv/xUa97kH8X4YdiP9LjML/JbQK/5cY hf+LbBb+717h/z7a/4XpFfi/LZ4C/xd1XFxh/T/8H/7PbwT/V5v/G72NMZ2eHUTRd3wr56aA k0r936gX/d/U4v8u7P/cMz7+L65V+L+s/s99Vvi/tGe5Zf83Zvd/7mEY/xfXjWnm1cX8n8X/ 4f/wf1miVlqF/9uI8vB/Gf1fePEy+kvszqinbfgeU4X+776qIf4vs/9zD8HO/6Ws/ze5/kuo 1Ges/4f/+xr/13W5/d8HrP93hP9j/T9KfLn7v/HAjDj/Z8X/dT8K/3d8cWc5/i9+3Bv/l94q /F9Ct6KQ/zPdqv8TKVTA/5nRn0Rl/F9zQNSF/J9/u4P/2xT1b/+X9RqI/4uMwv/dK/wf/m/h x/B/+D8p+D/8H/5vt/8zA/4vUxT+D//3vAfxf+lR+L/tBzv+TxXyf3I5wf/9fQiW8n/jiv9T kxzZ+D/836wc4P9sX8r/zVDey3Wpz+7/2ov5P7lMVOX/BtPk9n+3+9H5/q+XqCL+T870Av6v d3fpvP7PXQOv4//kvRL+b2Ho59n/Wdb/S/J/7rNa9n92fmH6Nv9nV/2fPEyV8H/hTynh/8Lj Qwn/F24iJfyf9KiK+D/59+r8n3lUu/2fmVf4P4X/+yNqpVX4v40oD/+X0f+F9y/Wtvujnrbx kHJ1+b861/+bobyT/N/tqNEV+j8j14fa/J8Md+P/Fiapzv3fR6z/5ycFsv4f5eRy93/TgRlR /s824v+aH4X/O764sxz/Fz/ujf9LbxX+L6FbcSX/J19whv/bcFic7/8ad9D0w/4oNyr1qHwU /i8yaulqUcL/2Q7/l6FV+D/832ur8H+JUfi/2KjXPYj/y7AD8X+JUZX5P9b/w//9Iwr/l/Jh 4f/So67i/8Lhhv/b4imW/V+Ys13C/4VOJ/7v34fgB6z/h//D/9W2/l9J/zet+T+T3f+Zcv5v XPV/skNr8n9t09e5/h/+b5P/czd8/F9cq07zfyP+71v8nzPQV/J/vf9givi/Qc92IP4P/zdv Ff5P4f/mjTouCv+H/1uJemrU/JG5Gv/XyzRE6+9XO6OetuF+skb/11r8X5ZWPfu/ttG3q573 f7ujHPxrfqtZFP4P/7fQqmv4v861A/9HObsE/2ePtHZx/k97/9fqH4X/O764sxz/Fz/ujf9L bxX+L6FbUcj/udchp/s/mTuI/9twWJzu/9xIN/5vU9T5/s/9O+v/bXlHgf9Lj6rN/1mD/0uN wv+9Z+H/8H/4v9Uo/F9Cq/B/iVHX8n/+B/B/UVH4P/zf75DqpfyfyIQy/i9MjcT//fsQvPUu zl//T7aL/8P/zQrr/230f6vr/2X3f60t5v9c1Nn+r/H92qz+rx0W/V+bf/2/j/B/YdQf//eH /+vstfxfI9U3+j/3hbcV+j/TVej/XJdzxf/NL0zV+L9BpjKV8H/y20X8n7w2KeL/wnZL+L8m dJVatf8BdaP/kx1YxP818nhQwv+NYXZziv+bb0Mp/J/C//0RtdIq/N9GlIf/y+n/5DKe5v/m 23A/VKP/Y/2/9LeNS/7P9INf/6+TQ2+n/3PDm6FSH7L+X/is6vJ/8jIE/7cwSRX/h/+jLJS7 /9MHZsT5PyP+r/1R+L/jizvL8X/x4974v/RW4f8SuhWl/J/5AP/Xh7fT+L8/D4uz/Z9He6br +/1XC239k2KofBT+LzJq6WpRwv+x/h/+bzWqNv/XjPi/1Kj6/J//UmL8X2QU/i/z8wH+L3EH 4v8So/B/b1H4PzPg/1Kj8H+JUfi/2Kiz/J/pavR/twfHUv7v0arD/d/6+n/4vy3+zz044v+i PqsX/3frXOD/4qLOWv8vMJva/J/tlvyfsW12/+euFqf7vzBdVaq9/u991m11/m9or+X/eqnw f69DPxde/08Pbgdm9X/d+f7PCInK6v8U/g//5z+jK/s/1v/D/+H/8H+rUU+Nmj9FVOT//G9b 3znb7f9m23hE4f/wfwutevZ/ph+7Ef+3Mvj92g/E/+Vo1fH+z4+cne3/3HAW/o9ydrn7P3Ng Rpz/a8X/9T8K/3d8cWc5/i9+3Bv/l96qU/1f6Dzh/77A/1mhGyX8Xz8dEHUl/zfh/y7s/1j/ D/+3GlWb/xsn/F9qVH3+z09KwP9FRuH/Mj8f4P8Sd2Ap/2cG/F+mKPxfZv8nd0XW/4uKwv/h /36HVK/l/2azbnf7v/GpWvN/906nn8m51//186qg/yu4/t8n+L/wlIj/+7f/Y/2/RP/nXC3+ Ly7qLP/nRkmu4v/U1PV1rv+H/9vk/26fAv4vslVn+T/XjcH/RbXqNP/nFpGtz//5IxD/F9eN aebVJ/g/EwZHWrX/ARX/h//bHIX/w/+tRa20Cv/315PIqf7v1hsbHtW+qOdtPKLq8n+Txf9l adWT/1NTq3u//p882u/1f+7ZIlTqI/xfG75wDf93Rf/3Cev/WfcMl9X/uSj8HyWy3P1fe2BG nP/rxP8NPwr/d3xxZzn+L37cG/+X3ir8X0K34kL+z315qsL/LUa9HhZn+7+hHxT+b1tUhf5P sf4f/m8tCv+H/3s7LPB/b1n4P/wf/m81Cv+X0Cr8X2IU/i+yWfi/e4X/+2z/J9Pz8H9bPMWi /wvCA/+H/5tnWflg8H9/+L8R/4f/U/L/zCr837f7PzsNRvzfsP9yOzV+z4UK/7fjcrvN/1l3 ZOf1f+4aiP+LahX+D//3/mr42f+5tRrxf4mfFf5PxT2gvs77xv9FRuH/jojC/+H/1qJWWoX/ ++tJ5FT/Z+QBNVT7op638Yg60/8N8sGk+b/Q4cf/Hej/7DAMbtyiNc3uKG1t3/xWCv+H/4vy f6bJ7v/G0/1f17p24P8oZ5e7/+sOzIjzf733f53+Ufi/44s7y/F/8ePe+L/0VuH/EroVF/J/ pve9JPzfhsMC/xfZqiv7P/9Uktf/Nfi/DK3C/+X3f2HCI/4P/zcr1ncA8X+b9iD+L8MOxP8l Rp3q//ylH/+3JQr/9xb1bf5PHqfwf1FR+D/83+/T8LX832zW7W7/91Bi/ifX/F9QIkn+T16+ /uH/zCiTBUr4v/C2oIT/02HSe8rlYqP/6+XiWpn/kwkJ+L+Fg32b/5MLbRH/18kOLuH/2kY+ y+P93+APvTL+r/NRrUmZWnT3f2IxP8H/+ZO2gP/rh/b22/p2sW1S1v/zSziE6jP8n9x3S/g/ FQZQ0/xfuNP/2/+5OY/4v+Wobf6vaX1Vwv+5K1JW/+eu7Iv+r/UZWf1feyn/Z91L9az+T49r /i+0uoD/a3wTCvk/mThfwv9Jnz3R/8ll4k//J3f3Ev6vkSO7hP8LrSrg/3rpWJXwf+GGX8T/ jWF2c4r/m29DKfyfwv/9EbXSKvzfRpSH/8vo/6zv/YZqp/972sYj6kz/Z4P/M/ujdOhidfcv oDnf/8l3I1Xl/27Pwrcbvr59UqbbG6WtdtN3Q6U+xP9p+azq8n/S16zL/xnrupzV+b/JXSbw f5Szy93/9QdmxPk/K/6v/VH4v+OLO8vxf/Hj3vi/9Fbh/xK6FZfyf+EFDf7vz8PibP83+gMB /7clCv/31ir8H/4P/7fYKvxfYlQp/2fwf/i/9R2I/0uMwv8ltAr/lxiF/4tsFv7vXuH/Ptv/ yeMU/m+Lp1j0f32O9f+CKfsc/zeIbijh/5r50EU9/k/+Hf/3h/8zF/N/8hSX5v/knP/L/8mA TRH/Jyuk4P/eoz7P//nzroD/66bBGnfRGxIm4UyN/+VQXc7/hdeRBfzf6F6i4v8Wozb6P3/3 wP+9D/3g/3L6P/dZVej/Rvwf/s9/Rvg//N/WKPwf/m8taqVV+L+/nkRO9X9t4wdUQ7Uv6nkb jyj8X27/J13SqvxfZ8fbk6k2t+eVbm+U7nt35QyVwv/h/6L8X1Oj/+v92yT8H+Xscvd/9sCM OP83iP/rfxT+7/jiznL8X/y4N/4vvVWn+r8wZ7su/6f9d5jn9H/t2J3v/6RPiP/bcFic7v8G /N/X+D//VI//2/KOAv+XHnWu/5M3mvi/LVEX8n++x5TT/7UN/g//t74D8X+JUaf6P3+OZ/V/ c5SH/8P/vUSd6f96IVH4v6go/B/+7/dp+FL+L0wL9PMR9/q/oPHur9VX/V94ceoP873+z8yr Vf8nf1FO/6fHZf8XJn6U8H/yTXGF/J8cbpX5P3kkyOj/3IPjlfyfnqO8ff5PTfLHhw9hzf+1 8qfk9H/tiv8LiiSn/9P9mv9zf0pO/xdUo3oterQ+KqP/cwf76f7Pt7qE/7vtuNZd9JqEGWdT 47FrqD7D/4VOfQn/F+4Yodrp/0Kn4nfoZ9H/TbbH/208rxb9X+Ovs0X8n5n801tO/6fW/J8/ Hgr5v3BYJPm/2TbUJ/i/wd2o8vo/ter/5E8p4f/kUlTE/8kdtIz/s7MdeLD/kyYU8X/SkSjh /8KIUgn/JwvrFPF/klHG/8m/e8K32//NtqEU/k/h//6IWmkV/m8jysP/ZfR/bd89qp3+72kb j6gz/V8vG6/L/5kpmLKUqE/zf01jWzdcHXrQu/xfN7bNb6U+w/+FJ9PK/J+fm1CZ/9N97/uz Of2fOd//9W5UCf9HObvc/d9wYEaU/7v9d+//mh+F/zu+uLMc/xc/7o3/S2/Vuf5Pejj4vy/w f+EFLf4P//dU8H9p/s8PaeL/tryjwP+lR+H/8H9vh0V1/o/1//a0Cv+X+fkA/5e4A1f8n5+P iv/bEIX/e4v6Mv9nZRIT/i8qCv+H//t9Gr6W/wujZkn+7/m1+qr/M4/E3f7vbX7qsv+T6eEF /J9u5IP5Sv+n1Jr/k48O/7cwnjD3f1db/y88Lufzf7efXPF/3TzqWP8XPsuv9H/tmv9r/OXY 6DDwtdP/ze4O/1j/LzilEv7Pw+Ss/s9Fvfu/fugG5/9ujd5/BI6Tn8YeKv9ZXcn/TTn8X/iQ /un/+sZNKs3q/7Q1V/J/ssxWEf/X6WL+rzPZ/Z/6y//JQZTm/37np57r/3o7Zfd/7iay4v+k 1fi/RP83pLyquD9fPe7CV/J/crgV8H9hlK6I/wtHIP4P/zdv1HFR+D/830rUU6PmTxHV+L/O tyNUO/3f0zYeUZ/g/xKifv1fGNxuzvd/4RZfk//rO3PrnN2eDXp5ptrn/3o38BMq9SH+T4ZQ avN//nypzP/5a3l16/+NGv9H+YBy93/jgRlx/k+L/zM/Cv93fHFnOf4vftwb/5feKvxfQrfi Sv5PXk7g/zYcFmf7v6nF/32N//NDFvi/Le8o8H/pUbX5P2vwf6lR+L/3LPwf/g//txqF/0to Ff4vMQr/F9ks/N+9wv99tP+bwqAZ/g//NysF/d99HbPv9H8W/4f/8z9/lv8b9Zr/M7OoLP5P rfo/uX1k9H+zz+op6gD/1yz7PzX6eSqm0Unr/8nxYP023MF+uv8b5PvvDvd/QzOJ/+um/Zfb cfIvpUL1Eev/aekkhWqv/5ueqhr9nz+Fr+T//Pu7L/V/tkr/d/r6f0f4P9Ot+r8Af77S/5lV /yfTfEr4v6dRm2P9X+izlPB/Ybsl/J8O/W3/eulQ/zfICVXE/8lIYxH/J+spSbX3GjjfhlL4 P4X/+yNqpVX4v40oD/+X0f9Z30cK1U7/97QN919q9H/diP/L0qpn/2eHrnP+rxvs7ijdeWYX KuUH6U73f/Kn1Ob//AKLlfm/ZqzS//lp0vg/ytnl7v+mAzPi/J8R/9f9KPzf8cWd5fi/+HFv /F96q871f9LquvxfI9+WldH/mXH8AP8n71jxf/i/p4L/w//h/5Ki8H8x5xX+77fC/635vxH/ h/9b34H4v8SoU/2fv/Tj/7ZE4f/eovB/+D/833IU/i+1Wef7v/Dy2O+gNP+nx5eoV/8Xvr4t yf+ZeVXO/6lJr6z/Z2bT2Cvyf/LB4P/+8H/jNf2f3zWJ/k+qNf/XNeX83/TN/m9l/b8j/N8n rP9n3UFVwP+NtyPP+z+TMAlnnPwvh+p6/k+2+53+zwzX8n/+mPtO/6dH/N+3+L/bgbbi//rQ IajL//Xl/F+YAFHE/8m1tYj/k/tgEf8newv/t9v/tY9qt/9r5xX+T+H//ohaaRX+byPKw/9l 9H+D702Eaqf/e9rGI6ou/zcY/F+WVj37v1HL+n/tkLL+n1++I1TqM9b/w/99jf8bhgr9n9Ws /0f5hBL833CktYvzf633f23/o/B/xxd3luP/4se98X/prcL/JXQrSvk/s+b/pONbwv/pYDbw f5/u/243ej/8XJ//G2bVwf7viKhS/q+1+L8MrcL/4f9eW4X/S4xi/b/YqNc9iP/LsAPxf4lR p/o/37nA/22Jwv+9RX2b/5NnfPxfVBT+D//3O6SK/3P/gf9r5tW6/wuzWqQ5OfyfGU73f3ez gf/7t/8L+uoy/q+RC22a/wtTIP7wfwL/Svi/Toc5Jl/p/z5i/T9pTgH/p9tS/q+xrfN/bZiq v9P/+V8Ilb/cXsj/Pd9E9vq/16Ef/F/kDtzm/8K4Ujivdvq/fl6V83/qI9b/6x7Vbv/Xzavz /d/gl0TL6v/8wV6f/xvX/N8gD1OVrf8X3qZVtv5f6ImZlAfUsIpl93sXxv/F7UD8n1T4v61R K63C/21Eefi/jP6vHbRUZnfU8zZ8P/B0/yff6SHVbv83zKrfVp3o/1rpklbl/4bh9hjsvsjF ytDdPv/XuCk2oVKK9f/wfzH+zy9civ9binryf25AFf9HiSx3/6cPzIjzf534v+FH4f+OL+4s x//Fj3vj/9Jbda7/C3de/N/bo9Xc/2m76v/k9ViJ9f9kgBP/t+GwON3/DXX6v/BZ4v/eHq26 WeVfnuL/kluF//sG/zdO+L/UqAr9H+v/4f/wfy9Rtfg/36/F/22Jwv+9RX2b/2v8oZ3T/+kW /5cahf9LjFr2f2P4xn78317/1+Xwf7KNP/2ffVTf5v+0Hov5v0erzvN/Bv+3xf+5N/j4v7jP 6tn/9R3+LzIqZv0/Pck7n0T/d7+cnu7/mtFtPKv/08v+z/R+/b+2TTgCx9F/3qH6bdX7h4X/ S/N/2v21ef2fO4Xxf3FX9pP8nzZV+j/3WZ3t/wb83yb/t7r+3+g/mCL+L7zPHefzvqP939vz Ff4v7hTG/+H/tkbh//B/a1ErrcL//fux+2z/Z/yNtZVHkJ3+72kbbmCiRv9nm9P9X3glnNP/ 6fZs/zfZabrd4fU4mL1Rt+6du8aEyv8Q/i9Lq67h//o2u/8z5/u/ps/u/0b8HyW63P2fOTAj zv/13v91+kfh/44v7izH/8WPe+P/0luF/0voVpTyf80H+D/ZWzlRnsX/HeP/dIv/u7D/60b8 X4ZW4f++wf/dbo34v8SoCv0f6//h//B/L1H4P/zfwo/h//B/S83C/+H/Fn4M/4f/k/LN/u+2 EfxfZNTbEYj/UzHn1SX8n1tmq5D/s2v+b8D/Jfq/MJIcpm4f6P/kwlRg/b+pn2T9v9Cl3en/ /CU7VH4Hnu3/wumH/3uNevV/Dibj/+Ku7Gf5v3HN/43f7P8+YP0/r4by+j+75v+e+Nq3+b/V 9f/wf/g//B/+bzEK/4f/W4taaRX+79+P3Wf7P3kt0crkkZ3+72kbDymH/8P/LbTq2f9NZhpb 5/8aGc7a5//G0f5Wbjjd4v+ytOoa/q8bsvu/89f/66cJ/0f5gHL3f+2BGXH+z4r/a38U/u/4 4s5y/F/8uDf+L71V5/q/I6YS1+f/utX1/w45r5b93/3tdFaUh/9LjFr2f+7ZtUL/F07xEv6v PSBq2f/5mQRZ/V9r8X8ZWoX/+wb/Zw3+LzWqQv/H+n/4P/zfSxT+D/+38GP4P/zfUrPwf/i/ hR871v+F96b4v93+T5pdxP/dxxv8lr7M/026mP9z37Zcxv+5ZUsW/Z8Ko9H4vz/833hJ/yeX 3UT/J9UnrP+H/0v0f+Gj+07/5y63b/5PN7YdxP91+y+34+gHfUP126r3Dwv/l+j/3ONUXv/n YPKF/J+W4cbv9H+r6/99tf9T56//l9//uc/qUv5PREMJ/ze0sx14sP+TVhfxf3IfLOL/wnUW //d33wL/h/9bicL/4f9Wop4aNX9krsX/mUH6s4N3//uinrehKl3/bzA1+r8ZyjvF/+mma279 F8f/bLc3SrdjP/5W7p/1+f4vvJrI+OV3+L+j/J+u0f9Z99v4P8rZ5e7/ugMz4vzfIP6v/1H4 v+OLO8vxf/Hj3vi/9Fbh/xK6FYX8X9t9gP/rjkB5+L/EqEX/Zzr834X9n23wfxlahf/7Bv/X 9vi/1Kj6/J+bRIf/i43C/2V+PsD/Je7AZf/nJ4Fl9X9mwP9lisL/4f+e9yD+Lz3qIv5PN7MZ e/i/PzwF/i/quNjo/8ILhLrW/1Py6eD/FsYT5v6vtfi/r/F/q+v/WXky+Er/F1agVG/lAP9n V/1fcCth6vZ3+b/bEbjk/3TT5vZ/Tong/2J2oDrP/7lT+EL+z9sY/N/C0A/r/7H+31+zbv0R uOj/BOUV8X/hZl3C/4U+Swn/17D+H/4P/5clat6o46Lwf/i/lainRs0fmavxf71//2J635/Y 6f+etuF7TBX6v9ae7v/a8Lyd0f+5LxM6d/2/cbj1Z/XtPhVG5/b5v87+Vuoz1v/D/+H/TvV/ nX/Bjf+jnFzu/q8/MCPG/3Xu/9f69nD0o/B/xxd3luP/4se98X/prcL/JXQrCvk/M676P+lP lPB/9/kR+L8/D4uz/V/r9hb+b1PUiv87Aoms+D8/7zCn/+tG/F+GVuH/vsH/sf4f/s//1vP6 fwb/h/9b34H4v8Qo/F9Cq/B/iVFX8n/95Dec0/8pi/9LjcL/JUat+L/QHPzfXv/Xy7+n+b/Q l/7L/9lHVY//k41/5/p/6/4vzHLE//3b/wV9hf/7av8nLxC+0/+VXP9v1f8FCFaV/xs7ndv/ dR/h/+SDqcv/GXeEsv7fYtQ2/+f7cPi/haGfrf6vf1S7/V8/r1SN6//9w//N+Vo1/s/6D6bM +n/DbAce7P/kvCvi/8IErRL+T6JK+D/54qIi/k+uFvg/hf+bN+q4KPwf/m8l6qlR80fmavyf zFkxZtgf9bwNxfp/+L/N/k83tum183+2NXujdDu654lQqc/wf/19DCoh6vP8n+9I1+b//GeV 1/+Z8/2fxv9RPqHc/Z89MCPO/2nxf+2Pwv8dX9xZjv+LH/fG/6W3Cv+X0K0o5f8M/g//txiF /3uLurz/0wb/l6FV+L9v8H9Di/9LjarQ/434P/zf+g7E/yVG4f8SWoX/S4zC/0U2C/93r/B/ H+3/9Owb+/F/f3iKZf83PKrd/m+aV+v+b/Ykttv/tfOqnP/TesT/RUa9HYEV+r8R/4f/U/L/ zCv838KV/TP9n7vcLvi/zk7i/xLw0Dj64fpQfYT/C/AP//ca9eL/9Djh/yJbdZr/G/F/3+L/ bn1y/F/qZ3Ul/6erXP8P/4f/w//h/9ajVlqF//v3Y/fZ/q8306Pau/7ffBuPqLr839jh/7K0 6sX/aXvrB2rd9E/9wGj/1/5WCv+H/zvb/33A+n/5/Z97Fsb/USLL3f8NB2bE+T8j/q//Ufi/ 44s7y/F/8ePe+L/0VuH/EroVhfyftmv+TwUf+JX+z+L/jvF/nbvg4f82Ra34vyOugSv+zz19 4P+2vKPA/6VH4f/wf2+Hxdn+z49Ksv7fpj2I/8uwA/F/iVH4v4RW4f8So/B/kc3C/90r/N9H +7/7e1P83zf4P4nqZG75Tv/3+mGx/t9bVA7/Z6v0fzq7/2P9v0T/N+oa/Z8t5/+aT/B/YTgh TN3+Lv/nohb839QM3v81CUfgOPrh+lDh/3Zcbjf6P5eRd/0/B5Mv5P/8nivi//ys26z+73Zn W/Z/fffN/k+bk/2fbc2U2//5g33R/w1yhH6n/xvX/J88XxXxf6GvVsL/hWtrkfX/yvm/+bcJ VeT/xNQU8X/2Ue32f3Ze4f8U/u+PqJVW4f82ojz8X0b/1/nLrenN/qjnbfjebYX+j/X/0t82 Lq7/594AOv9nd0c5+Nf8Vuoz/J88luP//ngSedzwa/J/bujxZP83Nu5tUlb/56Lwf5TIcvd/ 44EZcf6vFf83/Cj83/HFneX4v/hxb/xfeqvwfwndilL+r6nS/6k1/yfD+Pi/LTPMF/3fgP/D /+H/0lqF//sG/9dZ/F9qVH3+zw0v4f9io/B/mZ8P8H+JO7CU/5ujPPwf/u8lCv+X8mHh/9Kj 8H/bD3b8373C/z29Vm9mVcn1//oO/xe5A8/yf63F/7H+n5L/Z15dbP2/cv7PH6EF/J/7OmPx fzbJ/+lHhf/bcbnd5v9adyblXf+v7S/l//xdGP+3MPTz7P/spfxf25fzf+Ocr32Z/3MKH/8X 1yr8H/5v6SaC//MV/m9r1Eqr8H8bUR7+L6P/6/24hrHd/mvg8zZcL7dG/3cXPfi/vP5vtNOA /9sy+I3/+xr/575n73T/534b/0c5u9z933RgRpz/67z/6/SPwv8dX9xZjv+LH/fG/6W3Cv+X 0K0o5P9unaY1/yeD0SX833gEysP/JUYt+r/eDQ3j/zZFne//3L9n9X+txf9laBX+7wv8n2ka /F9qVH3+j/X/9rQK/5f5+QD/l7gD8X+JUfi/t6hv838yjpDV/7X4v9Qo/F9i1KL/U1OYGY3/ 2+3/wsvjEv5P/mea/5OXr1X7v09Y/09mu+P/FsYT5v6P9f9S/V+59f+0wf8l+T/H11b8X3Ar 8od9mf+7HYFL/q/r2xr9Xzjv8H+vUa/+b5yu5f9kuLEy/6ez+7/2Uv6v0xX6Pz35duT0f6bp 8H+Rrbq0/5POG/5v4SaC//MV/m9r1Eqr8H8bUR7+L6P/a+UJv/M3gJ3+72kbtfo//QHr/8lw Vk7/N0N55/i/2218mlxXJsX/db3rmIRKfYb/a7MPfn+C/9M1+r9hyO3/1Ces/5ff/1n8HyW6 BP83Hmnt4vxfL+v/mR+F/zu+uLMc/xc/7o3/S28V/i+hW1HI/7lXwvi/xKgr+b8J/3dh/9eN +L8MrcL/fYH/Y/0//N+C/3Nf34v/i43C/2V+PsD/Je7ARf83+IM9q/8zA/4vUxT+D//3vAfx f+lR+L/tBzv+T+H/ll6rN/Nq0hWu/+dJFP4vqlXP6/81+L9v8X+K9f8OW/+vPv9nTIP/u7L/ u9r6f9/s/4RE/adeypf7P/dZne3/huz+z9bo/3SH//t+/2fwf/g//F9qFP4P/7cS9dSo+SNz Nf5PnnZCtdP/PW3D/eTp/q9tuke11/+FuU9hjGns8H9ZWvXs/0xze7JyVRgW3OX/+sZ3E6Ry 1xyD/8vSqkv4P+2v5Xn93+OGX5H/a/F/lPhy93/6wIw4/2fF/3U/Cv93fHFnOf4vftwb/5fe KvxfQreilP9rPsD/DeHtdD6UZ9f8nx1yR13L/1m/XHcXXvLs9X/9o/JR+L/IqKWrxbv/s+7m hP/b8o4C/5ceVZv/G1r8X2pUhf7P4v/wf+s7EP+XGFWZ/+s7/F+mKPzf5/u/Bv+XGoX/S4xa 9n/3QTP8317/N7WPaq//kwPpt7Ir/m8+u3m3/+vnFf7vKP9n53QD/7fq/yz+L83/TaaY/1On +z+t/ZHdhhGtvf5vfg10pmzJ/+neN6HVSXhI7g66+eVrK/4vjCSHe8l3+T93uV1Y/28wdfq/ MCiH/8P/zUGPTEQs4v9czy+v/7NV+r9PWP8vv/9Ta/5vuM8L99Hf5f/+sf6fHHol/F8/znbg wf5Pbk4F/J8KnfW61v+z0qko4v+CQC3h/8YM/m++DaXwfwr/90fUSqvwfxtRHv4vp//z11Yj j917/d98G6pS/zdZ/F+WVr2s/9c3t8NGm2566gdG+j8/xSZU6jPW/9NhlY9sg9+Pw+I8/9f7 3m1l/s8Yndv/+ZGzc/1fN7l2ZPV/rlX4P0pkufs/c2BGnP8bxP/ZH4X/O764sxz/Fz/ujf9L bxX+L6FbUcj/3S7INfo/hf87xv8NGv93Yf/XWvxfhlbh//B/r63C/yVGFfJ/ncH/4f/WdyD+ LzGqMv/H+n/4v39E4f9SPiz8X3oU/m/7wY7/U/i/pdfqzbwq6P8erTra/7mJ8/i/uFY9+T/3 4Ij/i/usnv2f7a+0/p9M+C7h/9Tk0Z5pTcrUIhs6gr9RFfo/F7Xg/3qrs/s/g//7Fv/nFybF /8Vd2S/g/9SV1v/Tk87t/9xNpL71//B/Nfi/cuv/Ver/WP8P/4f/w/+tRj01av7IXI3/k1kJ phna3VHP21CV+j/W/0t/27jk/1p724Q2nZVDb5//692k5FCpz1j/D//3Nf7Pn+JZ/Z/7nr3T /Z+7+OH/KGeXu/9rD8yI8n+6Ef+nfxT+7/jiznL8X/y4N/4vvVX4v4RuRSH/p8cP8H829NtK +L/2gKgr+T9nykzXJ7wl09a/TA+Vj8L/RUYtXS0W/J/7bfzflncU+L/0qNr8X2fxf6lRFfq/ psP/4f9WdyD+LzEK/5fQKvxfYtSl/J8covi/qCj835f6v9mMPfzfH55i2f+Fb2N2N0f839Nr 9WZeFfR/t97F+f5PPpj/2bu3BFdVLADDGQpDEFTUWZ35P51wsaKJ7oggRvx5aLp7V7lqGS+I fFn4vy/+7/ngiP8L+6x+z//Vnrfh/95Dzf2fKtL/9XLR//Vm+WVa/yfxf5fxf88ddCf/V7mF iPi/z6mfG/u/qh/y+T89rgu3/+Na/k82a/6vcS9nc/i/Rk924LH+z5cPz+D/pF8aHef/XDpf /Z+fHInyf+46+83/uR/L4//cPZH6f/i/aVLHhcL/4f9WQs2Smj4yl+P/7LOH7/b6v+k2XqFO 9H/jzTCh/+sU/i9JVm/+T9fO//kX3Tv9X1v/deJH6v/5Vb7pJr9/wv/ZYW1h/q8aUvu/n6j/ h/+j/UIb/V9zYIww/yed/6sfAv93fDNnOf4vfN4b/xefFf4vYliRy/+p8/1frfB/V/F/vcL/ 4f/wf3FZ4f/wf+9Z4f8iQ2Xyf3WD/8P/re9A/F9kKPxfRFb4v8hQ+L/AtPB/Y4f/w//h/8S/ J6Vv4P+k7O9V/899MPi/f/s/8+CI/wv7rPB/Sf2fWvF/vV19o2QXc8f3JsMPJvWN/J+S6f3f 836E/wvageI8/6cV/i8wq9P8nyjS/0l1tv+rqza1/7MH+6L/c1nh/zZ8Vqf7P//Qk8P/yRT+ r5526/5vMptwcP2/fP7PVXal/p/5UfzfUlb4P/wf/i+N/5O9nYmUvX2/sy/UfBtmYuJ8/zf4 CdVmf6g3/yfxf4f4v6F+DqSlamo/O7fP/5mxpO8E/g//h/9rtbnvJvV/ZqE+/o8W2Eb/1x4Y I8z/Kef/2ofA/x3fzFmO/wuf98b/xWeF/4sYVmTyf+ZF9+n+r/JrVXL4vyOo4a38Xy/wf9tC Fej/zKoO/F90Vvi/K/i/rsb/xYYqz/+pHv+H/1vfgfi/yFCF+b+2wf8lCoX/S+v/tB1P4P/C QuH/Lur/3Owt/m+Lp1j0f37WLMr/KU+iXCiJ/wu93p5W/8/wtUX/10/pBv5vzf+ZB0f8X9hn hf/L4v98/T/83ycemvu/58Pckv9ruza1/zNH4J38n5+mwP9dwf+56cZr+r+M9f/0ner/1c9h L/5veQfOV932+D/8n/0Q8H/4v62h8H/4v7VQK1nh//792H22/2vde/tWD7tDzbfxCnWi/3Pw L6n/G1Uj/i+p/1Oteg5ln2OYNsb/9aZ8h+/sZAH+L0lW+L99/s9IufL8X4P/o4W30f/pA2OE +b/a+b/uIfB/xzdzluP/wue98X/xWeH/IoYVufyf+AH/59YV4f82HBan+78e/3dj/9cp/F+C rPB/V/B/csD/xYbC/33Gwv/h//B/q6HwfxFZ4f8iQ+H/AtPC/40d/u+X/Z+sfDr4v9/xf6JZ 83/9q9vt//S0y+f/xCDxf4GhPo5A/J8IOa/wf0n9n1Sn+z+p7dUkpf/zocR7axu7y3y3971S pyeduJP/q5XqzILvuh32X277wZ4wvnuOjvF/l/F/VY//C8zqLP9nruwF+r8fqP+H/4v1f66Q dhb/5zEs/g//N2n4P4H/w//h/xZD4f8S+z/pFidIe5nY6f9m23iFKsv/6ep8/+ce5Yryf89H t0Ga6YtO7w4ltXVpvhPU/8P/hfi/2j5fJfV/kxv+af5PmTzS+r8e/0cLbqP/6w6MEeb/Guv/ GvkQ+L/jmznL8X/h8974v/is8H8Rw4pF/yeb1P6vrs73f2pwD4w5/F93BDW8lf/r7BuKiKUW UttHad/ZUPi/wFBLV4sc/q/p8X8JssL/Jfd/tVtAktD/mZks/F9kqPL8X93g//B/6zsQ/xcZ qjD/10v8X6JQ+D/833wP4v/iQ+H/th/sN/d/fs22uTkeXf/P/VgG/1dXTsq5Ye5e/6cnnSkH VJ7/k02P/wvMaub/zIPjjfxf61bJ+26f/5Pu3Bw7U2brRvX/7JH9fBTx7+f2+b960tV6rf6f 3WVKVTF4yOkF4crXNepG/k9Vekjt/+pfqP/Xug8mzv/5o7xk/9cP9/J/FmkV5v+aPrn/q2/k /9pBtqn9n1nzeCv/565Ihfm/2i/lj3kS2er/3H0wi//z19nj/V/rJqPxfws3Efyf7fB/W0Ot ZIX/24jy8H8p/Z8dEDwvps3uUPNtiL9KeWX5v1+o/+fugyn9n6xP9n/PwW1X268v0s3eUFK3 5iHXd+I3/J97fIic/PbjwGYWCv+X2P9ZuJzU/5mnxpP9Xz2YZ7ik/s/MB+L/aIFt9H/9gTHC /F/r/F/9EPi/45s5y/F/4fPe+L/4rPB/EcOKG/m/2r0uwf9tOCzO9n9Dg//D/+H/4rLC/yX3 f8odoSnr//XU/ws+rz4OC/zfRyz8H/4P/7caCv8XkRX+LzIU/i8wLfzf2OH/8H/4P/FleeUN /N/zwbE8/2dJFP4vKCv8X0r/Z5YW4f/CQm3zf/2A/4vwf88xRZva/5kdiP8L2YHiNP9nDgv8 X1hW+L+k/s98Vvi/uGe5s/2fVPn8n3+fi//D/00a/k/g//B/+L/FUPi/xP7PT8OomPp/s228 QpXl/36h/l96/zdBeSf5P2ne+T1vVJ1bFrvP/zXm0POdwP/h/4L8X5W8/l+h/q/C/9GC2+j/ hgNjhPm/zvk//RD4v+ObOcvxf+Hz3vi/+KzwfxHDihv5P9X7FzT4v6+Hxcn+z72Zwf9tCnW+ /7MLilL6v1rj/xJkhf9L7/9a95ic0P9phf+LDVWe/2sq/B/+b30H4v8iQ53p/7Rbj5rS/9Ud /i9RKPxfWv/Xugdv/F9QKPzfJf2f6N11HP+3xVMs+z/3p9jFt7v9n1difiTYrPm//tXh/9YP wZ/wf1O6gf9b83/mwRH/F/RZnef/RIn+z5iyf/m/SkYtLfJTLO0YqkD/Zy63C/X/GiMP0vo/ 8RP1/9wOdgtTI/3fZNVtaf5PVv29/J9diJjD/9lv9Uvq/553thL93/n1/3ot8/k///6+MP/n 7tJZ/J/HZDn8n1tIncX/+a/4yeH//B0jg//TbsF3Dv/nZUIW/9d7u2cO8L3XwOk2hMD/Cfzf l1ArWeH/NqI8/F9C/9fYy6jvdvq/2TbsAi3832co/N+S/1O1m7eQuo3xf2bix3fCTX6f7f+U f+KLmvz248BmFupE/6ftCLow/6eGoUD/13R2UWBK/2dC4f9ogc37v+FIaxfk/1Rl/V9dPQT+ 7/hmznL8X/i8N/4vPiv8X8SwIpP/k/35/q+WjiLi//B/s4b/+zX/R/0//N9qqNL8H/X/8H/2 t/B/Av+3dQfi/yJDFeb/ZIX/SxQK/4f/m+9B/F98KPzf9oMd/yfwf0uv1c/yf6+szvN/7tKP /1uYT8D/JfR/5rzC/4WF2lj/r8b/bfJ/vVz0f52Bf4nr//U/4P/8oB7/92//Zw4L/F9YVvi/ 0vxfM2T0f+4ILcv/+SfULP6vHSY78GD/525OGfyfGPzBnsH/KT9UyuD/3Lg6j/9z98Qs/s9/ t0CU/5tsQwj8n8D/fQm1khX+byPKw/8l9H+qcpto692h5tuwC7QK9H9jVvi/tP5Pq+cxZ/xf rfaGMvCv+evEb9T/+5vuigj1e/6vMUcg/m/hsXvu/1SJ/o/6f7QdbfR/8sAYYf5POv+nHgL/ d3wzZzn+L3zeG/8XnxX+L2JYkcv/qR/wf7WbPcX/XcD/9bXA/20LVaD/0xX+L0FW+L8r+L+2 w//FhirP/9UN/g//t74D8X+RofB/EVnh/yJD4f8C08L/jR3+77f9n9su/m+Lp1j0f/6tcZz/ 86/V31Heu/8bF37YLeH/1g7BjPX/ns89K/7PvRbB//3b/9Wqv5X/c9/qh/9bOAJP8n/r9f/s gSAH973pkf7Pa5s1/+edUln+r2qL9H9+ES7+79/+zxYmxf8FZXWa/3Mk6j/x1nSjzR+a1P/J 9k7+r+5K9H+9PRCS+j/zJarL/s+NX7L4Pz3Zgcf6P3/oZfF/LlQW/+fuGPi/vf5vSOD/ptsQ Av8n8H9fQq1khf/biPLwf+n8n/DP20MXcQ2cbaNU/6ca/F+SrN78XzvI3vo/N0bb6//UXyd+ xP9J91nFzAd+jAPP9392/qU0/1en9n9Gyp3t/+yYPan/M8/C+D9aYBv9nzowRpj/U87/NQ+B /zu+mbMc/xc+743/i88K/xcxrLiT/6uOQHn4v8hQi/5PmhEt/m9TKPzfR1b4P/zfZfxfXeH/ YkOV5/+o/7cnK/xf4ucD/F/kDsT/RYbC/32Eupr/c9+Xjv8LCoX/w//9Tani/8x/pPd/frwe 5//8h5Xd/2lVoP+T1ar/c/MU+L8v/q/H/8X5v+d5lcv/6R/wf3ZYlsf/2RSUrCLeK/n/W7gP +l7+73kmpfZ/qrmX//Or2i7p/57nDf4vMCv8H/7v89Xwm/9T+D/8n/3Ratrh//B/H9sQAv8n 8H9fQq1khf/biPLwf+n8nxnXvrqd9f9m27DzFgX6vzEr/F9a/1d1dWNuVO2g9oaSujF16Xwn 8H/4vzD/V2L9v7q38xb4P9rJbfR/9YExwvxf7fyffgj83/HNnOX4v/B5b/xffFb4v4hhRSb/ N4Y61f9J/8o4g//TwwGhbuT/VFUL/N+2UPi/j6zwf/i/y/i/vsH/xYbC/33Gwv/h//B/q6EK 83+6wf8lCoX/w//N9yD+Lz7Ubfyff2+K/4v0f3YOLdb/1W+h8H97D8Fc9f90teL/Wv91Ofi/ j/kE/N9F/Z/A/0X5PxOqPP9noNeS/2tb6v/h//B/+L9m0uX0f+azwv/FDaTxf4E78Nf83zh+ yeL/Jt8mhP/799gC/4f/WwmF/8P/rYSaJTV9iijF/z2Ht25upGv2h5ptw4xyS/R/Y1VD/F9a /9d0VW39n94dysC/9q8T+L/D/J+Df/i/hcfun/N/nbn44f9oZ7fR/zUHxgjzf431f031EPi/ 45s5y/F/4fPe+L/4rPB/EcOKG/m/593JZof/u4D/07XA/20Lhf/7yAr/h/+7jP9rJP4vNlR5 /q9u8H/4v/UdiP+LDFWY/6s7/F+iUPg//N98D+L/4kPh/7Yf7Pg/gf9beq0+83/9UGL9P4X/ i/N/Cv8X5/+e5xX1/8JC4f+y+L9KFun/er++vij/p0yMtP6v0ffyf/aYy+H/amOh0vo/jf87 xP9pPeD/4vyfyyqP/5vuwIP9n7u2ZvF/7hjI4v/8dRb/931sgf/D/62Ewv/h/1ZCzZKaPkUU 4//8lb2LqP8338ZLypXl/8qs/2fmbk/2f81zxGT8X6v2hjLwr/nr7E/i/5JkdRP/V6f2f3V1 vv9rqf9H+4U2+r/2wBhh/q91/k89BP7v+GbOcvxf+Lw3/i8+K/xfxLBi0f+pKrX/M1PsK/7P rRTIUf/PTdvi/zYcFmf7P/vlqfi/TaHO938mK/zflncU+L/4UKX5P93j/2JDlef/qP+3Jyv8 X+LnA/xf5A7E/0WGwv99hML/4f/wf8uhzvd/njHh//b6v8Y9HsX5PzfEu6f/8yuvL+n/xHr9 P3e44f/wf5OW0/91bv0H/u8C/s+/mMvh/2w6Kf2feZhb8n9126X2f2NWnx8W/u/X/N/zKL6X /7P33dL8n/0ag6T+T3TZ/J9U+L+FHZjA/9mnhaT+TzX4v8Csbu3/3OGN/1u4ieD/bIf/2xpq JSv830aUh/9L6f/czJru6v2hZtsQhdb/+wX/5x5QU/o/WZ/t/+q6tzeqtmn2hjLwr/7rJqHO 9H9NO+nwfzfzf7rC/wWGwv8V2kb/pw+MEeb/tPN/zUPg/45v5izH/4XPe+P/4rPC/0UMKzL5 PzNYOt3/Nf4FDf7v62Fxuv/r8H/X8X9mB+P/tryjwP/Fh8L/4f8+Dgv830cs/B/+D/+3Ggr/ F5EV/i8y1K38X2//UvxfUCj8H/7vb0r1Xv7PD6Lxf++hZv5PSX0v/+dSwP998X89/i/O/2mV y/9Jlc//6Xz+r8/m/2p9J/+n2rZI/+fJAf4P/zcDPdWrw/9Np35O83/i9Pp/fdWl9n/ms1r2 f/515DX9n3kYxv+FDWOqaXcz/+fOXfzfwk0E/2c7/N/WUCtZ4f82ojz8X1L/Zy/H2l4mdvu/ yTbMD5Xo/zqF/0uS1Zv/UwYoGf/nnqn2+j/51wnxV9UQ/5fY/2n7Ghj/t/DY/XP+r0/u/8yz MP6PFthG/9cdGCPM/3XO/+mHwP8d38xZjv8Ln/fG/8Vnhf+LGFbk8n/V+f5PuTFhHv+nDwh1 K/+nBP5vW6jz/Z+deU7p/5oe/5cgK/wf/u89K/xfZKhM/q9u8H/4v/UdiP+LDFWY/9MN/i9R KPxfYv9nh5n4v7BQ+L+L+j+3PA//t8VTLPq/cQW12ZG7/Z+cdma5yqL/my6NjPV/fx/Wov9T bs1jyvp/XX0r/9f4teX4v4/5hJn/o/7fZfyfWKv/V7uSySn9X/0D/s+ewnIYify+pUWTdyql 1v+T1ZL/qwYD/9L6P/NZne7/tEda+L95KPyfyOT/zAeT1v/Vv+D/9Kvb7f/0tDu//t8R/k+s +j93sBfm/+wRmMn/TXfgwf7P3d2z+D+3t3L4P7/wK4P/a512yeP/3IeUw//1+tXtvQZOtyEE /k/g/76EWskK/7cR5eH/Evq/3g2VXLcz1Gwbr1D4P/zfQlZz/1f1+vmE/7xRNZ3aG0rqxsyN +E64L7872/+5twul+T87pV+c/xtS+z8z9Xi2/2tMHkn9X43/o4W30f/1B8YI8n915fyffAj8 3/HNnOX4v/B5b/xffFb4v4hhRSb/p5rz/V/t1lPi/zYcFmf7v6bG/13H/5l/x/9teUeB/4sP hf/D/30cFsX5P+r/7ckK/5f4+QD/F7kDc/m/QeL/EoXC/+H/5nsQ/xcfCv+3/WDH/wn839Jr 9bP83yuro/2fVGv+zy8xx/998X/U/4v0f/2A/wsMNfd/Cv8XeLXY5P9krWVq/2e/xRz/F3ZY nOX/dIv/C8zqNP83FOn/RJH1/8r0f3rF//nFRFn8n5+uyeH/Dlmferr/8yOxsvyfv6Tj/wT+ b5rUcaHwf/i/lVCzpKZPEcX4P93ZP7RT9f5Qs23YBVoF+r+xohf+L6n/k3VVD+ZGVTfN3lBS N2aiz3cC/4f/w//h/2i/0Ub/NxwYI8z/Sef/6ofA/x3fzFmO/wuf98b/xWeF/4sYVmTyf7L/ Af8n/QuaHP6vPSDUjfxfa95O4/82hTrd/7Vu/UNC/2deXeH/orPC/13B//UD/i82VHn+j/p/ e7LC/yV+PsD/Re5A/F9kKPzfR6ir+T/3Hh3/FxQK/3dR/+cep/B/WzxFJv/3CnUL/+c2fs36 f//wf35tOf7vYz4B/0f9v4Uj8Cz/l6/+n1musuz//EXlmv6v7hb9n2q61P5vzOrzw8ro/7xj wv998X91fyv/Z+/CV/V/YtX/mT8lrf+rb+T/Ot2m9n/mfrXs/7QbB17T/4lV/+e/ktm/a903 tnj/rFb8n57swGP9X+MOtwz+T/jBehb/56+zGfyfGzpn8X/uMoH/E/i/aVLHhcL/4f9WQs2S mj5FFOT/7J/S2fvrbv832carUl5Z/u8H6v8pN/GT0v8Jfbb/U2Y49rxRqWZ3KPkcfbd/nXAz 0mf7PzfdVZr/s48Pxfm/OrX/q3VVoP8zqhH/Rwtszv/V1ZHWLsz/Kev/FP4vSzNnOf4vfN4b /xefFf4vYliRy/+pX/B/7tEqIcrTq/6vSR3qbv6vFfi/baHO93/mt5P6v1rj/xJkhf/D/71n hf+LDEX9v9BQ73sQ/5dgB+L/IkMV5v90g/9LFAr/h/+b70H8X3wo/N/2g/3e/m+sX2Fujgf7 v+mgc7f/c/NL+f1fowv0f5ZELfo/7S6u+D/836Qd4P/qNpv/E2v+z1WRTen/ZFug/1uv/6f8 onf3h5Xh/9q6Te7/fqH+ny+zVZj/MxAsqf+TcriV/5NuuhH/9zv+T6qz/Z+2N6pM/s+/jrym /1ur/+cdUxb/5347i/9zK6jz1P/zC7Qy+D+Zzf9pd0Ll8H9uOJbJ//lTOMr/TbYhBP5P4P++ hFrJCv+3EeXh/xL6v87NnLluZ6jZNkqt/4f/i3/buOT/WjnY+n9Sqr2hzDVm+OuEwP8d5f8c /MP/LTx238D/Uf+PtqON/k8eGCPM/9XO/7UPgf87vpmzHP8XPu+N/4vPCv8XMazI5P/MZPTZ /k8N7oExS/2/I0Ldyf+ZMTb+b1Oo8/2fXVCU0v81Pf4vQVb4P/zfe1b4v8hQ+L/QUO97EP+X YAfi/yJD4f8issL/RYa6lf9zG8b/BYXC/+H//qZU8X/mP6j/h//D/y3MJ+D/Uvq/fji//h/+ b5P/+0f9vwL9n+6GIuv/4f+21f8z18Ab+T+HtPB/n1M/+L+U/s/cRG7k/6S/ImWp/9dOduCx /s8/+Gbxf24gkaX+nwuF/8P/4f/wf2+HBf4P//eZ1Uf9PzeL0NUR/m+2DTu2KND/jVkV5v+q s/2f7p5nkrlRqWZvqOc1xjxi+G4SCv+H/1vI6nj/Z2Y58X9hofB/hbbR/6kDY4T5v8b5v+4h 8H/HN3OW4//C573xf/FZ4f8ihhWZ/F/zC/X/3BtP/N+Gw+Js/6fNi3D836ZQ5/s/s4Op/7fl HQX+Lz7Uuf7PHaEp/Z9W+L/YUGf7v87OwCT1f+ZLifF/gaHwf4mfD/B/kTsQ/xcZCv/3Eepq /s/d3/F/QaHwf/i/vynVe/k/N2ET5//8BeCL//NPYtf0f12dzf+1TS7/9/zJNf83pRul+L+u Tu3/vL7C/+32f1pR/y8w1Nz/qWX/J6vaHg9D6xe177rj68ndwR7sy/7P/0Ul+b+q6iT1/y7j /0yhgrT+r5f4v8CsftD/mc8qrf+Ta/6venW7/V817YQu0P+Z+xX+L/Kzwv+JsAfUetrh//B/ b9v4DDVN67BQ+D/831qolazwf9+eRM71f4OjHa7bGWq2jVeoE/2fcp9OSv83aPxfkqzm/q+q ZKWfN6qqi6r/Vw9/nZnY1z/g/9xwrDT/V7sO//f+2D33f6pE/2dev+D/aIFt9H/1gTHC/F9r /V8tHwL/d3wzZzn+L3zeG/8XnxX+L2JYkcn/1b9Q/8+vwEmI8vSa//MTtfi/vf7P1GrE/20K db7/MxtP6v9Ug/9LkBX+L73/o/4f/i9H/b+6wv/h/9Z3IP4vMhT+LyIr/F9kKPxfYFr4v7HD //20/xv8pBn+D/83adf2f6+sjvZ/QtzK/+kuuf9T+L/r+z93PKT0f5PPahYqn/8Tgz2JZD/E 4KHxDvT3JdwF+j8Tasn/VW1q/2e/xRz/F3ZYnOT/ngfavfyf9TX4v8+pn63+T7663f5PTjvz WZ3q/5q+kdb/NW4h4l7/p18d9f/wf/g//N/6DsT/uQ7/tzXUSlb4v40oD/+X0P/1blTW2wm0 naFm27ALtAr0f2NWJ/q/2t2FS/J/Yhjkc3wp62c2/d5QUivzetJ3Av+H/wvyf32X3P8VWf9P Nfg/WnAb/V9zYIww/6ed/6sfAv93fDNnOf4vfN4b/xefFf4vYliRy/9VP+D//DvWHPX/8H+x /q8S+L9toc73f+bfk/q/psf/JcgK/3cF/0f9P/yf/a15/T+F/8P/re9A/F9kKPxfRFb4v8hQ 9/J/bm0+/g//txoK/4f/8218R2tujnv9nx9Lf/V/LjD+70tWqsvm//Sa//NPifi/L/6P+n+R /q8f8H+BoWb+z3iK0/2fz/qa/k8t1v97/q34vxv7P1OF907+zw7e8H8LUz839n+d6lL7P3MN XPZ/nTuvyvJ//rPK4v/8WC2L/3MpZPB/4yN+Fv/nr7MZ/F/lUFIO/+dG6Xn8X/Xqdvu/atrh /wT+70uolazwfxtRHv4vof/zlKezN9mdoWbbMKPcEv1f0+P/kmQ1r//3fIR73t2lGno3LbjT /9lhguvEb/i/pp105fi/9tUV4/+6Nrn/K7L+n1moj/+jBbbR/7UHxgjzf53zf+1D4P+Ob+Ys x/+Fz3vj/+KzOtX/+cET/u/f/s98rcDp/s+vP8T//b7/68wws0D/1026YvxfY25O+L8t7yjw f/GhSvN/jcb/xYYqz//ZLyXG/wWGwv8lfj7A/0XuwFz+b5D4v0Sh8H9p/Z9fAov/CwqF/8P/ /U2p3sr/paj/51TQd/83WTi/2//5+aO/DyuX/3s+OOL/wkJ9HIH4PxFyXt3C/9Vtif5PF+n/ VJH+TyzW/5O6G1L7P/NZne7//HJV/N+//d/d6v/ZTVzU/0mVz//pfP5PqrP9X9vX+D/835n+ T/r7YGH+T5fp/yZHYGz9v9fgDP+H//tXqJWs8H8bUR7+L6X/c1d+1+31f9Nt2HFggf6vU/i/ JFm9+T8th974Pz/ZudP/mdk53wn8H/7vZP9nZ87wf3HPV2e7JVqaNvo/fWCMIP/XVM7/VQ+B /zu+mbMc/xc+743/i88K/xcxrMjk/2S/5v+Uez2Ww//5FTg5/F93RKg7+T9z2BTo//xnmcP/ HUEN8X+BofB/Y4f/W/N/XY3/iw2F//uMhf/D/+H/VkOV5f9kpfB/iULh//B/8z2I/4sPhf/b frDf3P/5QbS5Oe71fx7+ffN/4+rmKP/3/mFR/+8jVAL/N07I4P+++D+F/4vzf1pl8396xf81 7YXr//kjUHy03i4ekb2OueO7/9t3ZpZk2f8pv+jd/WFl+L9+8PX/uv1HYD/YhV2++436f/g/ 6v8V5v+Epv4f/s/+6PvjwbL/G5L7P4H/w//Zz+jO/s8DnyHCvsy2IQT+T+D/voRayQr/txHl 4f8S+j/d2u12VUSo2TZEofX/RtGD/0vr/3rVddb/NbtDGfjX/nUC/4f/O9n/Uf8P/0fzbfR/ 3YExwvyfdP5PPQT+7/hmznL8X/i8N/4vPqtT/Z9fs43/++L/1A/4v9b+Kfi/DYfF2f6vr/B/ 1/F/bv1DQv9Xa/xfgqzwf/i/96zwf5Gh8H+hod73IP4vwQ7E/0WGwv9FZIX/iwx1K//nVgLi /4JC4f+u6f96dwzg/7Z4Cvxf0HFxmv97ZXW4/xP4vzj/R/2/SP/XD/i/wFBz/9dn83/r9f8K 9H+qUl1q/yfuVf9vfMbJ4P9qcyZR/28xVPn+T67V/2vtNTKt/6vwf0Gh7uH/qP+H/3OfEf4P /7c1FP4P/7cWaiUr/N+3J5GT/Z+bpOvsiHav/5tuw35Be4H+j/p/8W8bF/zf88MZpPV/1e5Q Bv5Vf90kFP4P/7eQVQb/1xfp/zT+jxbcRv/XHxgjzP8p5/+ah8D/Hd/MWY7/C5/3xv/FZ4X/ ixhWZPJ/ZjJ62f8dcl4t+z+//jCH/9NHUMM7+T/dCfzftlAr/q8+INSK/7MLivB/G95R4P/i Q5Xm/4YW/xcbqjz/1+gG/4f/W92B+L/IUGX5v+eFDf+XKBT+D/8334P4v/hQt/F/brv4vy2e Ytn/+Rjm5rjb//kLwDf/5y9/9pX3Xv/XTrsy/d8v1P+r3GsR/B/+b9IKrf9X++ps+L/3UDP/ Z76uetn/+b+oKP/X6uT+72b1/3L6P3O4pa3/97wL38n/2UUPF/V/QvyC/5tcA3f7v9l19Af8 X9fh//B/+L+AUxj/h//bGgr/h/9bC7WSFf7v25PIyf7P0Y7OrtPa6/+m27BjiwL936ga8X9p /V8zPAfSUg1+Ln+f/5ND+9cJ6v/h/872fz9Q/69Vqf2fCYX/owW20f8NB8YI83+183/6IfB/ xzdzluP/wue98X/xWZ3r/zxYwf+9P1rN/F/9A/6vdrP9+L8Nh8XZ/m9Q+L/r+D+zt5L6v6bH /yXICv+H/3vPCv8XGSqX/6vwf/i/9R2I/4sMhf+LyAr/FxkK/xeYFv5v7PB/v+3/3Owt/m+L p1j0f+MaE3Nz3Ov/nAr67v/aV4f/++chiP8L24Fn+b9a4/+uX/8vvf9rmmz+T+Xzf/pO/q9p 69T+Tyr831X8n1nzeCv/19kuzv+5Eyq//9P4v2P8Xzvg/7asujVX9hX/5w69HP6vne7AY/2f W0Gdxf/5W2cO/ycn3ya02/+56yz+D/+3EeXh//B/C6FWssL/fXsSOdf/te6liVYR/m+2DVFo /b9RNeL/Evu/+rmDjf9rmr2hDPyr/zr7Q/i/JFnh//B/k476f7Tw5v2fPNLahfm/xvo/1T0E /u/4Zs5y/F/4vDf+Lz4r/F/EsOJ8/+fGEzn8nzwC5a34vyOo4Z38X1+m//OneA7/dwQSWfF/ ZuNJ/Z9q8H8JssL/XcH/tQr/FxuqPP9XN/g//N/6DsT/RYbC/0Vkhf+LDIX/C0wL/zd2+D/8 X9n+z8cwN8fd/s/rhW/+z69uvqL/U1VVYP0/s2x50f8JFwr/tzCfMPV/1P+L9X9l1v+7mf8b s3Z/2MX8n7ncLtX/U22R9f/8QsUM/m+8Y+Twf+ZMSlv/r21u5f/cQkT83+fUz439nx6S1/+z B/ui//OQozD/5wZQefyfnOzAg/2fuzll8X8uVE7/Z18vRfq/v8vtsv9zjw95/J8zNTn8X+9X N8f4v+k2hMD/Cfzfl1ArWeH/NqI8/F9K/zf4Ocd2f6jZNl6hyvJ/1P+Lf9u46P86871Faf1f L8/3f+7tQnH+T7muKP9nV1yU5v8au14W/0c7u43+Tx4YI8z/ta7+n3wI/N/xzZzl+L/weW/8 X3xW5/o/f+fF/70/Ws39X3W+/1PuXVAO/1cr/F+M/3teivB/1/F/duYZ/7fhHQX+Lz4U/g// 93FY4P8+YuH/8H/4v9VQ+L+IrPB/kaHwf4Fp4f/GDv/32/7PPU7h/7Z4imX/59GLuTnu9n9u CIj/u5r/E2v1//B/G/2fwv9dpv6fwP/h/8SH/xPL9f/aZkju/36h/l+Z/i95/T97tcD/BWWF /0vq/6TC/y3swF/0f/YIxP+FDWOqaYf/w/99bEMI/J/A/30JtZIV/m8jysP/JfR/2t0atR72 h5ptw4xy8X8LofB/y/5veN7d0/o/JTX+L0lW+D/836sz3xqD/6MFttH/qQNjhPk/7fxf/RD4 v+ObOcvxf+Hz3vi/+KzO9X9HLCUuz/8p1az4P+H/PYP/8ytw8H+/7//sSkr836ZQK/7viGvg sv+r3foH/B/+b9ZmP4b/W/N/3YD/iw1Vnv9rKvwf/m99B+L/IkMV5v/aAf+XKBT+D/8334P4 v/hQt/F/fmU0/m+v//Pvbu29fq//m5syodf8n1/4cUX/J7u6QP8nV+v/+cMN/4f/m7Rr1//7 Af831Oa3k/q/ftX/OeQgI94rCb8C0YETc7Cv+D8/neD+sCL8nxwqmdr/GUB5vv9z/47/w/9N QE812LX//s4S6f/+ziv83+cOvFL9v66qU/s/M+Rc8X/uZCjN/znRkMX/VZMdeKz/80ukMvg/ 4Qfrpfk/99s5/J97iZrH/+lXt9v/6WmH/xP4vy+hVrLC/21Eefi/hP7vgPp/usj6f2NW+L+k /k/2zVCX6P/cmL44/1e5rij/18vk/q8/3f89rxKNSOv/TFb4P1pgG/1ffWCMMP/XOf/XPgT+ 7/hmznL8X/i8N/4vPiv8X8SwIpP/kxr/h/9bDIX/+wh1e//X9Pi/BFnh//B/71nh/yJDUf8v NNT7HsT/JdiB+L/IUPi/iKzwf5Gh8H+BaeH/xg7/h//D/4kvyyunpgz/dx3/J1br/+H/8H+l +T99vv87oP5fPv/3j/p/5fk/1ajk9f/kT9T/K9L/mQVVSf3f80DD/wVmdZb/kwr/dxX/Zw92 /F/cZ4X/E2EPqO/rvk/3fwP+D/+H/0sSaiUr/N9GlIf/S+j/tLtDuYVwe+v/TbchCq3/h/+L f9u4VP+vHp43cuP/3DPVXv8n/zqB/8P/Bfm/9PX/6gr/h/+j2Tb6v+bAGEH+r62c/6seAv93 fDNnOf4vfN4b/xefFf4vYliRy/9Vq/7PTQXm8H9+/WEO/1cdQQ3v5P80/u86/s8uKML/bXhH gf+LD4X/w/99HBbF+T/q/+3JCv+X+PkA/xe5A/F/kaHwfx+h8H/4P/zfcqjz/Z9PB/+31/+1 bsImzv+5Id43/+fH63H+z39Yv+P//Mrrwvyfe/LG/y3MJ8z8X4//u4z/E0X6P/UL/q/1O9J2 Zfg/bV5hJa7/V/2A//PLVfF///Z/5i58J//XmzP9ov5PlFn/T6oS/Z8u0v+JNf/nDpss/s+f DDn8X+1uThn8n/RLo3P4P/fvWfyfGzrn8H9S5vN/LgXX7b0GTrchBP5P4P++hFrJCv+3EeXh /w7wf3YCLdL/tf6psMH/LYTC/y36v7Z/DjLT+r/n2fkD/s8Nx/B/t/R/usL/BYbC/xXaRv/X HhgjzP9J5//UQ+D/jm/mLMf/hc974//is8L/RQwrMvk/8/b5bP9Xuxli/N+Gw+Js/6cU/u/G /q/W+L8EWeH/8H/vWeH/IkNR/y801PsexP8l2IH4v8hQhfm/XuP/EoXC/+H/5nsQ/xcfCv+3 /WDH/wn839Jr9Rv4P7Hm/zr3weD/8H+TdoD/64cV/+dmo6n/t3C1qCddRv/XqDv5v3qoU/s/ c7XA/4XsQLHV/5nzKq3/axv8X2BWd/B/mvp/+D+7Lzb5P+mXMuH/8H/Tjwr/h//D/+H/1kOt ZIX/+/YkcrL/c3n4l447/d90G69Q+D/830JW7/X/ZHL/9xv1/9xwDP+H/yvG/yn8Hy24jf5P HxgjzP8p5/+ah8D/Hd/MWY7/C5/3xv/FZ4X/ixhW5Kr/p6rz/Z977Yz/23BYnO7/evzfdfyf XXdI/b8N7yjwf/Gh8H/4v4/DAv/3EQv/h//D/62GKsz/dRX+L1Eo/F9i/+cevFP6P9Xh/2JD 4f8iQ+H/QkNt839+nYfdyG7/V027V6g3/9e0r263/2unXZn+75XV0f7PzBSv+D+XAv7v3/6v 1vi/g+r/ZfR/XtIl9H+9KtD//aP+n59Jdn/Yxfyf4dZL9f+GIbn/Uz/g/9ytEf/3Hurd//Xy Tv7Pbfyi/k+qIv1fmfX/xKr/c0donP/ze+4vq0X/N7T5/J+bpcji//p6sgOP9X9u4XwO/ycG f7BH+T//BTV/ixOW/Z97GZTF/7krex7/5x7nc/g/jyCi/N90G0Lg/wT+70uolazwfxtRHv4v pf9zQ1lt353s9X/TbdgFWgX6vzEr/F9a/6fr5xX8eaNyr/52+j/7ltx34jf8X+Umbcryf9rN VOD/FhapTv2fecIvz/+ZCVX8Hy2wjf6vOzBGmP+rnf/TD4H/O76Zsxz/Fz7vjf+Lzwr/FzGs wP8Fhpq9JdP4v2P8X93g//B/+L+4rPB/V/B/rcL/xYbC/33Gwv/h//B/q6EK839Dh/9LFAr/ h/+b70H8X3you/g/v7wC/7fFU5zu//pXt9v/6WmXz/+pqirQ/1kShf8Lympe/0/h//B/wv0/ k06V6P/+Uf/PzyS7P6wM/zfo5PX/7LeY4//CDouT/N/zr8b/BWaF/0vq/8QP1P8bkvu/9fp/ +D/8H/4v4LCoZ90P+D/q/+H/8H/4v9VQs6SmTxHl+D83QNc6xv9Nt2F+Ev+3EAr/t+j/hqqq nzcq1XZ6byip7eIJ3wk3RYL/S5DVPfxf16b2f6LI+n/4P9qONvq//sAYYf6vsf6vqR4C/3d8 M2c5/i983hv/F58V/i9iWJHJ/5nB0tn+TzXu/WKG+n9q/HZa/N/XUIv+r6nwf/g//F9cVvg/ /N97Vvi/yFCZ/F9T4f/wf+s7EP8XGaow/0f9P/zfP0Kd6f/azh7fKf2frPB/saHwf5Gh8H+h obb5v3pclSvEbv/nd903/1en8H/+w8rt/2TbZfN/qjvf//nDDf+H/5u09P7PuFr8X1ioIP/n 17hF+r+/8nVn+79qcPPfCf1fUy35v1p2yf1f0+P/ruL/qP9XgP9rLIlK6v9q/F+U/5Nmqv1f /s8lF+n//nZgLv+nV/2fG5xl8X/NpDvY/7m7exb/51LI4v/0Kzn837/HFvg//N9KKPwf/m8l 1Cyp6VNEMf6vczd81+0MNdvGK1RZ/q9T5/s/P4tQkv+rZa2c/4up/2ffIvpuEgr/h/9byCqD /3vd8PF/+L97t9H/DQfGCPN/rfN/6iHwf8c3c5bj/8LnvfF/8Vnh/yKGFbn8nzjf/9UV/g// h/+LuAbm8n+1xv8lyAr/dwX/1w34v9hQ5fk/6v/tyQr/l/j5AP8XuQOp/xcZCv/3EQr/J/B/ +L/FUPi/2LRO938p6v95uVO0/+ubEv2fwP9F+b9a4/+u7/8692SQ0P9NPqtZKPzf7/k/WS/6 v6p5jmVl3Sgd4/9a+erwfzsut6f5v7bB/wVmdZb/s/qqPP8nFf5vYQf+ov+zAnXR/2n8H/4P /7d9B+L/XIf/2xpqJSv830aUh/9L6P96N6hw3c5Qs228QpXl/8aKXmX5v7FS3on1//rnVU/W z6tEvzeU1J15zPTdJBT+D/+3kNW7/xvq1P7PPF+V5/9kj/+jBTfv/9SR1i7M/2nr/+r6IfB/ xzdzluP/wue98X/xWeH/IoYV5/s/Nxmdo/6fewmUx//VB4S6k//T+L/r+D+zg5P6P6nwfwmy wv9dwP89H1jwf7Gh8H+fsfB/+D/832oo/F9EVvi/yFD4v8C08H9jh//7af/nDzf83xZPsez/ /CDabORo/+eVSJT/q6cR8X9H1f9zq93xfwvzCVP/R/2/SP8nuxr/Fxhq7v/6fP6vv5H/q8y6 Buv/qhj/Z2+vvvsN/9e5HYz/++L/zCl8I/9nx7P4v4Wpn9P8n2rwfws78Bf9n1it/+cGUFn8 nxvG5PF/LoUs/s8dA/bHYv3fX1Yr/s8PlezrpWP9nxv94v8WbiLVtMP/Cfzfl1ArWeH/NqI8 /F86/ycbO0D33b5Q8228Qp3p//zNMM7/+UHD+AU0+L8kWc39X9UYtCfr2k9n7fN/utd/3fNn pMb/Jcnqw//ZkwH/t/DY/XP+rzN5JPV/JhT+jxbYRv8nD4wR5v865//ah8D/Hd/MWY7/C5/3 xv/FZ4X/ixhW3Mj/1e51Cf5vw2GB/wvM6s7+z5KopP7PvE/C/0Vnhf/D/71nhf+LDIX/Cw31 vgfxfwl2IP4vMhT+LyIr/F9kKPxfYFr4v7HD/+H/8H/i35PS+D/835YjEP8nQs4r/B/+bykU /u94//cc+/aV9X8y4l1FP9glUL7D/+243OL/8H8LpzD+D//37dYo8H/4P7sN/B/+z/wo/m8p K/wf/g//l8b/KWk34bt9oebbeIU60/+5MynO/zXuruPnmMyEKv4vQVYz//ccnRtT9rxRDTrC /zWD/usE/g//d7L/q6vT/V9j18vi/2hnt9H/qQNjBPk/XTn/Vz0E/u/4Zs5y/F/4vDf+Lz4r /F/EsOJG/m9cgZPF/1UHhLqR/2sV/u8y/s8+D+H/tryjwP/FhzrZ/7mHf/wf/m/SWrtd/N+m PYj/S7AD8X+RoU71fxr/h/+7jf9zb1nxf0Gh8H8X9X9ueR7+b4unWPR//vEozv95U1a9hXrz f34NbJz/c3vmm//zy1Uy+L9xfWoO/9f6J4OYy8VG/+cnlAvzf37sh//b6f/8eqAs/q8dXMQM /s9FzuL/7BN3Hv9nV98o5a6Mkf5PjaFO93/2GpjB/2k5WP9XD1H1/+xf4Lvf8H9+mVgO/+c0 Xhb/ZzaO/1sMtcn/VYNd+5/D/yltn96y+D+3iZT+T7Yr/m/8rNxBtG+J+XQbZjPn+z9zuc3k //zYI4f/c8vYs/g//94ph//T48J6+3cd6//czQn/t9P/tW7jOfyflwlZ/J9HEFH+b7oNIfB/ Av/3JdRKVvi/jSgP/5fQ/2l7bfXdTv8328Yr1Kn+z80JDxFrl0f/57qfqP9X2axS+j8zmXCq /2uHuhrM6KXt9N5QUtu7nO/ET/i/cTgW5//8OLCehTrT/7nzpTD/15o7VFL/Z2fOTvZ/vTkC 8X+0s9vo/+oDY4T5P+n8n3oI/N/xzZzl+L/weW/8X3xW+L+IYcWy/9Ml+r+6wf9dxv/1+D/8 H/4vLiv8H/7vPSv8X2Qo/F9oqPc9iP9LsAPxf5Gh8H8RWeH/IkPh/wLTwv+NHf4P/4f/E/+e lMb/4f+2HIH4PxFyXuH/8H9LofB/Gfxfqzpl/Z/WMf7PPqn7Dv+343KL/8P/LZzC+D/837db o8D/4f/sNvB/+D/zo/i/pazwf/g//F8a/1fLtn91+0LNt/EKhf/D/y1kNfd/zaCfV3CpGhnh /9rWDJV8J/B/+L8g/1c1Bfq/1k4m4P9oZ7fR/zUHxgjzf8r5v+Yh8H/HN3OW4//C573xf/FZ 4f8ihhWL/k92Zrsp/Z9smtP93zEob9n/uUcC/N+WFeb4v7Crxc/5P7uKHf+35R0F/i8+1Ln+ z701xf9tCXUj/+fuNfi/LXsQ/5dgB+L/IkOd6v+q5P6vrfF/iULh/xL7P7eqGf8XFAr/d1H/ 53ED/m+3//Or2U3E3f5vOqkzCXWi/3PD+hz+zz/kJPR/Zg3Jkv+TTuOk9H/1qv9z2y3L/7Xu coH/WzjYt/k/F7h1n9Ve/+f2eOWTG5b9X+3Oq5T+r17xfx6TZfF/dT7/J53/q2LwkF9c2/0t wjnd/0k3/324/2t08zzFZV3XMfX/+r57db/h//zCzgz+T/hVTDn8n7nq4f8WQ23zf/6FUg7/ Zz6ktP6vXvF/bjSRx/+NK0jcQbRvifl0G+In/J/ss/k/f2HK4P96eyDk8X9+KVMO/+e+MSGL //NLpPB/e/1fa7ebxf+5wyKP/3NHqJ0E3O3/JtsQAv8n8H9fQq1khf/biPLwfwn9XyP7V7fT /822YX7yfP/n55ji/J8bjPyO/1PuJVyk/5vdr873f7V83peed3g/+b3L/zWDWRfjO/Eb/s8N 1gvzf609oQrzf9I+Lhbn/7S5cOH/aGe30f+1B8YI83+183/6IfB/xzdzluP/wue98X/xWeH/ IoYVp/s//3Ue+D/838T/6Qb/dxX/p+yTIv5vyzsK/F98qML8n1Qt/i82VHn+T/X4P/zf+g7E /0WGKsz/TVEe/g//9xbqVP/nLkP4v6BQ+D/8H/7vaP/Xv7rd/k9Pu4z+r1Wn+z/VJ/d/Av8X 5f/qCv8X5f9MKe1c/k82Bfq/Wmfzf+Zbkk73f/bKntT/mVBL9f/a1vg/1Tf7L7e9kya++8vq 88PC/0X6P/M8mtT/Pa9P+L/ArLbW/0vu/0Q+/2dmBBf9n/tg4vzfdBvus7qR//MarzD/V7tD rzD/5y/pGfzf+D0ROfyfWxeew/9pd4QW5/+6V7fb/3XTDv8n8H9fQq1khf/biPLwfyn9nx3m 1E2730DPt/EKVZb/61SJ/m+C8s6q/9d1jVkZ2LsPaZ//s+zKd5NQ+D/830JW7/6vMg89af2f Ot//9Sq5/9P4P1pwG/2fPjBGmP9rrP9rqofA/x3fzFmO/wuf98b/xWeF/4sYVpzv/9zjdQ7/ 515O5PF/8oBQN/J/XYX/u47/MxtP6v+kwv8lyAr/dwX/1yr8X2yo8vwf9f/2ZIX/S/x8gP+L 3IG5/J/q8H+JQuH/8H/zPYj/iw91F//n3qPh/7YMOlf8nxuexfk/F+Or//ML56P831n1/1b9 3+A+mIT+75XV0f5PqjX/534b/7cwnzD1f6rB/x3j/5o6uf8TRdb/U//2f391FmP8n+vW/Z93 Shn8n6wz+b+uazvr/7qo+n92zaPvrBY+3//5FUj4v3mo9/p/z2f8G/k/KbP5v7pP7v/0iv9r hoz+r3l1u/1fM+2kKtH/6fP9X2f/0KT+T6z5PzfQzuL/Or8S3XYH+z93bc3i/1wKWfyf/zYh +3rpWP/nsirO/w2vbrf/G6Yd/k/g/76EWskK/7cR5eH/Evo/R+Sez5b7DfR8Gy8pd6b/c2eS skP7WP/3JrvP83+1G024aeJY/9fMQp3m/7pWPZ+35fNp200L7vN/ddv9dZNQP+D/6qjJ7/dx IP4vRVZv/q8azGAd/7cUCv9Hi22j/+sOjBHm/7Tzf/VD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy +T9TMP50/9fh//B/+L+Ia2Au/1dr/F+CrPB/+L/3rPB/kaHwf6Gh3vcg/i/BDsT/RYYqzP8J 6v9F30Xwf9E7cNH/uXkE/F9QKPzfJf2fdAs98X9bBp34v89Q8f7PLZy/qP8zL6CX/V/n15bj /z7mE6b+z1dfw//t9n9dlc3/6RL937f6f/i/Tzw093+qW/J/g24H6//aCDzU9zaG76wWPt3/ eSWC/8P/leL/zNcYnO//2le32/+1006cXv+v7gfr/3wx3r3+r311z7tsdbr/6+1fi/9b2oH4 P/zflrEF/g//txIK/4f/Wwk1S2r6FFGK/3veC7Xr9vu/+TbMD53v/9zNMKX/+4H6fyX6v6FR Zt5CNlLvDiUbZQYmvpuEwv/h/xayevd/vXkuSOv/+vP93/NiLtL6P5MV/o8W2Eb/1x8YI8z/ dc7/tQ+B/zu+mbMc/xc+743/i88K/xcxrFj0f6pO7v98qAX/56YCc/g/txAwi/+rhwNC3cj/ 9Qr/dx3/Z/49qf9revxfgqzwf1fwf92A/4sNVZ7/Uz3+D/+3vgPxf5GhTvV/9qkH/7clFP7v I9TV/J87RPF/QaHwf/i/vynVe/m/+tXF+r/3UO/+r391u/2fnnYZ/d/zwTGX/5Py/Pp/fo0Z /u+L/6tu6f/coRDp//wYY83/uVD4vy/I4Sfq//kXczn8n91bSf1f2yz6PzU4/6famPp/dn7J d+5bzO/j/6RP4Zr+r+7v5f8625Xl/9o2o//Tr263/9PT7vz6f0f4P3Uv/+ffdGfxf+7Kn8P/ +TFLFv/nTvEc/s/dpfP4P/sh4f8WPAX+z3b4v62hVrLC/21Eefi/dP5P9vZ/yqHZ/z0Q823Y BVoF+j/V4P+SZPXm/2T1/FOkrLso/2df5rnOTCLpH/B/bjhWmv+zj92F+b/ODGVLq//X9Gbi B/9HO7uN/m84MEaQ/3v+d+v/qofA/x3fzFmO/wuf98b/xWeF/4sYViz7v6FI/+f2Vh7/1x8Q 6k7+r8f/XcX/Sbt2ifp/W95R4P/iQ5Xm/6j/h/+zv4X/E/i/rTsQ/xcZCv8XkRX+LzIU/i8w Lfzf2OH/ftr/+cWB+L8tnmLZ/02WHO/2fx+LRsvzf7XO5v9MQaqz6//17oPB//3b/5mKXvi/ oM/qzf8N3Yr/65P7P1Gi/8tY/6+pivR/i/X/ZPU8yK3/89e9nf7PfGf42FmnhP8L2YFio/9T 5sqe1P+ZNY/4v7Cs8H9J/Z84v/5f1yX3fzer/4f/w/99+r/WbRz/t+Ap8H+2w/9tDbWSFf5v I8rD/yX0f4Mdkvpup/+bbeMVqiz/1+P/DvB/sqqH50BCPp8K/FBpn/+r5F83CXWm//PfQVWa /7PnS2n+z3xIxfm/pqtFWv8n8X+08Ob9X32ktQvzf9L6v1o+BP7v+GbOcvxf+Lw3/i8+K/xf xLBi0f/VbUb/546HHP6v82+n8X9fD4uz/d/Q4P9u7P/M+yT8X3RW+D/833tW+L/IUJn8n/lm e/xfaCj8X+LnA/xf5A7E/0WGwv99hML/4f/wf8uhzvZ/wl+G8H9bPMXp/s9dTvB/F/B/nTuL 8H//9n/U/4v1f6v1//L5v8ZFvqb/M57i9Pp/Pusc/q81283i/7T3f2r/5bbv7d73nb1anO7/ er8CqSj/Z+/0aev/mVP4Rv6vsrvsmv7PDGOW/V+fz//5d1e227vEfLoN80Mn+79W9XVq/2cP 9mX/10ySK8b/uSt/Hv/nriZZ/J+7NGTwf+NS2Sz+z6/Ctq+XjvV/bmotj/9zRyD+D/83Teq4 UPg//N9KqFlS06eIUvyfquxd+PnUuL/+33wb1P8T+L8Q/9d1tv5f64aD+/yfNKMu35l/lvi/ JFm9+z/thrX4v4VFqj/m/wZlniqT+j8TCv9HC2yj/5MHxgjzf8r5v/oh8H/HN3OW4//C573x f/FZ4f8ihhWZ/J95Jbzs/3y1mwz+r3bbTYnyNP4P/+d+e9bh//B/wu2BaYf/w/+53550+D/8 34L/o/7fnqzwf4mfD/B/kTtw2f/Zyx7+b0so/N9HqKv5P/cYjP8LCoX/u6b/GyfN8H+7/d/k 8Wi3/3tfdbvi/9xI8Jr+T9cF+j9TOGfF/7ms8H9f/J/G/12+/t+l/V/G+n8/4f/sbSOp/zOh Pv2fHKohtf9rfqH+X5H+rzEzxdT/Wwz1a/6vabL5P91c2f+Js+v/tXUlU/s/c79a8X/9pLua /9P38n/+wTdL/T93ZOfwf6p+dcf6P13n83/O1Wbxf4N8dXuvgdNtCIH/E/i/L6FWssL/bUR5 +L+E/k/aTcT5v9k2XqHK8n+jasT/JfV/Ug/PsYWUnXLTWfv8nzZjVN+5Z2H8X4qs8H/7/N/k ho//w//du43+Tx0YI8z/1c7/tQ+B/zu+mbMc/xc+743/i88K/xcxrMjl/9Sq/8tY/y85ysP/ HeP/6qrC/13H/9ljLqX/kwr/lyAr/B/+7z0r/F9kKPxfaKj3PYj/S7AD8X+RofB/EVnh/yJD 3cr/uddA+L+gUPi/i/o//94U/7fX/02XL+z1f36LvntVynv3f/2rw/+tH4K/UP/P/Tb+b2E+ Yeb/qP93Hf+nz/d/g93Bz6uEnwbf5/+mUxdr9f+eNyhLDavGbX6n/9OTrnbMZsn/+ekEt58v 5v+W6/89d1j6+n/6B/yfVyJl+b/09f+ef/Wd/F9lZ0fwfwtTP3P/p1f93wT+7PZ/73joVv6v mSR3Nf8nVvyff77K4v90O4l4sP9zl4Ys/s8v0LKj22L8nztCs/g/bS8Neer/+bFFzDVwug0h 8H8C//cl1EpW+L+NKA//l9D/uYWPvtvp/2bbcBOq5fk/XeH/kmT15v8qrY3/66P8X2fuwr4T P+L/3IRFnP9zg4of8n/2CCzM/0m7YK+0+n9tldz/mblb/B8tsI3+rz4wRpj/a5z/6x4C/3d8 M2c5/i983hv/F58V/i9iWHG+/3OP11n8n5/tT4ry8H+RoZb9n8b/XcX/KTucp/7flncU+L/4 UPg//N/HYYH/+4iF/8P/4f9WQ+H/IrLC/0WGupX/6+yG8X9BofB/F/V/bvYW/7fFU2Tyf1Kt +T+/cD7K/7k9U7T/q/vz6//h/7b5P+r/Rfq/rrqT/+uHXP5P9NbGyN7LkJ1Li4ZJZ94rne7/ 7Gr2HPX/qtrX/6v2H4F9b49y3+H/dlxuz/J/zwc0/F9gVvi/4vxfl9r/2YMd/xf3WeH/RNgD Kv6P+n8C/zdN6rhQ+D/830qoWVLTp4hi/F/T1bbrI+r/zbYh/irlleX/VIP/S5LV3P9Vvfl0 pOz99xbt9H9mLOk7+wSP/0uS1U38X/L6f2aWszz/Z749EP9HC2yj/2sOjBHm/1rr/xr5EPi/ 45s5y/F/4fPe+L/4rPB/EcOKTP7PDCtW/J8bT+Twf8q/8cT/fT0s8H+BWd3Z/9kHxqT+TzX4 vwRZ4f+u4P+6Af8XGwr/9xkL/4f/w/+thirM/6kO/5coFP4P/zffg/i/+FC38X9+xR7+D/83 adf2f6+sTvR/7uKK//vi/5oG/xf2WZ3n/8Sa/+vwf5H+zy9UdPv5Yv6vbZb8n2pqmdr/2VVM Z/u/3q+vx//NQ73X/5PDvfyfvXvg/z6nfk7zf8+BdHn+T/ar/k9NkivG/7mxRR7/53ZgDv/n D7cs/s9fju316WD/56+z9vXSsf7PIYg8/s+94qL+H/5vmtRxofB/+L+VULOkpk8Rxfi/2r4B eT491rtDzbfxE/7PPRD4bq//8zOpfl51zAr/l9T/Kdk3+tk9R5y7Q8nnwL/968RP1P+r3Xbr qJWjo/97G1uc6P/c+VKY/2vNYD2p/xO6wv8FhsL/FdpG/9ceGCPM/2nn/+qHwP8d38xZjv8L n/fG/8Vnhf+LGFZk8n+q+QH/56Zt8X8bDouz/Z9U+L/r+D/z20n9X63xfwmywv/h/96zwv9F hsL/hYZ634P4vwQ7EP8XGaow/9c2+L9EofB/+L/5HsT/xYe6i/8b/KQZ/m+v/+vc4xH+747+ z7xWx/+FZYX/u6r/W63/d2n/p/B/gVeLN/+nukX/p4bk9f/Mizn8X8gOFFv9XzWk9n91eyv/ Z8cWF/V/UmXzfyYU/i8k1C/6P/vsgf9b2oH4P/zflrEF9f/wfyuh8H/4v5VQs6SmTxHF+D93 GVe1XW+y0//NtoH/E4f5P/dkWpb/q3pdm+kL7T6knf7PPGb6bhIK/4f/W8gK/7fT/2n8Hy24 jf5PHxgjzP91zv+1D4H/O76Zsxz/Fz7vjf+Lzwr/FzGsyOT/zBT7sv9za6Oy+D8/XMf/XcD/ 9fi/6/g/u6Aopf9revxfgqzwf1fwf63C/8WGwv99xsL/4f/wf6uhCvN/UuL/EoXC/+H/5nsQ /xcfCv+3/WC/t//TKfyfGwJ+839+BWKc//MLfPF/B9f/c9vF/+H/Ji29/5OquZX/q1P7v1r/ gv/zM8luPxfh/+Sga+r/3df/mcPiRv7PLXrA/y1M/Wz1f+rV7fZ/atqV6f/Uqv/rJ105/s9d kXL4v9ad4ln8n9tbOfyfv4nk8H/+hML/4f/wf/i/t8MC/4f/+8zqzf9Jd0mXg9zv/+bbwP8J /N92/yc7/dzEc4DmH+X2+T/dyL9OUP8P/xfk/zrzXJDW/71u+Gf5v6Y3Ez9J/Z+ZD8T/0QLb 6P+6A2OE+L/W/P9SPh+OHgL/d3wzZzn+L3zeG/8XnxX+L2JYkcv/qVX/56YCc/g/NxmN/9tw WJzt/1SD/7ux/9MV/i9BVvg//N97Vvi/yFD4v9BQ73sQ/5dgB+L/IkPh/yKywv9FhsL/BaaF /xs7/B/+r2z/N1m+sNv/vZSY/aE1/+cXzkf5vxecmWV1uP+rdYH+T6zW/3N3EfzfwnzC1P+Z B0f8X9Bn9Vb/b+hK9H+6RP9nQhXo/9pmsf6fNg97+L/lUD/n/8xVL63/M9fAO/k/N914Sf8n 9Ir/axsTI6X/e95E8X9BobbX/7uy/9P4P/yf/Yzwf/i/raHwf/i/tVArWeH/vj2JnOv/lJ1j el4oIvzfbBtmlHu+/3OvxyL9nx80uP01aPxfkqze6v+18nkPl6rzZHOf/xtk89cJ/B/+L8T/ qSq9/zu//l+j8H+0X2ij/+sPjBHm/6Tzf/VD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy+b9mvf5f Pv+n7Sgpi/9zb2bwf1tWmOP/wq4Wv+f/TFbU/9vyjgL/Fx+qMP8nOon/iw11tv/rk/u/uqrw f/i/1R2I/4sMhf+LyAr/FxnqVv7P/Tr+LygU/g//9zeliv8z/4H/+zX/Vzf4vyj/1+nU/s+s Zsf/BX1Wb/6vl7n8n/laxPL8n2qW/Z9skvs/eaf6f9WgJf7vMv7PvG5M6v9kP9zL/3W2u6T/ k2v1/w7wf+JO9f/U0Kb2f02Z9f9W/Z9bB5HF/zWTUu4H+z839sji//zS6Cz+z19n7esl/B/+ 7+hQ+D/831qolazwf9+eRM71f40dEPhup/+bbcOOA/F/n6Hwf0v+r+qr5+ODVHpws1r7/F9v 7nK+E/g//F+Q/6uT+z/zhH+2/5NdLdL6P/OFavg/WmAb/d9wYIww/6ec/2sfAv93fDNnOf4v fN4b/xefFf4vYlhxvv9zKwVy+L/Br1XB/309LM72f3WF/7ux/1MN/i9BVvi/C/g/6v8V4P86 +3o/pf8zIyb8X2go/F/i5wP8X+QOxP9FhsL/fYTC/+H/8H/Loc72f88xoEsH/7fX/3nxY+/1 u/3fzJQJveL/3BLbSP/nl8Rk93+6XvF/buPX9H+WRC36P+22W5j/q1L7vwb/F+n/2ub8+n9N cv9Xr/m/IbX/a9Ra/T87FJOD8kRm1x1/rK+lxlB38X/Pi0Tn6v9Vw/7Lbd9X+tXZIxD/F7ID xXn+r27xf4FZ4f8K839VLZP7v5vV/8P/4f8W/J+Ngf9buong/2yH/9saaiUr/N9GlIf/S+n/ 3MNbW9e7Q8238Qp1ov9T/eS5YLf/c8etn1ftVIn+z0wmnOn/xNDrrjZvRNyrv53+rzNTpL6b ZIX/S+7/7FgT/7ewSHXq/5oy/V+F/6MFN+//miOtXZj/q63/U/oh8H/HN3OW4//C573xf/FZ 4f8ihhW5/J9a839uAjSH/6vdXCr+b8Nhcbr/0/g//B/+Ly4r/N8V/F834P9iQ53t/3Rr7zUp 6/9p/B/+b30H4v8iQ+H/IrLC/0WGupX/c6vA8H9BofB/+L+/KdV7+T/3p8T5PzfpU7T/W63/ 51deJ/R/ZrVFJv/Xr/m/1l1cy/J/uknt/2qN/7tK/b91/+dei6T0fyJb/T9/BIqP1qvU/q9u mvP9X2vzOL7+3/PqUKf2f/Uv+D/PbPB///Z/Fibj/4KyOsv/WX1Vnv8zn9XJ/k+lr/9XpP+z AnXR/7VumU8W/+dHVPbHDvZ/7tKQxf+5m0gO/1f5Msf29dKh/q91jyBZ/J8/AvF/+L9pUseF wv/h/1ZCzZKaPkUU4//qwdXuU/tDzbdhRrkl+r+6yPp/Z/s/U4VJWf9XNbtDybYzw1rfTULh /1L7PzdTUZj/s0PZtP6vL9L/Uf+PFt5G/ycPjBHm/xpX/696CPzf8c2c5fi/8Hlv/F98Vvi/ iGFFJv9nhhXL/s/NAWap/+e+9y4lytP4v2P8X2NGtPi/TaFW/F93QKgV/2fXHab0f+Z9Ev4v Oiv83xX8H/X/8H/2t/B/Av+3dQfi/yJDFeb/VIf/SxQK/5fY/9lhJv4vLBT+75L+T/R+xR7+ D/83aQf4v6a7lf/r3OGG//u3//PV1/B/F/B/z0t2gf5vvf5fcv/XVGv+zy9ULMr/Da1M7f/s Kqaz/Z+/reH//u3/blf/z14t8H+fUz9b/V/96nb7v3ra/YD/a3P6v3aS3MX8n1iv/+cGZ1n8 33Ql+rH+z683yeD/xOAPdju6Pbj+X5n+z+2tHP6v92OLGP833YYQ+D+B//sSaiUr/N9GlIf/ S+n/7APq80bV7Q4134YZMv2M/6si1i7/+b9xBvJ8/+cgWEr/J+uz/V9fPe9LUrWDexG40/+Z 75Lw3fNnpMb/JckK/3dd/2eXnSX1fwL/Rwtvo/9TB8YI83+t83/qIfB/xzdzluP/wue98X/x WeH/IoYVmfyfan7A/9V+rUpSlIf/iwyF//sIdTX/Z3Yw9f+2vKPA/8WHwv/h/z4Oi+L8n1lE h/8LDYX/S/x8gP+L3IG5/N8U5eH/8H9vofB/MR8W/i8+FP5v+8F+b//nTFmk//PLK5u3UO/+ r391u/2fnnZl+r9XVof7P4X/i/J/1P/D/53r/36i/l+B/k9J3eH/7uv/blf/zx5z+L/PqZ+t /k+/ut3+T087qU73f1nr/+H/8H/4v4DDop51P+D/qP+H/8P/4f9WQ82Smj5FFOP/Knejqtph d6j5Nn7C/9Xu9VhK/9cp/F+SrOb+T1X6OYKWz4G7m87a6f/sGzbXCfwf/u9s/6dK9H8mK/wf LbCN/q8+MEaY/9PO/zUPgf87vpmzHP8XPu+N/4vPCv8XMaw43f+5gW8W/9e6Ryv83wX8n5mk wP9tCrXi/+oDQi36P2knlJL6v1rj/xJkhf+7gv+rW/xfbCj832cs/B/+D/+3Gqow/0f9P/zf P0Kd6f+0/YIQ/F9YKPzfRf2ff2+K/9vr//xKtzj/NzVlZtnysv9zU4Ku2+3/psP2SVb4v8T+ z6WA/8P/Tdql/Z9ofsD/Dfn8n41hpvXtD++743d+rd544Vnxf/7FXEn+Tz7PpCL9X+fX1+P/ 5qHe/Z+5MN3I/9k9d1H/Z4YxBfo/cXb9v0YPOf1fM0muHP/nrkhZ/J+/cNkfO9j/ue1m8H+y ckd2Dv/n6thn8X/u0Mvj/9xiOvwf/m+a1HGh8H/4v5VQs6SmTxGl+L/no7L9n70dT+wMNdtG qf6vp/7fEf5PVu1z4GL8X632hpJtZ54nfCd+wv8pNyDA/317EvkF/1dXojj/V2uzgCSt/+vx f7TgNvq/5sAYYf6vc/5PPwT+7/hmznL8X/i8N/4vPiv8X8SwIpP/M69DTvd/vX87jf/7elic 7f/aFv93Y/9H/T/832oo/B/+7+OwwP99xML/4f/wf6uh8H8RWeH/IkPh/wLTwv+NHf4P/4f/ E1+WV05NGf4v1v+p7nz/53Yg/m9hPgH/l9L/tU2J/k9n839m6iKX/6tu5P9ULZPX/zOHBf4v ZAeKrf7PfEhJ/Z+sevxfYFan+b8e/3eM/+sH/B/+D/8XcArj//B/W0Ph//B/a6FWssL/fXsS Kc7/1bpE/6cr/F+SrN7q/6mutv6vm40Dg/1f/dcJ/B/+72T/V+sK/xcYCv9XaBv9X3tgjCD/ Jyvn/+RD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy+T/zaLXs/9y8eBb/V/u1Khn8X3MENbyV/1MC /7ct1Ir/OwKJLPu/Prn/a3r8X4Ks8H9X8H9a4f9iQ+H/PmPh//B/+L/VUPi/iKzwf5Gh8H+B aeH/xg7/99v+z6/Yw//t9X/ahcri//yjwSX9X9eUWP+vX/V/brv4P/zfpF26/t/zkl1g/T+z hiST/2vUmv/zWefwf3ZKMKn/a6pF/9e2kvp/+L+b+D93lOP/FqZ+TvN/z4E0/u9zB17L/7Wu gkoW/+dO8Sz+z10js/g/v0DLXp+O9X/Sj7ft6yX8H/7v6FD4P/zfWqiVrPB/355ETvZ/7kVS J+v9oWbbMD9Zov8bqxqe6f+knwhI5/+EPtv/PQfY9bPr/NrAff6vH5q/TuD/8H8n+z/zhH+2 /2u7WuD/aKe30f/pA2OE+T/p/F/9EPi/45s5y/F/4fPe+L/4rPB/EcOKTP6vWa3/l9H/uQlO /N+Gw+Js/6cl/u/G/s+8usL/RWeF/8P/vWeF/4sMlcv/VQ3+D/+3ugPxf5GhCvN/bYP/SxQK /4f/m+9B/F98KPzf9oMd/yfwf0uv1Wf+7271//B/W/yfr76G/9vt/wZVYv2/Vf9XJ/d/Gev/ 6Tv5v65OXv/vJ/yfXy+N//vi/7TC/wVmhf/D/32+Gr6F/xMr/s8vJsri//yVvTD/528i1P/D /+H/8H8LoVaywv9tRHn4v4T+T7sZE23fnewMNdvGK1RZ/q9v8H9Jsnrzf1o/xxbyOZpQzd5Q UtvnQN+Jn/B/tZsvxP9teBIpz/9Nbvj4P/zfvdvo/7oDY4T5P+X8X/sQ+L/jmznL8X/h8974 v/is8H8Rw4pM/q9erf/n1kZl8X/9ESgP/xcZatn/mWMA/7cp1Ir/O+IauOL/TFb4vy3vKPB/ 8aHwf/i/j8MC//cRC/+H/8P/rYYqzP9R/w//949Q+L+YDwv/Fx/qNv7PPU7h/7Z4imX/51fd pvN/r1Bv/s9JFPzft0PwF/xf6y6u+L9/+z/q/13I/72yersuXdn/+SNQfLQD/F+16v/8dILb zxfzf7pb8n+1ahuz4LtVzf7L7VDZg9p39nKL/wvZgeI0/2e+4+dG/k86pJXD/9WNfXpL6P9M hRT8X1BWW/1fndz/qSL931r9P/wf/g//F7ID8X+uw/9tDbWSFf5vI8rD/yX0f2Ptvioi1Gwb ZpR7uv9Tbm4k0v/5QcM444z/S5LV3P/VSj0H2s9n7qraHUrq3oxPfCfwf/i/EP9XV2awntb/ 6fP9X2MmXJP6v+edHP9HC22j/+sPjBHm/2rn/7qHwP8d38xZjv8Ln/fG/8Vnhf+LGFbcyf/p 2v0p+L+vh8Xp/q/H/+H/8H9xWeH/8H/vWeH/IkPh/0JDve9B/F+CHYj/iwx1qv+zRaKS+r8p ysP/4f/eQuH/Yj4s/F98KPzf9oMd/yfwf0uv1Wf+T1Ul+r9+1f9R/2+L/6P+34X8n17zf52c RLyY/8tY/8+Euo//q7RK7f/GrD4/LPzfz/m/Xt7L/9lj7qL+T1D/D//ndsa0+wn/5wZnWfyf u4lk8X/uyp7D/1X+YK9c3EP9n7/O2tdL+D/839Gh8H/4v7VQK1nh/749iZxc/88Nc7S96u6t /zfdRqn+j/p/8W8bl/xf1T4f5WTd9O5D2un/zJDOd/Yn8X9JssL/7fR/rxs+/g//d+82+r/h wBhh/q+x/q+RD4H/O76Zsxz/Fz7vjf+Lzwr/FzGsyOX/qjX/577gLIv/cxOcefxfc0CoG/m/ zrz7wP9tCnW+/7Mzzyn9X9Pj/xJkhf+7gv/rB/xfbCj832cs/B/+D/+3Gqow/0f9P/zfP0Kd 6f/a3h7a+L+gUPi/i/o/v2IP/7fb/7nhGf7vi/+7W/0/N0+B//u3/6P+H/7vXP/3rf5fPfrl KP/n7q/r/s9dJnL4PztOT+r/VL3o/5oqef2/pv8B/+dn/cvyf9J8B2hS/2dqHtzK/9n7Lv7v c+rnxv6vHdL7v37V/9WT5Mrxf+5qksX/ucMmh/87ZH3qiv9zA4kc/m+s0mtfL+31f36O79/+ T7sZ/Cz+T7sv/cb/4f+mSR0XCv+H/1sJNUtq+hRRiv+TVdu8un2h5tt4hTrT/7kZgLrS+0P9 DRrc/eon/J/9YJL6v/ps/6eG5/jS+L9a7Q1l4F/z14mfqP+n7Ft8/N/XJ5Ff8H9mWEv9v6VQ M//3vFri/2ihzfu/9khrF+b/Wlf/Tz0E/u/4Zs5y/F/4vDf+Lz4r/F/EsCKT/1PN+f5vfLTC /+H/Zg3/F+f/7FcxJ/V/UuH/EmSF/7uC/6tb/F9sqAL9n8b/4f/WdyD+LzIU/i8iK/xfZCj8 X2Ba+L+xw//h//B/4svyyqkpm4TC/+09BM/3f+5ww//92/+Z1ez4v6DP6jz/J9b8n9aTiPi/ Nf9nQt3H/ylznX1e9GIut4NbUziMSwt/wv/59fXH+z/Re6B0uP9revNmM6n/k1rdyv9JN92I //sd/2c+q5P9X9fi/y7j/2Yr0fF/4f7PLY/JUv+vd7sf/4f/w//h/xZCrWSF//v2JHKu/3Mv Xny30//NtvEKhf/D/y1k9V7/T2tt/Z97PNjr/9RfZ38S/5ckq0//Z8ea+L+FRapT/2deVJzs /5qqS+7/zNta/B8trI3+Tx4YI8z/aef/mofA/x3fzFmO/wuf98b/xWeF/4sYVpzv/9zjdY76 f+4tWUqUV6/6v+Sh7uX/+gr/dx3/ZxcUpfR/qsH/JcgK/3cF/6cV/i82VHn+r27wf/i/9R2I /4sMhf+LyAr/FxkK/xeYFv5v7PB/+L+i/V87fr+qEPv9XzXt1v1f84qI//vnIZjL//Wr/s+l gP/7t/+j/l+s/9Pt+fX/0vs/XaL/+0f9P/djOfyfPaiS+j8Taqn+n7lDyVrXav/ldqjsMeW7 u/m/8Y5xSf9nnvHv5P/syl7838LUz53r/x3g/1SJ/s+sT130f8JNx2Txf34H5vB/fr1JBv8n Bn+w29HtwfX//Hjbvl7C/+H/jg6F/8P/rYVayQr/9+1J5Fz/56ZIfLfT/8228QpVlv+rNf4v SVbv9f/655DUfG+RVHtDST2Yh2ffiR+p/+eGY4X5Pzulj/9beOye1/973fAL8n91hf+jBbfR /6kDY4T5v875P/0Q+L/jmznL8X/h8974v/is8H8Rw4pM/s9MRi/7P/9ldDn8X+XXqiRFefi/ yFD4v49QV/N/dt1hSv/X9Pi/BFnh//B/71nh/yJDUf8vNNT7HsT/JdiB+L/IUIX5vynKw//h /95C4f9iPiz8X3wo/N/2gx3/N24E/zd7rX4D/7de/8+lgP/D/03atev/Fen/fAVK8dGy1v/z M8luP1/M/6lu0f+1Rg3Juuvq/ZfbQfbq1Vn7gv8L2YFim/9rK5NCWv9nroH4v6Cs8H/4v89X w3fwf2Kt/h/+D/+H/wvZgfg/1+H/toZayQr/txHl4f/S+T8x2IG0GOy4YGeo2Tbs2KJA/9f0 Jfq/ujrb/7VVY7+3qIvwf11lhq2+sz+J/0uS1T38X20G62n9n67O9n91l9z/mblb/B8tsI3+ rz4wRpD/U5Xzf/Ih8H/HN3OW4//C573xf/FZ4f8ihhWZ/F+z6v/c2qgc/k/6bzjA/13A/2n8 33X8n/n3pP7PvLrC/0Vnhf/D/71nhf+LDJXL/1X4P/zf+g7E/0WGwv9FZIX/iwx1K//nlkTi /4JC4f/wf/f0f+PCVLORvf7PrZv86v/8k1ic/3N7pmj/p7rz/V/j15bj/z7mE6b+z0y14/+C Pqtf9H/tJOLV/J/6t/9Tgz/To/yfm4er7uT/at0m93+/UP/Pk4Oy/J+dKcb/LYba6P/cdCP+ D/93qP8ziHzF//WTrhT/Jyv3MJXF/7mbSBb/51LI4P/8Dszj/9wFL4f/03a7Wfyfm5LL4//U q9vt/9S0w/8J/N+XUCtZ4f82ojz8X0L/17nH+U7X+0PNtvEK9Qv+LyLUHLU8f/J0/6f8Q3BC /yfbs/2f0oM0DwXaJbfX/3V/nfiJ+n8e/hXn/8wOxv8tLVKd+j/zouJs/9cO+D/aD7TR/zUH xgjzf9L5v/oh8H/HN3OW4//C573xf/FZ4f8ihhU38n+qxf9dxf8NCv+H/8P/xWWF/8P/vWeF /4sMlcn/1Q3+D/+3vgPxf5GhzvR/nU0hqf9rG/xfolD4v8T+j/p/+D/8H/7vY9B5uv/zpQap /3cB/+cW1uP/FuYTpv6P+n+x/q/TufyfVPn8X9OU6P/KrP9nvtx+wf81dfr6f/i/o/xfJxP7 P9kP+L/ArPB/Sf2f+azwf2ED6Xra4f/wf3Yj+D/8n/lR/N9SVvg//B/+L7H/6yLq/822YYZM +L+FUPi/Rf9XPz8e6//63aEM/Gv/OoH/w//h//B/tN9oo/9rD4wR5v+U83/tQ+D/jm/mLMf/ hc974//is8L/RQwrMvk/M8W+4v+cFMrh/xo/258O5Wn830H+r8f/Xcb/2SnNpP6v6fF/CbLC /+H/3rPC/0WGov5faKj3PYj/S7AD8X+RofB/EVnh/yJD4f8C08L/jR3+D/9XtP/zqzFy+D+/ rBn/dwH/5y79+L+F+YSp/6P+X6T/ez7Fl1j/L5//8wJVfLT0/s8c7Mv+z1/5i/J/engeerIe 6ogjcHAPncP47In/u4z/s9fAG/k/u4mr+j/9C/6vf3W7/V8/7fB/+L/lzwr/J4JGt7/n/9zr SPzfwk0E/2c7/N/WUCtZ4f82ojz8X0L/p904savq/aFm27BjiwL9n1T4vyRZvfk/rbTxf4O/ Ue3zf/Ya4zuB/8P/Bfm/1pziSf3f3zUQ/4f/u3sb/Z8+MEaY/6ud/+seAv93fDNnOf4vfN4b /xefFf4vYliRy/9VRfo/seb/2uGAUPfxf03V4P/wf/i/uKzwf1fwf3WL/4sNhf/7jIX/w//h /1ZDFeb/VIf/SxQK/4f/m+9B/F98KPzf9oMd/zduBP83e60+839dk83/vbLC//24/6P+H/4P /3dt/2e49ZL/q553qOdlvWr2X24HdwfynX0xdyf/54vI+m6n/3ufZcrl/3qJ/wvM6g7+T9/K /ymZ2v+ZNY9n+7/BHXMp/Z+4l/87ZH3qsv/z98Ec/k/Vrw7/9++xBf4P/7cSCv+H/1sJNUtq +hSB/5uE+kH/148rS/eHwv/9dUf6v7bVnfF/nZ8I3OX/GjOB7jv7BI//S5LVPfyfNsNa/N9S KPwfLbaN/q87MEaY/2us/2vkQ+D/jm/mLMf/hc974//is8L/RQwrMvk/1az6P7dSIIP/k50d JeH/NhwWp/s/s7fwf5tCne//7IIi/N+GdxT4v/hQpfm/rsb/xYYq0P9p/B/+b30H4v8iQxXm /6j/h//7Ryj8X8yHhf+LD4X/236w39v/6erV7fV/qpp26/7PBY7zf37qMrv/K7P+X7/m//wa M/zfv/0f9f8i/Z/oO/xfYKj51IX6Bf/ns3b7+WL+b63+n7kZpvV/d6v/d2n/J+5V/69y042F +T+Z3P+JfP5PqrP9X9Mmr/+H/8P/4f/aAf+H/8P/JQm1khX+byPKw/+l9H/ufqXbiHHgbBt2 gVaB/q/W5/s/n1VC/ye68/3fYOv/dVLtDWXgX/PXCer/4f/wf3Vb4/9oP9BG/9cfGCPM/7XO /9UPgf87vpmzHP8XPu+N/4vPCv8XMazI5P/Mqo6z/Z9yb8nwfxsOi7P9n1T4P/wf/i8uK/zf Ffxfo/F/saEK9H/U/8P/4f/eQuH/1vxfL/F/iULh//B/8z2I/4sPhf/bfrDj/8YO/zd7rX4D /7da/w//t8n/Uf/vQv5PZPN/z7tDtvp/VTb/V+si/d/zYW7J//Vd8vp/+L8L+b+2wf8FZoX/ K83/NQP+b9OqW43/w//Zzwj/h//bGgr/h/9bC7WSFf7v25PIuf6vdRMW2t7wd4aabeMl5cry f6NqxP+l9X9d3w/G/+l+dygD/6q/TuD/8H8n+z/zouJs/2cXf+D/aGe30f8NB8YI83/a+b/2 IfB/xzdzluP/wue98X/xWeH/IoYVufyf+gH/58bYefzfEaHu5P96/N9l/J99+kjq/xT+D/+3 Fgr/h//7OCzwfx+x8H/4P/zfaij8X0RW+L/IUPi/wLTwf2OH/8P/Fe3/mnH9qhC7/Z+c6oVJ qHf/5x8NovxfO42I/zvK//lHN/zfv/0f9f8u5P/W6v/VephETFL/T/QF1v/7h/9zP1aU/2vN dbZA/+e+LRP/9x7qzf/Jqr+X/7NIC//3OfWD/8P/fV11u+b/hB+/ZPF/05Xox/o/v9Akh//z S6ML83/u0MP/LdxE8H+2w/9tDbWSFf5vI8rD/yX0f9qNPbSOuAbOtvGScvg//N9CVm/+r9GN 83/uQ9rp/8yQzncC/3eg/7N54P8WFqni//B/tIXm/Z8+0tqF+b/O+r9aPwT+7/hmznL8X/i8 N/4vPiv8X8SwIpP/a/B/+L/lUPi/j1C3939Nhf9LkBX+7wr+r6vxf7Gh8H+fsfB/+D/832oo /F9EVvi/yFD4v8C08H9jh//D/+H/xL8npe/g/7omm/97ZYX/w//h/8Tug/08/1cV6P9MqAL9 X9vk8n+mViP+L2QHivP8n1b4v8Cs8H/4v89Xw2/+T5Xo/8xAGv8XltUP+j/96nb7PzXt8H/B 10D8n+vwf1tDrWSF/9uI8vB/Kf1fZber24hQs22U6v/Gqob4v4P8X632hjLwr/nrBP4P/4f/ w//RfqON/k8eGCPI/9WV83/yIfB/xzdzluP/wue98X/xWeH/IoYV5/s/dzxk8H9Su+E6/u/3 /Z8yL8Lxf5tCne//7Mwz9f82vKPA/8WHwv/h/z4OC/zfRyz8H/4P/7caqiz/Z2oD4P/ShML/ 4f/mexD/Fx8K/7f9YL+5//MxzEZ2+z+vxKq3UG/+b/QWUf7PL/DN7v9W6/+5jZdW/8+bDfzf v/1frfF/l/F/Av8X5f/W6//5C1dR/k+1TWr/Z5zS+f7Pr6/H/81Dvfu/ur2T/6vcg+JF/Z8o 0v+Zz6o8/7da/093k+QO9X+9fa+UtP6fapb9n/RXpCz+z53iOfyff3zI4v/cfTCL/5vMJhzs /9yalSz+r7OXhiz+r/erm2P833QbQuD/BP7vS6iVrPB/G1Ee/i+l/3PXWW0fmff6v+k2nhdw VaL/k6pI/1ed7f/U87qX2P/ZGWn8X4KsPv2fXcqE/1tYpDr1f3bmDP8X93x1tluipWmj/1MH xgjzf9L5v/oh8H/HN3OW4//C573xf/FZ4f8ihhU38n9KJfd/Gv93kP8zL+zwf5tCFej/pMb/ JcgK/3cF/9do/F9sKPzfZyz8H/4P/7caqiz/R/0//N+v+j/tVgXi/4JC4f/wf39Tqvg/8x/4 v5n/U1U2/9c2+L/AHUj9P/zf0mdVTzvq/x1V/+/S/s8sbvv0f6rTKrX/M+t98H8hO1Cc5//6 Af8XmNXv+b/uyv7vB+r/1R3+D/+H/ws4hfF/+L+tofB/+L+1UCtZ4f++PYmc7P/cY4fW9f5Q s23YsUWB/m/M6kT/N5qykvyf0p2U1P9bmfz+Nf/XVbXr8H/vj93U/8P/0Zba6P/qA2OE+T/l /F/7EPi/45s5y/F/4fPe+L/4rE71f37whP/7t/8z39N6tv+Tdo1+nvp/Y9b4v6+hFv1fbYaZ Bfq/btIV4/9qt/4B/4f/m7XZj5Xi/9wbTer/bQmF/wubHZktotP4P/zf+g7E/0WGwv9FZIX/ iwyF/wtMC/83dvg//F/Z/s9fk0zESP8n27dQb/6v8e+po/yfD5Xd/92s/l+H/9vk/3r8X5T/ k7I53f81Cv+3xf+t1/8T/hR2+7kM/9d2VZn+z93wc/g/Pzy6pP8zax5v5f/sqAz/9zn1c2P/ V7d1Pv/nsrqo/zNH4I38n3/oKc3/6Vd3rP/TlQ1VnP8bXt1u/zdMO/yfwP99CbWSFf5vI8rD /6X0f752n1vVGVf/r507pbL831jRC/+X1v+11XOQafyfavaGMvCv/uvEj/g/NfnIivF/9k+R nb/97vR/0xcVrxv+ef6vqyuR2P/15/u/2vwpSf3f806O/6OFttH/NQfGCPN/jfV/TfUQ+L/j mznL8X/h8974v/is8H8Rw4pc/q9a839u4Jul/p+bgsf/bTgszvZ/jRki4v82hcL/fWSF/8P/ Xcb/aYX/iw1Vnv+rG/wf/m99B+L/IkPh/yKywv9FhsL/BaaF/xs7/B/+r2z/1766g/2fX84S 5/+mw/ZJKPzfHv9nSRT+Lyirmf8zU+34v6DP6vfq/13a/9X6B+r/lej/OnNJL9D/+UF9Yf7P nAxp6/9phf8LzOo0/6eL9H/mszrZ/zWyRP83VPg//B/+LyAU/u+IUPg//N9aqJWs8H/fnkRO 9n/uJhLn/6bbEIXW/2v6Ev2fmUw4uf5f87zqGf9X7Q5l4F/11wn8H/7vbP/3A/X/8H+0n2ij /2sPjBHm/1rn/9RD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy+T/VrPo/N57IUv/PPVpl8X/6gFB3 8n9mUh3/tynUsv8bXzvFvHn5mGJf8X9mb+H/tuxA/F98qNL8Xz/g/2JDlef/mgr/h/9b34H4 v8hQ+L+IrPB/kaHwf4Fp4f/GDv+H/yvb//lrUpT/83vwW/0//576kv6v7Qv0f+ZrdVf8n0sB //dv/+err+H/dvu/F8o7z/817STixfxfzvp/1Zr/8wvrr+n/2mbR/+lOpfZ/Zgee7//cJT2L /3MpXNP/9cOd/J+0IKU4/9ck93/1rfyfGvB/m/yfxv/h/+xntM3/afwf/g//lyTUSlb4v40o D//32/6v1iX6v1+o/1e59UVF1f/T9fNRTtaDn8vf6f/McNh3Av+H/8P/4f9ov9FG/6cPjBHm /7Tzf81D4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCtu5P+UxP9dxv9p/N+N/Z9o8H8JssL/XcH/Uf8P /2d/C/8n8H9bdyD+LzIU/i8iK/xfZCj8X2Ba+L+xw//h//B/4t+T0nfwf7XM5v8MSMH/hd2H P1az4/+CTuEb1P+TqkT/l7H+X63v5P8a3af2f3bNI/4v7LA4y/9VPf4vMCv8X3H+r07u/xT+ D//nds20w//h/z62IQT+T+D/voRayQr/txHl4f9S+j/duk7vDzXbhvmhEv1fp/B/SbJ6839N XbfW//m5up3+T/51Av+H/8P/4f9ov9FG/9cdGCPM/3XO/+mHwP8d38xZjv8Ln/fG/8Vndar/ 8y8+8X//9n9mVcfp/q+yoyT834bD4mz/15pTpUD/5z/LDP7Ph8ri/8wOxv9t2YH4v/hQ+D/8 38dhgf/7iIX/w//h/1ZD4f8issL/RYbC/wWmhf8bO/wf/q9o/+eXBcb5P7/q9pv/c6Hi/J+f acnu/25W/29Uj/i/j/mEqf+rNf7vKv5vklVB/u836v+5LIvyf51Wqf2fudzi/0J2oDjP/2l1 K//nFiJe1P+JIv2fVPi/hR14Kf/nV3pm8X9ewuTwf/4qlMH/CTcAzOP/JrMJ+L9/jy3wf/i/ lVD4P/zfSqhZUtOniHL8nxuJxfm/6TZeocryf79Q/88/7RTl/zrVSuP/mmZ3KNk15tHddwL/ h//D/z0vFqYmZkr/97yq4v9ooW30f/2BMYL8X1M5/ycfAv93fDNnOf4vfN4b/xef1bn+z0/B F+X/1JDa/zW/4P9qv1YF//f1sMD/BWZ1a/9nF5Dg/zbsQPxffKjS/F8/4P9iQxXo/zT+D/+3 vgPxf5Gh8H8RWeH/IkPh/wLTwv+NHf4P/4f/E/+elL6D/8tY/y+j/1P4vyj/R/0//N+5/u83 6v/5ga3bz0X4P4NEUvu/Bv93Hf9Xt/fyf5Xr8H/vUz/U/8P/LY2Y8H/4v4VTGP+H/9saCv+H /1sLtZIV/u/bk8jJ/q+3N9ZO1ftDzbZhhoMl+r9fqP9XoP+TfT3Y+n9+mnin/7Mv81wn8H/4 v7P9X1+k/1P4P1pwG/3fcGCMMP8nnf+rHwL/d3wzZzn+L3zeG/8XnxX+L2JYkcv/qTX/5+bF c/g/OTi6gf/7ff+nTa3GAv2fP8Vz+D+fVcybl63+z848J/V/Ff4vQVb4vyv4P+r/4f/sb80X 0TX4P/zf+g7E/0WGwv9FZIX/iwyF/wtMC/83dvg//F/R/s+te430f+20W/d/bm7omv6vzPp/ q/5Pu7MI//dv/0f9vwv5P73m/+p+EvFi/i9n/b9V/+dXoGXwf1VvtpvU/5lQS/X/6j61/zMF FPF/ITtQbPR/Utep/V/V38r/VW668ZL+zwxjlv2f3VtJ/Z9sqf8XFOrN/5mbyIr/qyfJHer/ ens/S+r/hjX/5xxTFv/X+hFVzFvojf7PXyMz+D/pLulZ/J8/oXL4P/fvefyf21v4P/zfNKnj QuH/8H8roWZJTZ8iyvF/unZdsz/UbBv4P4H/2+7/lB56W/9PdWpvKNk9D9y/TvyI/2snXTH+ zx16+L+FRar4P/wfbaF5/9cdae3C/J+y/q9uHgL/d3wzZzn+L3zeG/8Xn9W5/s/fefF/749W M/9npthP939+BQ7+7wL+z0w34P82hTrf/5l9gv/bsgPxf/Gh8H/4v4/Dojj/11T4P/zf+g7E /0WGwv9FZIX/iwyF/wtMa+7/VIf/iw2F/4sMhf8LDfVz/s+vQIzzf/7Dyu7/yqz/1+P/ovwf 9f9i/d8L5eH/9kxd/ET9vwL9X12pivp/l/F/5nk0qf+zp/Cd/F9nO/wf/u+s+n/1JDn8H/7P /zP+D/+H/0sSaprUcaHwf/i/lVCzpKZPEcX4v85ODPtuZ6jZNl6hyvJ/o2osy/+Zudtz/d9Q P8eBxv+pZm8oA//qv07g//B/+D/8H+032uj/5IExwvxf7fyffgj83/HNnOX4v/B5b/xffFb4 v4hhRS7/V635P+WOhxz+r/NrVfB/Xw8L/F9gVr/n/6TflQlCffF/rVv/gP/D/83a7Mfwf2v+ rx/wf7Gh8H+fsfB/+D/832qoM/2ftg8GSf1f3eH/EoXC/+H/5nsQ/xcfCv+3/WDH/43d0f7P XU6u6f/0kM3/vbI63P+t1//za8vxfx/zCfi/a9b/k2rN//X4vzj/5y8qGfyfcwA56v8NdZn+ zy9XLcz/pa//1w+38n92E/i/hamf0/yf+axu5P885CjN/7mlTFn8XzuJeKz/888COfyfvw9m 8X9+qJTB/0mbRxb/pzP6P28hovzfZBtC4P8E/u9LqJWs8H8bUR7+L53/ew2k94eab+MVqiz/ V2b9v/P9Xy/1YP1ftTuUgX/VXyd+wv+5ZdLF+T+7+/F/C4/dM/9nlrSf7f+aKrX/M6Hwf7TA Nvo/dWCMMP/XWP/XVA+B/zu+mbMc/xc+743/i8/qXP93xFLi8vyfas73f8p/XQf+7/f9X6dq gf/bFup0/2dedOP/FkPh/8YO/7fm/6j/h/+zvzX3fxr/h/9b34H4v8hQhfm/KcrD/+H/3kLh /2I+LPxffKi7+D+/vAL/t8VT4P+Cjou5/2tUifX/8H/4P7uRs/yflE02/1c1+L/AUDf2f12f 3P/Jm/k/r7Oo/4f/O9T/CV2k/zu//l+vZGr/Zw92/F/cZ4X/E0GjW/wf/s/8KP5vKSv8H/4P /5fI/1V+ZZasd4eab8OOA/F/n6Hwf4v+r6ueYyRZD7LTe0PJrjZAyXcC/4f/O9n/mSXtJ/s/ rRT+j/YDbfR/9YExwvxf6/yfegj83/HNnOX4v/B5b/xffFb4v4hhxen+T+bzf8q/ncb/fT0s Tvd/fS3wf9tCrfg/P9SOefMyfkj4P/wf/s+2A/xf3eL/YkOd7f+6zt5rEvo/M2LC/4WGwv8l fj7A/0XuwFz+T1H/L/ougv+L3oGL/s8tgU3p/2SN/4sNhf+LDIX/Cw21zf/5NbBdjP9T7bST asX/Ob4W6f+mw/ZJViXV/6v7XP7PLJxf8X9unqIs/9er1P7PPDji/4I+q7f6f7q6lf8bcvk/ 2dibk+y9DNm5tGiYdOZLuJf9n79w5fB/9rzL4f9k1VP/7yr+T5mTIa3/a5tb+b/KTTde0/+J Nf9nvtk0rf8T3Z3q/3Xe/7nZkb3+r3l19hq47P/abpLcsf7P7q2k/k+v+j936GXxfy7rHP7P H26F+b/KD5Wi/J+f4/vi/7qM/s89zufwf50bLkb5v+k2hMD/Cfzfl1ArWeH/NqI8/F9C/6e0 uXA9LxT7x4HzbYhC/V/Tn+//pJ8ISOf/ZH2y/5ODHqT1f36ubqf/k3+d+A3/54dj+L/f93+D Gdamrf+nT/d/TZW8/p/JCv9HC2yj/2sOjBHm/7Tzf81D4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy +T/zNaOn+z+ZHOVp/B/+z/32rLuZ/7MLSFL6P6nwfwmywv9dwf/1A/4vNtTp/s++3k9a/0/h //B/6zsQ/xcZqjD/J6j/F30Xwf9F70D8X6pQ+D/8H/4P/7f6Wj1n/b9f8H/uybsw/9dVqf2f Wc2O/wv6rPB/af1fteL/lD2JlOxi7vh+fbrrzCzJ6f7P7q0M/q/SvU7t/+y3mOP/wg6Ls/yf uFf9v3z+r6nwfxep/4f/W9+B+L9M/q99dbv9Xz3tVv2f8tfZKP/nrrP4P/zfRpSH/8P/LYRa yQr/9+1J5Fz/19jawr7b6f9m2zCj3BL93yh68H9J/V9lB+uy7vtO7Q0lu9p845PvBP4P/3ey /7PfnFWc/zML9fF/tMA2+r/2wBhh/q9z/k8/BP7v+GbOcvxf+Lw3/i8+K/xfxLAik/8zr4RX /J8bT2Twf9JNN1L/b8Nhcbb/682IFv+3KdQ//V/aa+CK/7Mzzyn9n2rwfwmywv/h/96zwv9F hlr0f9q+6E7p/8wXMeH/QkPh/xI/H+D/Incg9f8iQ+H/PkJdzP+17is78X9BofB/l/R/spqs 2MP/ffEUi/7Pv7tN6f/6Ff/XyleH/1s/BPP5v+dPrtX/c2dRWf5PN8n9n8L/xfm/oc/l/0Sz 5v90M4l4rP+rU/s/fwSKj9bbxSOq8jtt3x1ft5POzJIs+z/hT2G3n4vwf7LRVWr/Z17M4f9C dqDY6v+Mr0nr/57P+Dfyf5WdHbmq/9P4vwL8XzNJ7mr+T6z5v87Lb5fcof7P7bk8/s8dgTnr /2XwfzJF/b9t/s8d7Dn8n1eNWfyfm9R03d5r4HQbQuD/BP7vS6iVrPB/G1Ee/i+d/xP94Cah m25/qNk2zKNaif6vb0r0fxOUd1L9v7rvtVl+6+fyd/o/+zLPdQL/d5z/q+xjd2H+z049pvV/ 6nT/V/fK+j+/gGSv/5vOvjX4P1p4G/2fPjBGkP9rK+f/5EPg/45v5izH/4XPe+P/4rPC/0UM K+7k/9x31+D/NhwWZ/u/wTyE4P82hSrQ/1H/D/+3Ggr/h//7OCyK8392UQL+LzAU/i/x8wH+ L3IH5vJ/bYP/SxQK/5fY/7lRfUr/JzT+LzYU/i8yFP4vNNQ2/+e+4TfS//nllV/8X+PfU1/S /7V1Nv8n5Q/4P3e44f/wf5N2bf/3yur9utRMIibxf/pm/s+7Fbefy/B/WurU/s/WPDjb/7kR emn+z8wUp/V/vcT/BWb1e/7PLuVI6//qO/k/3Wb0f2qSXDn+zy1lyuL/3E0ki/9zeyuH/6v8 wZ7D//mHogz+r3b7JIf/c5eJPPX/3P0syv9NtyEE/k/g/76EWskK/7cR5eH/Evq/zk0MdRH1 /+bbEIXW/+sU/i9JVm/+r+2r2vg/FVP/T5l0fCd+w/+5cUFh/k/bqWj838Jj98/5v67C/9F+ oI3+rzswRpj/k87/1Q+B/zu+mbMc/xc+743/i88K/xcxrMjk/1Sz5v/cYZHF//VHoDz8X2So Zf+na4H/2xYK//eRFf4P/4f/W8wK/xcZKpf/U/g//N/6DsT/RYbC/0Vkhf+LDIX/C0wL/zd2 +L9f9n9imHxjP/7vi6fA/wUdF6f5v1+o/9dS/w//l8P/tW02/6fxf0f5Pz+d4Pbzof7Pzv1k 8H+qSl//z6z3wf+F7EBxmv+TVY//C8wK/5fU/5nPqjz/p4r0fxr/h/+znxH+D/+3NRT+D/+3 FmolK/zftyeRc/2fruzNyRV43Rlqto1XqLL8n67O93/uqleW/xuG5/hS1r1PZ6f/M9MsvhP4 P/xfkP/rzFC2OP+nG/wf7Qfa6P/6A2OE+T/l/F/7EPi/45s5y/F/4fPe+L/4rPB/EcOKTP5P 9j/g/1wJ+yz+b3wXhP/7Ggr/9xHqav7P/Dv+b8s7CvxffKjS/J9W+L/YUPi/z1j4P/wf/m81 FP4vIiv8X2SoW/m/zh7m+L+gUPi/a/q/cdIM/xfp/7RdERvp//zcj17zf37F7CX9X1/dyv+5 J2/838J8wsz/9fi/OP/Xq/P9X91MIibxfzX+b+HK/pv+T3WL/k+lr//3G/7P/Tv+79/+zxwW +L+wrM7yf2YYs+z/uvT+r8L/BYW6h/8Ta/6vtx9MFv83W4l+sP9zd/cs/s+lkMP/VZNvE8L/ /Xtsgf/D/62Ewv/h/1ZCzZKaPkUU4//6Sr+6naFm23iFKsv/9Q3+L0lWc/+nnqOY9nmj6ga1 O5TslBl++078hP/z8A//9+VFxeuGX5T/68/3f415akzq/2rV4P9ooW30f8OBMcL8X+38X/cQ +L/jmznL8X/h8974v/is8H8Rw4rz/Z+TQhn8n/LvWPF/P+//2srMi+P/NoU62/8p+zokqf8z 75Pwf9FZ4f+u4P+o/4f/s7+F/xP4v607EP8XGQr/F5EV/i8yFP4vMC3839jh/37b/7ljAP+3 xVPg/4KOi43+z6+8vqT/syQK/xeUFfX/8H9LR+Ct/V/rd6TtSvB/ou/7Quv/4f/wfx/+z12O 8X8LUz/4P/zf0ohpo/9zL2ez1P9zWWfxf+68y+L/XKgs/m/ybUK7/Z+f4/vi/7zwwP/h//B/ +L+FUCtZ4f++PYmc6v9kay9cvtsXar6NV6gz/Z+vvhbl/9z05ej/Bo3/S5LVzP89hxRKmhuV 1v3uULKrzHs834nf8H9uvhD/9+VFxeuGf57/02ZYW5z/G6rU/s+Ewv/RApv3f/2R1i7M/zXO /1UPgf87vpmzHP8XPu+N/4vPCv8XMay4k/+r/CvjKJTnP6Qv/s+9mcH/bVlhjv8Lu1rg/xIf 7Pi/6FD38X9+OSr+D/83adq+vsf/bdqD+L8EOxD/FxnqVP9n1940yo96dvo/Penwf/i/n/V/ DvQk9X81/i82FP4vMtSK//O4Af+31/81Cfyfnzz/6v/8o0GU//NTl7/j/6rJMvaD/Z8aGY4Q +5dANNNu1f9pdxYV5v/c8YD/WzjYt/k/d95l8X9uxXwO/1f3Xmdl8H/2FpXH/9ntFuf/7OU2 qf+T9ZL/0515JJD10EdcbofannO+u53/a/P5P/Pb+L/FUBv9n/U1+L/PqZ9b+z9zjcT/LYXC /xXr/+xAOtL//WWF/wvbgfg/1+H/toZayQr/txHl4f/S+T/lLuO+2xdqvo1XqDP9X+uGMfZD 2u3/9KT7Cf8n/URAQf5Pt2bprayVdofeLv+nWzNs9Z3A/+H/gvyfLLH+X9Nq/B/tB9ro/+SB McL8X+v8n3oI/N/xzZzl+L/weW/8X3xW+L+IYcWt/J9/QYP/+3pYnO7/+lrg/7aFOt3/2ZsT /m/LOwr8X3yoc/2fL3iA/8P/TZp2a1Xwf1v2IP4vwQ7E/0WGOtX/2Us//m9LKPzfR6jL+T+7 u/B/QaHwfxf1f272Fv+3xVPcyP+5i2Bp/q+yn2Ue/+dSKMz/uYMK/7dwsG/zf+5gj/R/7oT5 5v+cfcni/xw5yOP/7MLhLP6vcmv1svg/t0Mz+L/KHg8Z/F/bev9X9/svt4NbMOm73/B/sxVI x/o/f/3K4f/MMAb/txhqo/+zxxz+73Pq59b+z+y5XP5PTpIrx/+5wVkO/+dOhjz+z6WQxf+5 UFn8n9tbWfyfTSGH/3PDsUz+z59QUf5vsg0h8H8C//cl1EpW+L+NKA//l9D/9fap0nc7/d9s G+Yn8X8LoRL4v8reOiP933TU9RfqNP/Xqu45JJWq8y+6d/m/drAzvq4T+L/j/J8d7RTm/9Tz eVEU5/9aSf0/2i+00f+pA2OE+T/t/F/zEPi/45s5y/F/4fPe+L/4rPB/EcOKRf8n7RvNlP6v 7pvT/Z8cC8a3MTvw47Na9n9uohb/t9P/SfPGE/+3KdTp/s8ebvi/Le8o8H/xoc71f267+L8t oe7j/9oG/4f/w//h/95DLfq/trPLEVL6P1nh/xKFwv8l9n/upTH+LygU/u+i/s8tz8P/bfEU i/6vHkW7EPv9n9+DfsP1iv/zmMw+ie32f+8LfJf9XzNZ2HGs/xOde4GQ0P/JYdn/KbfIO4v/ 81mX5f9ad9PF/y0c7Jv8X209xfOn7K7Z6/+aSbfq/2qXVUr/V6/5vzq5/5Ptsv/r7OK3LP6v a03Wxfk/e8xl8H9NbwSqrHtd77/cDqpRr+43/J8boWfxf367Ofyf2S7+bzHURv9Xu0/seP+n +tT+z6yQXvZ/Vmdl8n/+sIjyf5NtuM/qZP/XmimATP7PfxNJDv9nVyVk8n9uKVMW/ycnEY/1 f36JVAb/J/xgPYv/86uw7UD6UP/nn0Ty+D9narL4P3eE2vNqt/+bbEMI/J/A/30JtZIV/m8j ysP/pfN/tdLdq9sXar4NM8o93/+55TO+MOFe/9dOul/wf8rdhSP9n4vxK/6vac2dXirln773 +T+lm79O/Ij/cxMWhfk/u2i5MP8nO/OEX5z/a80sKP6PdnYb/V99YIww/9c5/6cfAv93fDNn Of4vfN4b/xefFf4vYlhxI/+n/DtW/B/+b9bwf/g//F9UKPxfyHk1939a4f9iQ53v/yq749L5 P7OyDf8XGgr/l/j5AP8XuQOX/Z89k/B/W0Lh/z5CXc7/2Scw/F9QKPwf/u/vaRj/Z/7j0v7P Pe2V5v+qkeEIsX8JRDPt1v2fm6cozP+5teX4v4WDfaP/c09xOfyfe5eRx//5+dAc/s/8KXn8 nyUHxfk/W4ggh/+rTeE/WXddxLuKQdphvu/u5v+Ef6WZxf8p/N/G8wr/FxTq5v6vTez/7FR7 ef5P/4D/a/tJxHL8nz/Y8X8fh0U969b8n1Mkefyf+1Pi/N9kG0Lg/wT+70uolazwfxtRHv4v of9zgwrf7fR/s228QpXl//rmfP/XTaaJC/F/9WCmN5/PBt6U7fJ/TWvORt8J/N+B/s8e5YX5 P/s+rjj/1zX4P9oPtNH/NQfGCPJ/unL+Tz4E/u/4Zs5y/F/4vDf+Lz4r/F/EsOJO/q9yj1Y5 /J/PGv+H/5u1Iv2fW0CC/9vwjgL/Fx+qNP/X1fi/2FDl+T/V4P/wf+s7EP8XGepU/+cesFL6 P4H/i76L4P+id+Cy/7MbTur/JP4vNhT+LzLUsv8b3DGA/9viKZb9n1/GanfQXv/nV91+83/u x+L8n5pGzOj/6i6b/3vtwDf/98dwhNi/BKKZdmLV/7nDDf/3b/9XV/i/OP+n+mz+T6z6P/vv Kf3f5LOahUrv/8zURS7/V635P++UMvg/qd333yX0fybUp//TSjn/10T5Py1fnflJ/F/QDhRb /Z95MMf/LYba5v/soocs/q9ukvs/R6L+E29Nt31y/1d/83/uIIrzf348rc72f43Fz0n9nz3Y F/2fH2pk8H9dl9z/1Wv+z401s/g/L6dy+D9368zh/2SVr/6f9LMJdiB9rP9zn1UW/9e7e2IW /zeZN9zt/+Zzj/g//N+XUCtZ4f82ojz8X0L/V9tnD9/t9H+zbbxCleX/6vPr/42mTMWEGv3f PNRp/q8d6udAWz6ftt2HtM//1WZI5zv7BH++/3Pbxf99eVHxuuGf5v+qoSnQ/2ml8H+0H2ij /2sPjBHm/6Tzf/VD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCty+T+15v/cBGgW/+emXvB/Gw6Ls/2f Mt/9if/bFGrF/3UHhFr2f/Z9E/5vyzsK/F98qNL8nxzwf7GhyvN/ZmUb/i80FP4v8fMB/i9y By76P233Fv5vSyj830eoq/k/WyAlrf+r8H+xofB/kaHwf6GhTvN/1Zr/mzyJXa7+n1yp/zcu Gk3p/6rz/Z8Lhf9bmE+Y+T+N/zvG/zUucg7/17iRxDX9nz8CxUfL6f/G6QS3n4/0f6pO7v96 ueT/uqHX1v+piCNweJ6Or476fzsut9v8X21eYaX1f21zK//nDoQc/q+pruz/xL38X/L6f2LV /7msLur/hhX/J/1Spiz+z53iOfxfk63+n/TbzeH/VPXq8H//Hlss+j8XynV7r4HTbQiB/xP4 vy+hVrLC/21Eefi/hP5PWvRSy2F/qPk2XlLuTP/nvg8spf+bojz8XzL/12mt2+cdvm763aGe x595cPKd+I36f/i/y/i/TuP/Nvk/jf+jBbfR/+kDY4T5P+X8X/sQ+L/jmznL8X/h8974v/is 8H8Rw4pM/k/pH/B/fvY0i//zL8Lxf19DLfs/XQv837ZQK/5PHxBqpf6fPeaS+j+N/0uQFf7v Cv6v0fi/2FDl+T/q/+3JCv+X+PkA/xe5A5f9n7244v+2hML/fYTC/+H/8H/LofB/sWmd7/8m j0ex/q9+C/Xu/7pXqMv5v7X6f37O4qL+T6/6P/fB4P+++D/q/x3l/9xsNP7v29SFas73f/54 vKb/a5sl/zf0vav/59cr7vR/djf47vnsif+7jP8zpzD+Lygr/F9p/q+v8X/4P/xfwClcTbu7 +b/m1e32f820w/8J/N+XUCtZ4f82ojz8X0r/Z7/qJdL/TbfxCnWm/3PzgSn9n1T4vyRZzf3f 0Ha9NP7PP8rt9H+GbvlO4P/wf0H+T6ev/6fwf/g/mm2j/+sOjBHm/2rn/7qHwP8d38xZjv8L n/fG/8Vnhf+LGFbk8n/Vmv/zVdwL83/u2RT/t2WFOf4v7GpxA/9XU/8P/7cWCv+H//s4LIrz f9T/25MV/i/x8wH+L3IHLvs/u3oV/7clFP7vI9TV/J9bWYT/CwqF/7um/+v9e1P8H/5v0q7t /1R3vv/r3FmE//vi/6j/F+n/2jab/9Nr/k9f2P/VTTb/Z74l6XT/ZzeRw/8NjfV/uq/3X24H qdSrMz+J/wvagWKr/zPfepLW/z3vwvi/sKw2+j+dzf/p5sr+z3xWZ/u/Ibn/00X6P4H/w//Z z6iadvi/4Gsg/s91+L+toVaywv9tRHn4v3T+T/UWvag+wv/NtyF+of7fKOVst9f/tfWkE90P +D//vF2U/+vMzNrzQW6Qam8o2dhhq+/MP0v8X5Ks8H/4v1dnlp3h/2iBbfR//YExwvxfY/1f Kx8C/3d8M2c5/i983hv/F58V/i9iWJHJ/8lm1f+5x+ss/s/+O/5vw2Fxtv+rzbw4/m9TqBX/ Vx8QasX/2ZnnlP6vUfi/BFnh/67g/+SA/4sNhf/7jIX/w//h/1ZD4f8issL/RYbC/wWmhf8b O/zfL/s/Wfl19fi/vf7Pfxuz7Xb7v3barfo/j14at7Z8p/97/7AK9H91v+z/apXR/7kjG/+H /5u0A/yfkOfX/8vn/3r7riKl/zMrYxb9X2/X6MthpGf7/J+adOZgX/Z//qO7pv8zi9sW/F9n boay1l0EHhrcArrhT4Hcyv+NZ/o1/V/b4P8CszrN/2n8XwH+T0+SK8b/Vf7K75PfN7Z4/6yW /Z9fAJHF/7ntZvF/biCRw/9JP962A+li/J87obL4P/etMXH+b7oNIfB/Av/3JdRKVvi/jSgP /5fQ/9VDZ7djCMxe/zfbhvmhEv1f3+D/kmT1Xv+vfg6knw9yfjprn/+rzBjVd4L6f/i/IP/X 9gX6v7ZO7v+aHv9HC26j/xsOjBHm/1rn/+qHwP8d38xZjv8Ln/fG/8Vnhf+LGFZk8n/PA+h0 /+fhH/5vw2Fxuv/ra4H/2xbqfP9n9klS/yd7/F+CrPB/+L/3rPB/kaHwf6Gh3vcg/i/BDsT/ RYbC/0Vkhf+LDIX/C0wL/zd2+L/f9n8+Hfwf/m/S8H/b/J9U+L84/1fdyv81ztckrf/X4P8C Q93a/1Umq+P9n6z6ztX/0/3+y+0g7enmO3u5xf+F7EBxnv8zp/Cd/F/jukv6P5HP/+l8/k+q Av2fuQbeyP/562we/+fTsT92rP+r89X/q/zBHuX/XDpf/Z9fhW0H0sf6Pzd0Ls3/Uf8P/4f/ w/+thpolNX2KKMb/KTuaULWdH9rp/2bbMBMTJfq/MSv8X0r/JyvdK1v/z09+7/R/5unWd/YJ Hv+XJCv833X9n6rwf7QfaN7/DUdauzD/p63/e/64wP8d38xZjv8Ln/fG/8Vnhf+LGFZk8n91 v+b/3JGdxf/5hfVpUd6y/2vbA0LdyP815n0T/m9TqBX/dwQSWfZ/dtEC9f+2vKPA/8WHKs3/ NRr/FxsK//cZC/+H/8P/rYbC/0Vkhf+LDHUr/9fbQxv/FxQK/3dJ/yfcwY7/2zLoXPF/fhIg h/9zfwr+72f8n1it/6fdWYT/++L/7lX/79r+T5fo//wRKD7aAf6vWvV/fmDr9nMR/k/Jyvs/ vf8IHKR9UvfdX1afH1ZG/zdbgVSM/zO7jPp/i6E2+r/Kdfi/96mfG/u/tm0z+r9+0pXj/5xo yOL/3MmQw/8dsj51pf5f9epi/d9fVsv+T1Wv7lj/p93gLYf/89fZPP6ve3W7/V837fB/Av/3 JdRKVvi/jSgP/5fQ/1X2Cvp8ehx2h5pvw/xkif5PV+f7Pz+L0MSE8t+n07ezUKf5PznUzxH0 s2tqtTeUbAbzPOE78RP1/5QbSJfm/+zjQ2H+T1Y6tf+b3PBP839V8vp/5lkY/0cLbKP/kwfG CPN/nfN/+iHwf8c3c5bj/8LnvfF/8Vnh/yKGFbn832r9v4z+zz3lpUR5Gv+H/3O/Petu5v/s ApKU/q9t8H8JssL/XcH/Uf8P/2d/C/8n8H9bdyD+LzLUqf7PrUdN6f9Uh/9LFAr/h/+b70H8 X3yo2/g/P2mG/8P/TdoB/k/JAv2fXK3/534b/7cwn4D/u6j/E/n8n75Z/T8/sHX7+Vr+T1b9 ov+rzCpM4//qGP9n/9xhXMmp8X8H+b/k9f+et7tb+T/pphuv6f80/u/6/k93k+Su5v/0mv/r 3eAsi/9zp3gO/9e4DyZL/T//4s6Obo/1f37hVw7/56bnsvg/d23F/wn83zSp40Lh//B/K6Fm SU2fIkrxf57yyM6+CNkXar6Nl5Qry/916gf8X//qdvu/2f1KdWf7v757DpWkUu2w3/+1tVsA Vbtdgv/D/4X4v7ZJ7v90VaD/a/B/tPA2+j91YIwg//f879b/yYfA/x3fzFmO/wuf98b/xWeF /4sYVmTyf0qv+j+3sieH/6uSo7x1/ydTh7qX/2urWuD/toVa8X9VglDVW6hl/2d/G/+35R0F /i8+VGn+j/p/+D/7W7NFdKrB/+H/1ncg/i8yVGH+7zlkwv+lCYX/S+z/3Po5/F9QKPzfRf2f 21v4vy2eYtH/+WWBOfzfdNCJ/1vP6hf8X+fXluP/PuYTZv6vwv9dxv8VWf+v6bP5P7NcZdn/ eb52Sf+3Uv9PdrJP7f/M1eJ0/+cXleL//u3/hL6X/7NPU8X5P5nc/9X5/J/5rG7k//x4uzD/ 547QLP7PrRbN4v/c6DeP//MLtOzo9mD/57LK4f8coMzi//yXfmfxf+7f4/zfZBtC4P8E/u9L qJWs8H8bUR7+L53/E4O9bchK7a//N9+GGeXi/xZC/aT/m6C8k/yfltb/1bJp9oZ6fkRD/deJ n/B/Hv6V5v/sdkvzf7oq0P81dkl7Wv/X4/9owW30f/WBMcL8n3T+r34I/N/xzZzl+L/weW/8 X3xW+L+IYcWN/J/qk6M8/N9R/s8sSsD/bQp1vv+zC4pS+r9G4f8SZIX/u4L/o/4f/s/+1rz+ n8b/4f/WdyD+LzJUYf6P+n/4v3+Ewv/FfFj4v/hQt/F/fk0p/m+v/3PrXvF/X16r387/uXkK /N8X/0f9vwL8n/MW1/R//ggUH21whqcfYvCQ+7/93jDLVe7j//qmSe7/fqH+H/5vm/973oXx f2FZneb/xC/4v+bV7fZ/zbQrs/5fj/87yP/597n4v73+T1WvDv/377HFsv/rX91u/9dPO/yf wP99CbWSFf5vI8rD/yX0f93gbqxVhP+bbcM8d5fo//oG/5ckqzf/13W19X+VG0/v9H9G4ftO 4P/wf0H+b0ju/8xXj53s/2rd4P9oP9BG/9ccGCPM/ynn/9qHwP8d38xZjv8Ln/fG/8Vnhf+L GFbk8n/Vqv9z44kc/s+9JUuM8vB/kaEW/Z9WtcD/bQv1b/+X9Bq44v/susOU/q+u8H8JssL/ XcH/1RX+LzZUgf6vwv/h/9Z3IP4vMhT+LyIr/F9kqFv5P1fMBv8XFAr/d1H/55YU4P+2eIpl /9e/ut3+T0+7Mv1f02fzf83wA/7PHW74P/zfpB3g/55DafxfWKh5/T/1C/7PI3K3n8vwf02T vP6f2YH4v5AdKLb6P7PL0vo/c2G6j/+r3IPiRf3fT9T/a15dGv8niqz/t+r/9DBJ7mr+T6z5 P7faPYv/82gph/9Tfil/zJPINv8nBn+w29HtwfX//OSIDVWK/xN+BI3/w/9NkzouFP4P/7cS apbU9CmiHP/nl2Tpdn+o2TZEofX/xopeZfm/51Pjyf6v7urm+QmoQe8O9fyIzMDEd3YSCf+X JCv8H/7v1eH/aDva6P/aA2OE+b/a+b/uIfB/xzdzluP/wue98X/xWeH/IoYVmfyfbH7A/2n/ jaf4v6+HBf4vMKtb+z+7gAT/t+EdBf4vPlRp/q+q8X+xofB/n7Hwf/g//N9qKPxfRFb4v8hQ +L/AtPB/Y4f/w//h/8S/J6Xv4P9y1v+rz/d//jqO//vi/yr8H/X/hPt/pt35/q9vnf/TMXf8 dvB7bgx1G/+nVKPxf5fxf8nr/5k1jzfyf7Jy042X9H9SFen/iqz/p5oi/d9q/T/8X5z/G1Fe Yf7P/SnF+b/h1e32f8O0w/8J/N+XUCtZ4f82ojz8X0L/pwd7Oe5UxDVwtg38n8D/bfd/Spm3 Ic8Bml8buNP/Dc1fJ9wUyen+z63yLcz/ufkX/N/CItWp/6t1dbr/a3v8H+0H2uj/9IExwvxf Y/1fKx8C/3d8M2c5/i983hv/F58V/i9iWJHJ/5nS6sv+zx0WWfxf678fOYf/qw4IdSf/Z1bR 4f82hTrd/0m3/iGh/2sU/i9BVvi/K/g/6v/h/+xv4f8E/m/rDsT/RYYqzP+1Df4vUSj8H/5v vgfxf/GhbuP//Ppf/N8V/N8432C3tNP/+QW+fx9WJv8nhuZW/q/D/23yf9T/w/+5rdza//kr u9vPR/o/aWsiJPV/dbfo/6RWqf2fXcWE/ws7LE7yf8+j+F7+r7NdYf7PPtUn9X+yvVP9P3v7 Ter/mjLr/+H/8H/uM6qm3Zr/a11VQ/zfgqfA/9kO/7c11EpW+L+NKA//l9L/uQG67iNCzbbx knJl+b+mP9//uSFpSv8nq7P9n3T+rxmqZm8o2WozgvadGU635/s/P4VSmv+zj934v4VFqlP/ Z6rG4//CQuH/Cm2j/+sOjBHm/1rn/+qHwP8d38xZjv8Ln/fG/8Vnhf+LGFZk8n/Nav0/gf/D /+H/Aq4WN/B/1P/D/62Gwv/h/z4OC/zfRyz8H/4P/7caqjD/R/0//N8/QuH/Yj4s/F98KPzf 9oP93v6vla9ut/+bjqUnod78n0cv1P/D/xXj/6j/F+n/enm+/3OvXlL6P43/W7iy/6b/M0v2 FvxfVyX3f9T/O8r/Vea3k/o/JTX+LzCrs/yf1Vf4v7DD4mPEtOD/ZOv8n1Ieu+3zf/Wrw//h //B/+L/1HYj/cx3+b2uolazwfxtRHv4vnf+Tla5f3b5Q8228QpXl//oG/5ckqzf/1w7P0e9z 9OJH0Lv8n6766q9zz8L4vxRZ3cL/KZXc/01u+AX5P4n/o4W30f/1B8YI83/a+b/2IfB/xzdz luP/wue98X/xWeH/IoYV5/s/J4Vy+L/Gr1XB/309LM72f51544n/2xTqfP9nfjup/xMa/5cg K/zfFfxf2+H/YkPh/z5j4f/wf/i/1VD4v4is8H+RoW7l/xzowf8FhcL/XdT/+ZXR+L+9/m+Y cIC9/m8c4nnf16/5v/bV7fZ/7bTD/x3l/1r/dTn4v4+Dfeb/qP9XgP9rk/u/esX/DXYHJvV/ /Yr/G+zeUrKLueO7/9vPGZlQ9/F/0lzS8X/Locr3f/bCdCf/Z0dl+L/PqZ8b+7++6lL7P3uw l+f/xJr/a2xWefyfu1rk8H9+iVQO/1e57ebwfz5UlP+rp08zAv8XfA3E/7kO/7c11EpW+L+N KA//l9D/OVPmu53+b7aNV6gT/Z9yY/qU/q9T+L8kWc39nxyG5xhJqmFw76r3+T/VaNe58WM/ /ID/sydRcf7PPhsV5v/65P7PfPXYyf6vqark9f8U/o8W3Eb/NxwYI8z/dc7/dQ+B/zu+mbMc /xc+743/i88K/xcxrMjk/+r+fP9XV/i/q/i/3ryZwf9tClWg/5MK/5cgK/zfFfwf9f/wf/a3 ZovoVIP/w/+t70D8X2SowvzfFOXh//B/b6HwfzEfFv4vPhT+b/vBjv8T+L9vr9UL9X+6wf8F ZkX9v6T+r23u5P8c/MtU/y+1/6v1nfxf21X4v6v4P2lunWn9n7kG4v+Csvo9/2d/O6n/MzOC mfyfVCX6P43/O8j/+fe5hfm/nPX/3N7C/+H/8H/4v7fDAv+H//vM6t3/qdZtott/DZxv4xWq LP9Xa/xfkqze6v81ZrmUVEPfxvg/85hpOvcZ4//wf//I6t3/dQ3+b4v/MxOq+D9aYHP+73k8 HhgjxP9p8/9LKZV8CPzf8c2c5fi/8Hlv/F98Vvi/iGFFLv+nzvd/z9Gf/VPwfxfwf7oW+L9t oc73f3ZBUUr/V1P/D/+3Fqo0/0f9P/yf/a25/+sb/B/+b3UH4v8iQxXm/+oe/5coFP4P/zff g/i/+FD4v+0HO/5P5PF/49JI/N+/D8Gf8H/uyMb//dv/mQdH/F/QZ/Xm/yZZHez/pFrzf82F /Z+vQCk+Gv5v7Qjc5v/6XhXp/zqXdWH+zyw1S+r/nre7e/k/+/4O//c59XNn/2cHffi/pVBb /Z//gkG3n4/1fy7rLP7PbbdM/2e7SP9X/9GNZf/n7sL4vwVPgf+zHf5va6iVrPB/G1Ee/i+d /xPaj18i/N98G3YcWKD/09Xp/k+5icCU/k+0Z/u/vnL1/3rV7A31fGI3/7fp3ActNf4vSVaf /s8+aOP/FhapTv1frauz/V/d6OT1/3r8Hy24jf5PHhgjzP9J5//qh8D/Hd/MWY7/C5/3xv/F Z4X/ixhWZPJ/SuP/8H+LofB/H6Hwf/g//N9aKPwf/u/jsCjP/yn8H/5vfQfi/yJD4f8issL/ RYa6lf9z747xf0Gh8H/4v78pVfyf+Q/83+y1+tBk83+6yub/Kvwf/s/+/Fn+L1/9vzL9H/X/ jvF/taqS1/8bs/r8sPB/v+b/7IUJ/xeU1Wn+T+D/8H9uZ0w7/B/+z25ko/9T1avb+4DqX2F/ q/+H/8P/4f/wf+uhVrLC/317EjnZ/0k3frHjgr3+b7oN85P4v4VQCer/+fVFKf3f2fX/alU9 H1BlXetO7Q0ldWcmLHw3CYX/w/8tZPXu/3qd2v9Nbvj4P/zfvdvo/9SBMcL8n3L+r30I/N/x zZzl+L/weW/8X3xW+L+IYUUu/1f9gP8bv7cB//f1sDjb/w2mCDn+b1Oo8/2fXXeY0v+pBv+X ICv83xX8X13h/2JDFej/qP+H/8P/vYXC/635vynKw//h/95Cner/tP1L8X9BofB/+L+/KdVb +b8pB9jt/1wMP9JTq/7Pr26O8n/T+aNJVofX/3upxsP9X9Pk8n8m1Ir/c4cb/u/f/q9u8H9x /q+Xufyf0Gv+z/17Sv8nW/xf6A48y//V3aL/aytdZP0/7T+kDP7PI3L83+/7v8o9KOL/Pqd+ TvN/qrmX/2snyRXj//xgPYf/84+LWfyfuzTk8H/usMlT/88PlWyoQ/2fdqHy+D9narL4Pz+m j/J/k20Igf8T+L8voVaywv9tRHn4v5T+z43ZtY6p/zfdhijU/9Ua/5ckqzf/1zTPUfrzoUC5 6axd/q+r7Bs21z3/Sz/8gP9zwzH838/7v1ri//B/tKPa6P/qA2OE+b/a+b/uIfB/xzdzluP/ wue98X/xWeH/IoYVmfyfbM73f37slxLlafzfQf7PfHEg/m9TqAL9H/X/8H+roU71f+NCnYT+ r+rxf7GhyvN/pg4G/i80FP4v8fMB/i9yB+byf6rD/yUKhf/D/833IP4vPhT+b/vBjv8TSf2f 1Of7v8FuN2X9vzZf/T/Z/UD9P/zfFv8n9a38X+uOQN/t9X/tpMvp/0SJ/q/WK/5v6FL7P9nf yf81XV2Zy7ru9l9uh9pecXxn1rDh/4J2oDjN/z1vd/i/wKxO83+6SP9XZP2/50+u+D+X1UX9 n76X/ztkfSr+L2wH/qD/o/4f/g//lyTUSlb4v29PIif7PzeFonXEOHC2jZeUK8v/mS9UK8// qe50/2cG68+BktQR/q81RM53Av+H/wvyf116/6fxf/g/mm2j/2sOjBHm/xrr/2r5EPi/45s5 y/F/4fPe+L/4rPB/EcOKTP6v+QH/p9x311D/b8Nhgf8LzAr/h//b8I4C/xcf6tz6f/4VXEL/ 1w/4v9hQ5fk/pfB/+L/1HYj/iwyF/4vICv8XGQr/F5gW/m/s8H/4v7L934QD7PZ//qz0T97N mv/zCz+u6P/sEohM/u+V1dH+b73+X+POIvzfv/3fzer/pfd/UqsS6/9NPqtZqIz1/wa7t1Tl BnFx/k//UcPT/V9jT6iU/s+E+vR/5luNnf9rI+r/1Xbv+87uwNP9nz/K8X//9n+3q/9n7x74 v8+pn9P8n/ms7uT/8tX/a5L7v3rN/7lrYBb/1/qV6PbHjvV/fr1JBv8nBn+w2+vTsf5PVa/u YP/nblRZ/J+TdPg/gf+bJnVcKPwf/m8l1Cyp6VNEQf7P3lj1EDEOnG1DFFr/r1P4vyRZzf2f auvnMSfroVW7Qz0HyGb84rvnz0h9vv9z48TS/J+97+L/Fh67Z/7PfPUY/i8sFP6v0Db6v/bA GGH+r3X+r34I/N/xzZzl+L/weW/8X3xW+L+IYcWN/F+t8H8X8X/avvHE/20Khf/7yAr/h//D /y1mhf+LDJXJ/5llnPi/0FD4v8TPB/i/yB2Yy/+1Df4vUSj8H/5vvgfxf/Gh8H/bD3b8n8D/ fXutbpxSLv+nfqD+nz+x8H/4v0k7wP/1Q4n+T2fzf6v1//rW+T+/03YuLfLpuM/iF+r/5fN/ Q3L/Z+wL/i9kB4pt/q8ZuiGx/7tZ/T9pV/Ze1P+Z86pA/3d+/b+malP7P3MTKdD/iXv5v4z1 //x9MIv/q1/dbv8np93N/J9LwXV7r4HTbQiB/xP4vy+hVrLC/21Eefi/lP7PjT20HZnu9X/T bYhC6/+NFb3wf2n9n26f1wdZD3VM/b/G1f9rRjDX4f+SZIX/w/+9OvwfbUcb/Z8+MEaY/+uc /9MPgf87vpmzHP8XPu+N/4vPCv8XMazI5P/q/nz/p1r/dhr/9/WwONv/SfNmBv+3KRT+7yMr /B/+D/+3mBX+LzIU/i801PsexP8l2IH4v8hQhfk/6v/h//4RCv8X82Hh/+JD4f+2H+z39n9+ +ZS9nsf6P5/Vqv/zI8GY5ZVu5DN2Gf1fxvp/Gf1f06/5P5cC/u/f/u85qMT/hX1W1P/LU//v AP+n7uT/+m5I7f/GrD4/LPxflP97Pr3pxP7PnsJ38n/2mLum/xMZ6//pO9X/y+r//FCjNP/n Dr0c/q93Wefwf37MUpj/k368HfOA+nv+zw3e8tT/cydDlP+bbkMI/J/A/30JtZIV/m8jysP/ pfR/bpyoB7k/1Gwb+D+B/wvwf337fJgy/q9q9oZ6DpDNCNp3wn35Hf4vQVb4v33+TzX4P/wf zbbR/3UHxgjyf7Jy/k8+BP7v+GbOcvxf+Lw3/i8+K/xfxLAil/9T5/u/evx2Wvzf18PidP+n a4H/2xYK//eRFf4P/4f/W8wK/xcZKpP/M8s48X+hofB/iZ8P8H+ROxD/FxkK//cRCv+H/8P/ LYfC/8Wmhf/7yOr2/u+V1dH+T/T4vyj/R/2/WP9XZv2/Iv1fre/k/7qmS+3/Gur/HeX/zPLL tP7v+YyP/wvLCv+X1P+dX/+v1jX+D/+H/ws4hfF/+L+tofB/+L+1UCtZ4f++PYmc7P8aN+fo VnXu9H/TbZghU4n+b8wK/5fW/+m+l8b/Kd3sDfUcIJtxlu+ePyM1/i9JVvg//N+rw//RdrTR //UHxgjzf9L5v/oh8H/HN3OW4//C573xf/FZ4f8ihhWZ/N9z5H++/xtfGeP/vh4WZ/s/ZSa8 8X+bQhXo/8z7JPxfdFb4vyv4P63wf7GhzvZ/blVHSv9nFmbh/0JD4f8SPx/g/yJ3YC7/N0V5 +D/831so/F/Mh4X/iw+F/9t+sN/b//nVGFH+b3wjWr2Fevd/kyex3f7vfYFvLv/X1QXW/1v3 f+7Sj/9bmE+Y+b+qwv+FfVZz/2eWFmXyf89LdoH+r9Yr/m+wVxPZDzF4qPVTLH4tzg/4v85s N4P/k1Ulk/u//hf833QF0rH+z+1g/N+GrM72f5UdMV3V/4k1/2eHpEn9X32n+n+qzVn/T06S K8b/uaX8efyfOxly+D+/RAr/t9f/ORqfxf+5MVwW/+eBjxsA7rwGTrchBP5P4P++hFrJCv+3 EeXh/9L5P1M3/tXtCzXfxitUWf6vb873f+4PTen/ZH2y/6t68xAs6753jwf7/F9tRvq+E+7L 7872f5WbsCjM/9nzqjT/NzSp/Z+dOSvO/5lQ+D9aYBv933BgjDD/p5z/ax8C/3d8M2c5/i98 3hv/F58V/i9iWJHL/1Xn+79xBU5ClKfxf/g/99uz7l7+z56v+L8t7yjwf/GhSvN/1P/D/9nf wv8J/N/WHYj/iwyF/4vICv8XGQr/F5gW/m/s8H/4v6L9n1/tbofqu/2fvwC0b6Hwfz/u/2St 1vyf+2Dwf1/8n8b/XaX+X5n+7x/1/xq3f9P5P3W+/1N2nJ7D/w1ySO3/jBY+3f959IL/++L/ 2uZe/s/ePS7q/1br/9mskvo/caP6f/UwSPxfpP9zV6Qc/q9zA+ks/s/d3XP4Pz9OzOL/XFY5 /J/Lujj/N7kB7PZ/7zcR/J/A//0r1EpW+L+NKA//l9D/Nb1+dTv932wb5ifP93/+dVKc/3O/ 4P1fp/B/SbKa+z/Z9Wbeou5bPzu3z/8ZIuc78RP+T3XSfWRl+T97XpXm//o+uf9T5/s/3eD/ aD/QvP+TR1q7MP9XW/+n9EPg/45v5izH/4XPe+P/4rPC/0UMKzL5P9ncy/+5GPi/LSvMF/1f Xwv837ZQp/s/O42P/9vyjgL/Fx8K/4f/+zgs8H8fsfB/+D/832qowvyf6vB/iULh//B/8z2I /4sPhf/bfrDj/wT+79tr9bv5v96dRfg//N+kXdr/TbKaX5fwfxfyfzarpP7PXG4//Z96nklF 1v+brUDC/636P3MK4/+Cstrm/1qV3P8J/N8h9f+qNrn/swf7yf6vr4r0f/59bmH+L2P9P1W/ Ovzfv8cWy/5vMrbY7f/eV0jj/wT+71+hVrLC/21Eefi/hP6vtWMk3+30f7NtmFFuif6v6Uv0 fxOUd5L/G/rn+FLWva/dt8//2XqPvnv+jNT4vyRZ3cT/qQL9X9P0qf3f8yfxf7TQNvo/eWCM MP/XuPp/1UPg/45v5izH/4XPe+P/4rPC/0UMKzL5P/Oa8XT/58bYiVEe/i8y1KL/q80bT/zf plDn+z/z20n9X63xfwmywv9dwf9phf+LDYX/+4yF/8P/4f9WQxXm/wT1/6LvIvi/6B2I/0sV Cv93Uf/n08H/7fV/fhAd5f+83Pnq//x8Q5T/8/NHf9NM+L+PUCn8n19ijv/D/03atf2fzuf/ NP5v4cqewP9Je+4m9X/1sv/TbZfa/5nD4nT/15dY/0+apWZp/d/zLnwn/+dfKF3T//1C/b/R 11hMtnOJ+XQb7rPC/4UNpOtpl9H/6VX/5w69LPX/XNY5/F/lDrfC6v/l83+tK+1UnP/rX91u /9dPO/yfwP99CbWSFf5vI8rD/yX0f417QdvYL9DaW/9vug331Pgr/q/ZH+rP//mbcVOi/zNz t6f6P9W2zw9J1r3qYvyfucb4bhIK/4f/W8gK/4f/o2Vro/9TB8YI83/a+b/6IfB/xzdzluP/ wue98X/xWeH/IoYVmfyfWZRwuv/r8X/4P/xfxDUwl/9revxfgqzwf1fwf9T/w//Z38L/Cfzf 1h2I/4sMdab/6+zzPPX/toTC/32Ewv/h//B/y6FO93/jezT8317/17jHozj/59c+UP/vYv5P dPi/OP9X4f/i/J9WN/J/slKp/Z8PJd6b0vZ9iO/23vHdMnXfyTv5v+fFVhZZ/69M/2cuE2n9 X9vcyf9Je2Tj/xamfmb+z1wDV/zfZHS72/9N31WIX/B/Hf5vk/8TK/5Punkl/N+G9ann+7/J bMJu/6em3b38nz/YXbfzGjjbhhD4P4H/+xJqJSv830aUh/9L6P8qbac3pa2Ut9P/zbbxClWW /xurGuL/kvq/Z069sv5PN3tDGfhX/3WC+n/4vxD/11RVav83ueEX5P/MfCD+jxbYRv9XHxgj zP91zv+1D4H/O76Zsxz/Fz7vjf+Lzwr/FzGsyOX/qh/wf34FTg7/1/YHhLqR/2vMmxn836ZQ p/s/md7/Vfi/BFnh/67g/6j/h/+zvzVbRGe+MQH/FxoK/5f4+QD/F7kDc/m/tsH/JQqF/0vs /9wrO/xfUCj8H/7vpv7P/S/83+/4v+fo4vz6f+5ww//h/ybt0vX/pFrzf04NpfR/9Ur9v6FK 7f/W6//Z9yFycIved97xR1/j1slVa/7PO6Wi/J9shtT+z+xA/F/IDhRb/V/6+n/4v8v4Pw+T /xNv7eL+T6rT/V9dp/Z/dqod/xf3Wd3J//n7IP7vCv5Pvbrd/m+yDSHwfwL/9yXUSlb4v40o D/+Xzv89n/Dt5XhoI66Bs22YG/r5/q/3MwDp/B/1/+LfNi75v2p4PiIa/1ervaFkp7rhrxO/ 4f98lQ/838/7vzLr/z2zwv/RfqCN/q85MEaQ/1OV83/VQ+D/jm/mLMf/hc974//is8L/RQwr 7uT/7FfY4P+2HBb4v8Cs8H8p/V+r8H8JssL/XcH/Uf8P/2d/i/p/Av+3dQfi/yJDFeb/eon/ SxQK/5fW/2l3wuL/gkLh//B/+D/83+prdVVV96r/h//D/92l/l96/yfy+b8+m/9rVuv/Xdr/ 6WbR/+m2Tu3/DB7C/4XsQLHV/5lLUVr/Z05h/F9QVqf5vx7/h/9zO2Pa/YL/cx8S/m/D+lT8 X9gOxP/ZDv+H/1vKCv+3EeXh/xL6P+0Gb9oNKvaFmm1D/FXKK8v/NT3+L0lWb/5Pq+cYSdZD 4z6kff6vMY+ZvrNP8Pi/JFnh//b5P9Wc7/9aV/+vdhPXe/1fO+nwf7QdbfR/7YExwvyfdP5P PQT+7/hmznL8X/i8N/4vPiv8X8SwIpP/M4Ol0/2fG7fl8X/NAaHu5P90LfB/20Kd7//sgiL8 34Z3FPi/+FDn+r/WvTJO6P+6Gv8XGwr/9xkL/4f/w/+thirM/1H/D//3j1D4v5gPC/8XH+ou /s8fbvi/LZ7idP/n/ucl/d/d6v/5lXP4vy/+T+P/8H/C/T/TbsX/Ofh30fp/Tb/m//yLuaL8 X2d4iGyk7iL8X2NZie+sUzrd/3UeaeH/5qHe/N/zdncv/2ePucL8X2v/lJT+z5QtyeX/zGd1 sv9TMrX/s1Pti/6v7SbJFeP/3AeTx/+5q0UW/+c+mBz+z48Ts/g/f53N4P/chSuP/3OP8/g/ /N/s0zosFP4P/7cSapbU9CmiOP+n6/2hZtuw8xb4v89Q8f5PDe5pp2kiQjnJP3ayPtv/dfL5 WclmrFO2z/9pMwr3nfiR+n9uSr8w/2efBYrzf31q/yd/oP4f/o/2E230f/rAGGH+Tzn/1zwE /u/4Zs5y/F/4vDf+Lz4r/F/EsCKT/zOvQ872f7X06yPwf18PC/xfYFb4v5T+Tzf4vwRZ4f/w f+9Z4f8iQ2Xyf/ZLifF/gaHwf4mfD/B/kTswl/9THf4vUSj8X1r/1zrcgP8LCoX/w//9Tane y/+5CRv83xf/1+gC/d96/T/8H/7vNv5v5G1X9H/+CBQfLb3/M6Hu4//6Ibn/s99ijv8LOyxO 8n/mLoz/C8sK/5fU//1A/T/8H/4P/xdyCuP/8H+bQ+H/8H9roVaywv99exI52f+1drtx/m+6 DUH9P/xfgP/rm+cIWjaydu+q9/o/9dcJ/B/+D/+H/6P9Rhv9X3dgjDD/Vzv/px8C/3d8M2c5 /i983hv/F58V/i9iWJHL/6nz/Z/S9iTK4//UAaFu5P9aVQv837ZQZ/s/OST3fw3+D/+3Fqo0 /9do/F9sqPL8H/X/9mSF/0v8fID/i9yB1P+LDIX/+wh1Nf/n5hHwf0Gh8H8X9X9ueR7+b4un WPR/flmg3chu/+eVWPUW6t3/jctZ7JZ2+r+P9anl1f9T3Q/U//P/jv/7mE+Y+b8K/xfn//oh l/+Tas3/uWvgNf1fxvp/5mBf9n8+66L8n9ZDav9nPqvz/Z+73OL/vvi/QeH/ArPa5v+a2jwo pvR/BuXh/4KyOs3/2a/aW/Z/apLcsf5P5/N/Mp//8+9zc/g/d2HK4//cVSiH/5Mp/J+f4/vi /9z8aQ7/560m/k/g/2af1mGh8H/4v5VQs6SmTxHl+D93a9T22wz2+r/pNuw4EP/3Geon/d8E 5Z3k/7R6DpWM/3PPVDv9n5k88p34Cf/n4V9p/s++t8D/LTx2z/yf0NXp/q/pB5HY/zUN/o8W 2kb/1x8YI8z/Ndb/NdVD4P+Ob+Ysx/+Fz3vj/+Kzwv9FDCsy+T8zxX66/2v8WpUc/k8eEOpO /s+sosP/bQqF//vICv+H/7uM/6P+H/7P/hb+T+D/tu5A/F9kqML8H/X/8H//CIX/i/mw8H/x oW7j/zxuwP/t9n9+YarZyG7/5yZ9vvo/PxKM8n8unaL9n5Q/4P/ciYX/++L/qP93Gf8nVuv/ Xdn//UT9P5HP/1lvkdT/GZS35P/65PX/zPd938n/+RTi/J+f88nu/8wpfCP/5w6Ei/o/sVb/ zz4fJPV/UuH/gkJtrv/nssL/bfislv3fICfdXv/3vgNP93/+JpLT/9lQkf7vLyv8X9AOxP/5 Dv+3NdRKVvi/jSgP/5fS/7nHB23viXv933QbLymH/8P/LWT14f+eA0Dj/6TaG8rAv+avE/g/ /B/+D/9H+402+r/hwBhh/q91/k89BP7v+GbOcvxf+Lw3/i8+K/xfxLDiTv6v9W+nM/g/fUSo G/k/O92A/9sUCv/3kRX+D/+H/1vMCv8XGQr/FxrqfQ/i/xLsQPxfZKjC/N8U5eH/8H9vofB/ MR8W/i8+FP5v+8GO/xs3gv9bfa0utcrm/+o+l/8THf4P/2d//iz/19X4v8BQZ9X/M6FW/J+f TnD7uQz/13Uytf8bs/r8sIr0f8Itr8zh/5Q5ytP6P9Xh/wKzwv8l9X/ms8L/hQ2k62mX0f/p Nf/n0inN/x2yPvV8/+fH2zYU/g//d3Qo/B/+by3USlb4v29PIuf6v85duLqYa+BsG3bIWaD/ G0UP/i+t/+u65zBHNlK5Q2+v/1N/nf0h/F+SrPB/+/yfVPg//B/NNu//1JHWLsz/aev/6voh 8H/HN3OW4//C573xf/FZ4f8ihhW5/F/1A/7Pr8DB/+H/Zg3/F+f/uuT+T+H/8H9roUrzf22H /4sNhf/7jIX/w//h/1ZDFeb/2gb/lygU/i+x/3OHaEr/pzr8X2wo/F9kqBX/598O4v92+z83 PLPLX3f7P4/y2rdQK/7PzhRF+r/3rA73f/1QoP9br//nnxLxf1/8X4X/i/J/6rUDj/Z/UpXo /zLW/7uZ/2uS+7+b1f8b/Z+/ccT5v7+xxaL/q8wpntb/9fJW/s8qkYv6P6l+wP/5xY6227vE fLoN91ndyP/pbpJcMf6vdaIhh//z0zU5/J87QrP4Pzcxl8X/qerVHez/3GR0Hv/nFtNl8X9+ biTK/022IQT+T+D/voRayQr/txHl4f8S+j9d+fFLuz/UbBt2gRb+7zMU/m+5/l/3HJUZ/+em s/b6P/nXCer/Hef/7JmO/1tapIr/w//RFtro/+SBMcL8X+f8X/sQ+L/jmznL8X/h8974v/is TvV/fvCE//u3/1PN+f7Pj5LwfxsOi7P9X2fezBTo//xnWZj/c+sf8H/4v1mb/Rj+D/+38GP4 P/yfa/g//B/+D//3Hgr/9xEK/ycl/i82FP4vMhT+LzQU/i+h/7NLIDL5v2Y4v/4f/m+b/6P+ 32X8n6D+32H+r/U70naF+D81FOn//HrpOP/n/tzpqtuT/V/fpfZ/d6v/p1yH/3uf+sH/4f+W Rkzb/J+7TGTxf34BRFn1//xS2Tz1/9xJlMP/+X2C/8P/4f/wfwuhVrLC//37sft0/9fVr26v /5tuww458X+fofB/y/5PN67+X787lIF/1V8n8H/4v7P9X4//w//RbBv9nzowRpD/qyvn/6qH wP8d38xZjv8Ln/fG/8Vnhf+LGFZk8n9msHS6/3Njvyz+rx0OCHUn/6drgf/bFqpA/ycV/i9B Vvg//N97Vvi/yFCZ/J9Zxon/Cw2F/0v8fID/i9yBufyf6vB/iULh//B/8z2I/4sPhf/bfrDf 2//51e5x/q+ddkX6v5z1/56ji9Pr/2l3FuH/vvg/6v8V4P96/N8W/2dmSU73f01y/yeX/Z/u u9T+z+zA0/1f66tEFeX/pLkUpfV/5hS+k/+Trrui/xNizf/ZAyGp/xMa/xcUarP/8+PtHP6v Tu7/6lX/50RDFv/nT7/C/J9foGVHt/i/Hf7PPc5n8H/CP1jF+L/ZNoTA/wn835dQK1nh/zai PPxfSv/npqRdt9f/TbchCq3/V2v8X5Ks3v2feo4Djf9zw8Gd/q/t/zqB/zvQ/9kHbfzfwiLV mf+j/h/+j+ba6P/qA2OE+T/p/J96CPzf8c2c5fi/8Hlv/F98Vvi/iGFFLv+nzvd/4wqchChP 4//wf+63Z93N/J9dd4j/2/COAv8XHwr/h//7OCyK83/mi9nxf6Gh8H+Jnw/wf5E7MJf/m6I8 /B/+7y0U/i/mw8L/xYfC/20/2O/t/1r56nb7v+lYehKqJP/X1dn83yuro/3fM7kV/+ev4/i/ L/6P+n9x/s+cV7n8n8D/Rfm/f9T/czu0LP9n7EuB9f/wf/g//N8V/J9UJ/u/emhq/B/+7y7+ T1Wv7lj/p12oLP7PLWfLU/9Pvbrd9f8m2xAC/yfwf19CrWSF/9uI8vB/Kf1f5eyevdzu9X/T bQj8H/4vwP+1eugS+7/n2Xm+/6urSbd38vt9HIj/S5EV/g//R8vWRv/XHBgjzP8p5/+ah8D/ Hd/MWY7/C5/3xv/FZ3Wq//MvPvF///Z/Rsqd7v/GbzxNivLwf5GhFv1fr2pRov/zpzj+7+PR Cv83dvg//N/CX4T/u5X/o/7fnqzwf4mfD/B/kTuQ+n+RofB/H6Hwf/g//N9yqPP9n08H/3cF /+f+px177vZ/atpl9H99U2L9P4n/w//Znz/J//1E/b82uf+rs/k/fwSKj4b/WzsC3/xf3S36 Pzm0qf3fmNXnh5XT/7kPyT0NR/q/1w2/PP/XNvfyf/2rw/9Np37uXP9PJ/d/8mb+z3HrLP7P PVEV5v9k5Y6BLP6vfnW7/d/7KYz/C9qB+D/f4f+2hlrJCv+3EeXh/1L6v8HeWLtG7w8128ZL ypXl/3R1uv8bJ1SL8n+yez5MpfV/sh/wf0mywv/t839/V4sT/d+gU/s/kxX+jxbYRv/XHhgj zP/Vzv/ph8D/Hd/MWY7/C5/3xv/FZ4X/ixhWZPJ/9S/4Pzduw/9tOCxO9399LfB/20Lh/z6y wv/h/y7j/+oK/xcbqjz/Z7+UGP8XGAr/l/j5AP8XuQNz+b+2wf8lCoX/w//N9yD+Lz4U/m/7 wY7/G7uj/Z9+dfi/9UMQ/4f/s3/UHfyfOQLxf3FTF/i/j1Dx/k8b+4L/Ww61yf+Nd4xL+j9Z 9ffyf9p1l/R/Gv93Ff+nGvwf/s/+aDXt8H8l+L/m1e32f5NtCIH/E/i/L6FWssL/bUR5+L+E /q9zw5yujRgHzrbxClWW/+sU/i9JVm/+T6va1f9z4+m9/q/769yz8On+zxcUaWLmA90Ab+zw f5fxf/IH6v/h/2g/0Ub/pw+MEeb/Guv/muoh8H/HN3OW4//C573xf/FZnev//As7/N/7o9Xv +T+/AichytOr/k+nDoX/w/8thzrf/5kdnNT/mfdJ+L/orPB/V/B/fYP/iw2F//uMhf/D/+H/ VkPh/yKywv9FhrqX/7M/kNL/iRb/FxsK/xcZCv8XGmqj//Pj9Rz+z784vaT/a7ts/q9tcvm/ Z3Ir/s+vcsT/4f8mLb3/M18tjv8LC3VW/b9a/4D/s3srqf8zoRb83yCT1/9r+h/wf/7Qw//9 2/8ZhX8n/2fHs1f1f2LV/5nPKq3/q7P5P6kK9H+yX/N/3txk8H+dnb1K6v/Emv9T+fyfH6vl 8H/+oSeL/3OhyvJ/rbs+ZPF/7gjN4f+Ef7CK8X+zbQiB/xP4vy+hVrLC/21Eefi/hP5PuwmL zr6d2F3/b7INOw4s0P9J/N8h/q9vWpnY/5kv6cL/pcgK/4f/e3UmK/wfLbCN/q87MEaY/2ud /1MPgf87vpmzHP8XPu+N/4vPCv8XMazI5f+qH/B/+oiifPi/yFCL/m8wbzzxf5tC4f8+ssL/ 4f/wf4tZ4f8iQ+H/QkO970H8X4IdiP+LDIX/i8gK/xcZCv8XmBb+b+zwfz/t//zyCvzfFk+x 6P/GWTO7iHin/5svrzQLO5b93+RJbLf/+1ifWp7/e2V1tP9br/+H/8P/lVb/T5zv/4Yqtf9b rf832PNKVU3M0qLp3cG+V7qP/1NmJC0b2UUswhka+8u++8vq88PC/0X6P3OZoP7fYqgb+L/1 +n/ms7qq/xP3qv+H/7uO/8tZ/8+Fwv/9vv+j/l9gKPwf/m8t1EpW+L9/PHb/gv9ztw3X7fV/ 022YiYkS/d+YFf4vrf9TzxG2mbdo3TPVTv9nBpG+sz+E/0uS1S38X6Oa1P7PfnPWyf6v6VP7 P5MV/o8W2Eb/1x8YI8z/aef/mofA/x3fzFmO/wuf98b/xWd1rv/zr3Pxf++PVjP/Z6bYT/d/ yv57Hv/XHBDqPv6vs29m8H+bQhXo/6TC/yXICv+H/3vPCv8XGSqX/+vxf/i/9R2I/4sMhf+L yAr/FxnqVv6vtYd2Sv9XK/xfbCj8X2Qo/F9oqLP83ysU/m/XIai6bP6vW/V/LgX8H/5v0gqt /+fET0r/J9sfqP+X2v8Zani6/2vd/Pfh/k91XZn+zx0DWfyfn6a4pP+z18D7+L9qcNON1/R/ YsX/udeRaf1fRf2/oFDb/V81Sa4c/+cOvRz+r3cD6Sz1/9zhlsP/+ftgFv/nLnhZ/J/dbhb/ 5+4Y1P8T+L/Zh3VYKPwf/m8l1Cyp6SNzOf7PXWefQ8/9oWbbMD+J/1sIhf9b8n+qa58jMdk8 H7d3h5LPC2f71wn7XTin+z93hyrO/9mjHP+3sEh15v9+oP4f/o/2E230f8OBMcL8X+f8n34I /N/xzZzl+L/weW/8X3xW+L+IYUUm/yf7H/B/rX87jf/7eljg/wKzwv/h/za8o8D/xYfC/+H/ Pg6L8vwf9f/wf/i/t1D4vzX/pzr8X6JQ+D/833wP4v/iQ+H/th/sN/d/PkaU//PfElyy/3s+ OBbo/9br/7kU8H/4v0k7wP81+er/Fen/Vuv/pfd/tb6R/6vrTqb2f/ZbzM/2f40LlcH/id5d WzP4P2XGHmn93/MujP8Lywr/h//7fDU893+miOzZ/q+3l2P836bnq9P9X/vqdvu/etr9gP/T 7s0m/m/hJoL/sx3+b2uolazwfxtRHv4vpf/r7B/aqXp/qNk2zCi3RP83ZlWW/xsr5Z1X/6+u Wjtv0XRqbygD/5q/zszva/xfkqzwf/i/V2eywv/RApv3f/WR1i7I/zWV9X/PP0jg/45v5izH /4XPe+P/4rM61/8dsZS4QP+nfsD/2bfPmfxffUCoO/k/8z1D+L9Noc73f3bmGf+34R0F/i8+ VGn+r+3wf7GhyvN/ZmUb/i80FP4v8fMB/i9yB+L/IkPh/z5CXc3/uaFESv8nNf4vNhT+LzLU sv/zhxv+b4unWPR/7UR47PZ//gLwzf/55SxR/s/PH73e4OP/gg6Ljf6vndIN/N+q/6vwf1H+ T712IP7vx/3frer/PS+2yev//Yb/c1nj/774v7a5l/+zvgb/9zn1g/9L6v/0vfyf+1Oy+D+3 57L4v0PWp/67/l8O/1e/uoP9nztfs/g/d+7m8X/ucIvzf5NtCIH/E/i/L6FWssL/bUR5+L+U /s/X7rNji8j6f107C1WW//uF+n/uPXpK/yfrs/2f7J9jJOP/3NTdXv9X/3XiN/yffzIty/+1 7mt38H8Li1Rv4P+o/0cLb6P/kwfGCPN/0vk/9RD4v+ObOcvxf+Hz3vi/+KzwfxHDikz+z7zo Ptv/+VFSFv93CDW8kf+zE974v02h8H8fWeH/8H/4v8Ws8H+RoXLV/+vxf/i/9R2I/4sMhf+L yAr/FxkK/xeY1tz/mVs+/i8uFP4vMhT+LzTURv/nQ+H/3kPd2v917oPB/33xf9T/u4z/kyqf /+uK9H/9nfyfbNsi/V/ndjD+D/8383/2mMP/fU794P/y+D//OtJ1e/3f+7Pc2f7PF+XL4v+0 uxzn8H9+zJLD/1UZ6//Vr+5g/9eX6P882ovyf7NtCIH/E/i/L6FWssL/bUR5+L+U/s/d3bX1 YHv933Qbr1Bl+b9fqP9Xov+ruudnZfyf+5D2+j/51wn8H/4P/4f/o/1GG/2fOjBGmP9Tzv81 D4H/O76Zsxz/Fz7vjf+Lzwr/FzGsyFX/r/8B/zcW1sH/fT0s8H+BWd3Z/9nDO6n/Exr/lyAr /N8V/F9d4f9iQ5Xn/6j/tycr/F/i5wP8X+QOxP9FhsL/fYTC/+H/8H/Loc73f+5xCv+3xVMs +z8/gjHdXv/nJ89V9Rbq3f/5kWDM8koppx3+D//nNvKxmh3/F3QKn+X/ZFcv+7/afUgp6/+p ZsX/VX41Rjr/V3cF+j9T7PJG/q+SRfo/94fi/95Dvfk/WfV38n/S/qFX9X86n//T+fyf+azK 838V/u8g/+fgH/5vw7rvFf+nX91u/6em3ar/0zYF/N/C48FkG0Lg/wT+70uolazwfxtRHv4v pf9z36+ihxj/N93GS8qV5f+o/xf/tnHR/5n1sMb/uceDnf7PvPrznfgR/+cmLMryf7rF/23y fz3+D/9Hs230f/WBMcL8X+38n34I/N/xzZzl+L/weW/8X3xW+L+IYcWd/J+nG/i/C/g/U+Ud /7cp1Pn+z61/wP/h/2Zt9mP4vzX/R/0//J/9rY9FdPi/0FD4v8TPB/i/yB2Yy/+1Df4vUSj8 X2L/59Yp4v+CQuH/8H9/U6r4P/Mf+D/8H/5vYT4B/5fS//VDNv8n1ur/4f82+T8T6jb+T/Xd gP+7iv+T5lKU1v9phf8LzAr/h//7fDU89392qh3/F/dZ4f9E0OgW/4f/Mz+K/1vKCv+H/8P/ pfJ/bkiq7fTF7vp/k22YnyzR/+kK/5ckq7n/U92g7LyFe/W32/81f534Df/nXtDi/768qHjd 8M/zf7JP7f9qXeH/AkPh/wpto/9rDowR5v8a6/+a6iHwf8c3c5bj/8LnvfF/8Vnh/yKGFbn8 nzrf/6lx3JbD/x0R6kb+T5k3nvi/TaHO9392AUlK/yd7/F+CrPB/V/B/fYP/iw1VoP/r8X/4 v/UdiP+LDIX/i8gK/xcZCv8XmBb+b+zwf7/t//zKaPzfXv/X+FBmI/i/1dfq5otjbuX/XAr4 vy/+r2nwf2Gf1Zv/M8ymPP83+axmoQ7wf32++n/6B/yfncdL6v/Mkr0F/zfoGv93Gf9nbp1p /Z+ByTfyf/bqe1H/J9Wa/7PmLKn/G1b9X/3qdvu/etqd7v/qQbUl+r/BHg/4v6UdWE87/B/+ z20F/3dEKPwf/m8t1EpW+L9/P3af7//c3IiMuAbOtvGScmX5v7Gq4Zn+z91kUvo/oc/2f/3Q aOv//OzcTv8n/zqB/8P/nez/zFMj/i8sFP6v0Db6v/bAGGH+r3X+Tz0E/u/4Zs5y/F/4vDf+ Lz4r/F/EsCKT/zMPjPi/yFD4v5BQ+L9Xh//D/y2Fwv/9gP+j/h/+z/4W9f8E/m/rDsT/RYYq zP+pDv+XKBT+D/8334P4v/hQ+L/tBzv+b9wI/m/1tfrd6v/1fm05/u9jPmHq/56DSvxf2Ge1 0f/52eiU/k+v+T99Zf93s/p/ufxf3egO/3cV/1dVOrX/u1n9v0v7vx7/dxX/ZxA5/i/ys8L/ iaDRLf4P/2d+FP+3lBX+D/+H/0vl/2o3cGkjroGzbYhC6/81Pf4vSVZz/1c38jnQNv6vVXtD yU6bySPfCfwf/u9k/0f9P/wfzbfR/+kDY4T5P+38X/MQ+L/jmznL8X/h8974v/is8H8Rw4o7 +T/35JDF/7XdAaFu5P9q82YG/7cp1On+zy6wTer/zPsk/F90Vvg//N97Vvi/yFD4v9BQ73sQ /5dgB+L/IkPh/yKywv9FhrqV/2vsoY3/CwqF/7uo//Pp4P92+7/JNWm3/9PTDv93Hf/Xrfo/ N0+B//u3/6P+H/4P/1ei/3uesm2R/s89H+D/3kO9+7+qv5f/s/fdHP7PnndJ/d/zYC7R/0l1 L/9X+c/SfnQX83961f+58UsO/+eoYR7/566ROfyfvwpl8X+TbxM62P+5wVse/+dMTQb/J4bh 1e29Bk63IQT+T+D/voRayQr/txHl4f/S+T/p7vS+2xdqvo1XqLL8X9/g/5JkNfd/la66zsxb KD9U2uf/WvnXCfzfcf7PFljE/y08dt+g/p8Jhf+jBbbR/3UHxgjzf53zf/oh8H/HN3OW4//C 573xf/FZ4f8ihhU38n+1wv9dxv/pWuD/toU62/8pO5uP/9vyjgL/Fx8K/4f/+zgs8H8fsfB/ +D/832oo/F9EVvi/yFD4v8C08H9jh//D/+H/xL8npfF/+L8tRyD+T4ScV/g//N9SqLP8n6Eb d/F/z4O7ra3/08P+y+3Q2L3vO/zfjsst/g//t3AK4//wf1ue5fB/gTuwnnb4P/yf2wr+74hQ +D/831qolazwf/9+7D7b/w32qdJ3O/3fbBuvUGX5v0Hj/5JkNfN/onuOarvnjarvXTr7/F9t Vl75TuD/8H8h/q8emuT+rz/d/zWqwv/RfqCN/q8/MEaQ/2sr5//kQ+D/jm/mLMf/hc974//i s8L/RQwrbuT/jkF5K/6vPSAU/i8kFP7v1R3r/+wOxv9teUeB/4sPda7/84vs8H/4v0nTbtFS Qv9nFyXg/wJD4f8SPx/g/yJ34KL/0/YyhP/bEgr/9xHqav7PrQrE/wWFwv/h//6ehm/l/7zw ivN/fg/+jv/zeeTwf3I6dXGo/1PDyHCE2L8Eopl0Uq75P12k/3PPO/i/hYN9k/9r3CK9LP7P 5ZHD/9XjGpMM/s+mkNT/9Wv+z8ZQld9pO/1fO+l+of5fZT+kpP7PLNn79H+60sp+j37b7L/c Du4oHsaD+Sf8n1+v6PbBof7PUcMM/q8ZzPpU/N9iqG3+r3LTjTn8nzmy8/i/1p7iSf1f0674 P+9rovzfdBviJ/yf2W4m/6enF6ZD/V9vD4Sk/q9e839uHUQW/9f5228G/+dPohz+r8rn//wd I4P/a+2XM2Txf8J9F04W/9cn8H89/s92+L+toVaywv9tRHn4v3T+T7X21um7faHm23iFOtP/ +ddJVUSoOWr5Bf+nrL6K9X9uk7/i/9pe6fZ5o2qk3h1Kavv60HfiJ/yfe6Yvzv/Zh57S/F/d 2/FsYf6vMw/B+D/a2W30f8OBMcL8n3T+r34I/N/xzZzl+L/weW/8X3xW+L+IYcWN/F89LqzH /309LM72f415HsL/bQp1uv+zz7/4vy3vKPB/8aHwf/i/j8MC//cRC/+H/8P/rYbC/0Vkhf+L DIX/C0wL/zd2+D/8H/5P/HtSGv+H/9tyBOL/RMh5hf/D/y2Fwv9l8H/PcbTzf1XEu4qhqeSr w//tuNzi//B/C6fw3P8p/B/+z/7o+7Mc/i9wB9bTDv+H/3Mbwf8dEQr/h/9bC7WSFf7v34/d Z/u/wW7Cdzv932wbr1D4P/zfQlZz/9f0/XNs8Ry9dO4P2+f/qqH/6wT+D/8X4v9Upwr0f61s 8H+0H2je/zVHWrsw/6es/6ubh8D/Hd/MWY7/C5/3xv/FZ4X/ixhWLPq/ys2WJfR/tWpO939K H4Hylv1fXR0QCv8XEgr/9+qO9X/2fRL+b8s7CvxffKhz/Z9724f/2xLqPv6vbd0aUfzfhj2I /0uwA/F/kaFO9X92uj+p/5M1/i9RKPxfWv/XuIUz+L+gUPg//N/f0/C9/J+bsHGLiPf6PzXt fsD/SS/lEvq/plr2f/4imdL/PUcXy/6vGVdQC7F/CUQz6db9X+s+mML8n2M4+L+Fg32b/3Ov xlL6P9kv+7+6GXnbK8dw/6dm3Zr/8wu/Mvi/rjfnVRb/19kl5nLwq0V3+r8JW/gN/2ePrAz+ r2lbrc1lXdb7j8Chth+0737E//n1im4fHOr//PAoh/8zp3BS//c85u/l/+wuy+H/VG+f3rL4 P3sSZfJ//rBwB9FO/zfZhvgF/2cH0pn8nxtyZvF/9hqYyf+5Qy+H/9PucpzF/7lLQxb/5/ZW Dv9X+fF2Bv/nWGgW/+cOiyz+r3OPcn2M/5tuQwj8n8D/fQm1khX+byPKw/+l83+1smdSrax9 2Rdqvg1zTT7f/7kzqTT/13hT1kSE6t1B/TP+T7VD/fwEam/Kdvm/tjGDBt+JH/F/7vGhNP9n H7QL839VW6L/a5QU+D/a6W30f/LAGGH+r3b+Tz8E/u/4Zs5y/F/4vDf+Lz4r/F/EsOJ0/+cG vlnq/6nk/k/j/w7yf2ZRAv5vU6jT/Z9d1YH/2/KOAv8XH6o0/1fV+L/YUAX6vwr/h/9b34H4 v8hQp/o/O4ua1P9NUR7+D//3FurU+n9ud+H/gkLh/67p//zyCvzfFk+B/ws6Luav1Xudzf+9 spovbav/VlDbzyeB/zNzqvi/sKxm/k9q/F+U/xOvHXi4/xMl+j8vUMVHS+//zCzJ2f5P2gVT af1fteT/njeNRj8veoPWEfX/anuj8t1fVp8fVpn+b8jn/wyJSuv/VIf/C8xqY/2/Jrn/cyTq P/HWdGufgpP6PzMjuOj//GET5f+m23CfFf4vbiCdyf9Jhf/D/9nPaJP/07JI/9cn8H89/s92 +L+toVaywv9tRHn4v6T+zy7QUm5Qsdf/TbbxknJn+j83xxTn/5y2G/2fVOf7v9GUNRGh3vxf dbL/09KM2Z83877fHUq20tZod539Sfxfkqw+/J99lCvM/0k9JPd/6gf8X4//o/1AG/2fOjBG mP9rrP9rqofA/x3fzFmO/wuf98b/xWeF/4sYVmTyf0qv+j/3eixH/b/Wz/YnRXnL/k91B4S6 kf9rzfsm/N+mUKf7P/t2B/+35R0F/i8+VGn+r67wf7GhyvN/qsH/4f/WdyD+LzLUqf7PrtDH /20Jhf/7CHU1/+evsPg//N9qKPwf/s+3cXgW5f88yrul/xtcCpf0f2bZ8rL/a/zjMv7vYz5h 6v+Uwv/F+b+uXfZ/TZXN/zWNnw+9ov97Ptbk8n9mlmTZ/3mnlMH/KXvYZPB/Q9NV1v81zf4j cFD2RuS7H6n/5z4k/N8X/2dO4Rv5P3cg5PB/TZXN/2n71bCZ/F/z6nb7v2balVn/r1rzf37F eWH+r/EvGCY30sP8n19bmsP/uRSy+D93HyzN/7l9ksP/tYPLPYf/cwOCOP832YYQ+D+B//sS aiUr/N9GlIf/S+f/VG+vrarX+/3ffBtmYPQr/k/ZDynS/7nO1Oz+Ff/nnn0i/Z+ahTrN/w2y f45+n3f43h16u/xfM5i7sO/Ej9T/sydRcf7P7ODS/J9delNe/b/k/s9MqOL/aIFt9H/1gTHC /J92/q9+CPzf8c2c5fi/8Hlv/F98Vvi/iGFFLv9Xrfk/NweYpf5f41/Q5PB/yUsN3sv/afNm Bv+3KdTZ/q+25yv+b8s7CvxffKjS/F/V4/9iQ53t/7o6tf+j/t+erPB/iZ8P8H+ROxD/FxkK //cR6mr+z90V8X9BofB/+L+/p2H8n/kP/N/stXo7LPs/9xng/7YcgWf7P92n9n/mwRH/F/RZ bfV/Gv+3yf+pZf/3PLqT1//TP+D/7Gr2pP5PdYv+r+qd/6ti6v+5VWu++8vq48PK6f88OcD/ ffF/vcT/BWa10f/pfP7PTlNc1f+J0+v/dUNy/2cqOeD/Ij+rZf/n4F8W/3fI+tTT/Z9/lMP/ 7fZ/1P/D/+H/koRayQr/9+/H7rPr/1WuQL3rdtb/m22jVP/X/U79v5L8X983Q/28w/d9p/aG ej6qm0GD7yah8H/4v4WsPvyfTO7/iqz/Z54a8X+0wDb6v+bAGGH+r3P+r30I/N/xzZzl+L/w eW/8X3xW+L+IYUUm/yebNf/nHr2y1P8b/Ctj/N/XwwL/F5jVnf2fXXeU1P+pBv+XICv8H/7v PSv8X2SoTP7PfL0U/i80FP4v8fMB/i9yBy76v85eYfF/W0Lh/z5CXc3/uZfG+L+gUPi/a/o/ f7jh/7Z4imX/p1/dbv+npt0v+D93XOD/FpZANJPuH/7PXVzxf//2f2Zdwq38n3sMzuL/3DU9 i/9TLtQV/V/drNT/65P7P3OwL/s/f+XP4f/8998l9H9ts+T/uq5Rxv/1TZT/q+Wr+436f9qv r3f74Ej/N94xjvd/bWVOcer/LYbC/6X0fxr/F1f/T6/6P3cyXNL/mcNixf/5Sg+TG+lh/s9d LXL4P//1IPi/vf7PTV7l8X9ub+Xwf+MRaLq918DpNoTA/wn835dQK1nh/zaiPPxfOv+nhtZe Gqpqf6j5NuzY4nT/5z6dwur/1W4HF+X/uqatTf0/3bl31fv8Xzt0f534jfp/vf3fxfk/m0dh /s8uSy3P/7XmnEjp/8yVHf9HC2yj/2sPjBHk/3Tl/F/1EPi/45s5y/F/4fPe+L/4rPB/EcOK TP5P9Of7v7p2j1YJUZ5e9X9N6lA383+6Fvi/baHO939u/UNC/9fj//B/a6FK8391i/+LDXW2 /9Ndcv+n8H/4v/UdiP+LDHWq/7ODlqT+T3X4v0Sh8H/4v/kexP/Fh7qJ/5OVXxmN/9vt/yaP R7v938ei0WX/Nwm12/+thCrJ/0l5vv/T7oPB/33xfz3+L87/tc2K/3PXh5T+T+P/ovzfev2/ jP7PHgNJ/Z8J9en/+rZqrP+rhv1H4KAq/eqetyX83yH+r7ErZtP6v+cz/p38n72a4P8Wpn62 1v/rX91u/9dPux/wf1XO+n9l+j93Rcrh/zp3Zc/i/9y1NYP/G0tl5PB/cvJtQrv9n7vO4v/w fxtRHv4P/7cQaiUr/N+/H7vP9n/2y/SfnR0q7fR/s22YUe4P+L/m1e32f92k+1ON+L+k/q+v daXNUMYfevv8X913f90kFP4P/7eQ1Zv/q4Yuuf/rS/R/DfX/aOFt9H/6wBhh/k86/6ceAv93 fDNnOf4vfN4b/xefFf4vYliRy//5UAv+zz1e56j/1/sXNPi/r4fF2f6vM89D+L9NoU73f/ZF X1L/N2j8X4Ks8H/4v/es8H+RoXL5P+r/4f/wf2+h8H9r/q9t8H+JQuH/8H/zPYj/iw91E/8n vOTB/23xFPi/oOPiNP+nulz+z5KoZf/n5inwf//2f7XG/8X5v15m83+iSP+n+mz1//o1/+ez vqb/W67/Nzyf9Yz/6/qI1yKDHOpX9xv1//6+9c/tzyL8X1uZ1YH4v8VQG/2f3WX4v8+pH/xf Jv/nBwT2LyrG/7Xu5WyW+n9y0h3r/w5Zn7pS/8+lkKX+X/3qYv3f3+V22f+5osJ5/J97nM/i /9Sr2+3/1LTD/wn835dQK1nh/zaiPPxfQv8n7btZJfX+UPNtmOEg/m8hFP5vyf8NSitT/69p qt2hZGP3jO8E9f+O83/u/Wxh/q8vsv6fXW+W1v/1+D9acBv9X3dgjDD/p5z/ax4C/3d8M2c5 /i983hv/F58V/i9iWLHo/2Sb2v+ZRQnL/s8NabL4v9b/KUlRHv4vMhT+7yPUxfyfW3dI/b8N 7yjwf/GhSvN/VY//iw1Vnv8zIyb8X2go/F/i5wP8X+QOpP5fZCj830co/B/+D/+3HOp8/+cn zfB/e/2fnzWz9/q9/m98re53ZL/i//wCX9vt9n/ttMP/HVX/z633wf8tzCdM/Z9Zl4D/C/qs zvN/q/X/3LuKHP5vsKdwrWXMG5jJL/8dgeKjDdYxKa1jlhb55x239ko1Rfo/c7n98H+yGlz9 v67rYvyfvRH57i+rzw8ro//r3IdUlv+zt9+0/s+cwvi/oKy2+b9W4f+u4f+ayo6gk/o/e7Av +r9ZYdK9/s/FyO//xKr/87dO9xcd6v/cUCmL//Njlhz+b1yglaP+nx9v2+O1HP/nPiT8H/5v mtRxofB/+L+VULOkpo/M5fg/e4dSbvHIXv833Yb5yRL9X9/g/5JkNfN/z/tT87yRS1n7L37a 5/+U+YR9J+yqqfP9n5uwwP/9vv/rhtT+73mmnu3/mqHD/9F+oI3+rz8wRpj/q53/0w+B/zu+ mbMc/xc+743/i88K/xcxrLiT//PrD/F/F/B/5kuJ8X+bQp3v/+wCkpT+r1P4vwRZ4f+u4P+0 wv/FhirP/1H/b09W+L/Ezwf4v8gdSP2/yFD4v49Q+D/8H/5vOdTp/q/3703xf/i/ScP/4f+W /J9K7f+o/4f/W1qIqPP5v37F//W21KDS/rTd6f/8h+SWq6hV/+enE9x9oAz/p3Tv/F/Eu4pB 2mG+7563JfzfZfzfzer/2U1c1f/pIv2fVKf7v1bi//B/+L+AUxj/h//bGgr/h/9bC7WSFf7v H4/dv+D/7N1DyW7/NXC+jVeosvwf9f/i3zYu+b9nHtIwpd6ls9P/qf6vm4TC/+H/FrI63v+Z Wc7y/J95e4D/owW20f8NB8YI83+N9X9t9RD4v+ObOcvxf+Hz3vi/+KzwfxHDilz+r1rzf26f ZPF/vX9Bg//7elic7f9688YT/7cp1Pn+z848U/9vwzsK/F98qNL8X93i/2JD4f8+Y+H/8H/4 v9VQ+L+IrPB/kaFu5f9au2H8X1Ao/N9F/Z9nTPi/3f7P/Tv+78tr9V5n83+vrM7zf36JOf7v 3/6P+n8X8n9Nc7r/s1Pteer/ZfV//sru7gNF+L9noOT+b8zq88PK6P88mSrL/ylzZU/r/3SL /wvM6iz/J9UP+D+3Vs91e5eYT7fhPqvy/J9e9X/9JLlI//f3Fvp0/9c50ZDD/3lAmcP/eSmX xf+1r+5o/+fGLDn8n/v3LP6vGVzuOfyfSyfO/022IQT+T+D/voRayQr/txHl4f/S+T/Z2cml 5xBj//dAzLdhv6Ad//cZCv+35P+eH87z0/HdzlDPcZ0Z0vlOuCmSs/2fm7Qtzf/ZmbXC/J9U MrX/m9zwT/N/fUv9P9oPNO//2iOtXZj/a139P/kQ+L/jmznL8X/h8974v/is8H8Rw4pM/s98 zeiy/3NHdg7/V7sZYvzfhsMC/xeY1a39XyUS+79B4/8SZIX/w/+9Z4X/iwyVy/8p/B/+b30H 4v8iQxXm/1SH/0sUCv+H/5vvQfxffCj83/aD/eb+z/0pWfyf+5/X9H9NXaD/s05p2f+5FPB/ //Z/1P/D/53r//wRKD5a74oI6MrfIvf5v8b/2WOoAv1f2yz6v0ZWqf1f8wv1//rZR4r/w/+Z f7y0/xO/UP/PPXe7brf/k9OuyPp/xmri/yI/K/yf2PWA+pfV2f6vq8r0f+rVUf9vI8rD/+H/ FkKtZIX/+8dj9/n+73ndspfjIaL+33wbZpRbov9r+hL93yjlzvN/dfUcpUvVtm7iZ5//02ZM 7DsjujT+L0lW9/B/fZfc/+nqdP9XJa//h/+j7Wij/5MHxgjzf9r5v/oh8H/HN3OW4//C573x f/FZ4f8ihhW5/J9a9X9upUCO+n9+/SH+7/f932DezOD/NoU62/+pwR5z+L8N7yjwf/GhSvN/ VY//iw2F//uMhf/D/+H/VkPh/yKywv9FhsL/BaaF/xs7/N9v+z+/Yg//t9f/+aJ8diO7/V81 7cSw4v/8CsRr+r+uKtD/ydX6f/72hP/7t/+j/l+s/2ubbP6v71f8n0ru/+qb+T/3Y0X5v3bQ Zfo/Of1I8X8r/k9qdSv/V9ldhv/7nPo5zf+JEuv/mS8nXvZ/3ZX9n17zf9q9nM3h//yTShb/ 566tOfxf5Y7sLP7PX2ft8VqK//PzZPg/gf+bJnVcKPwf/m8l1Cyp6SNzMf5Pu5uM1hGhZtt4 Sbmy/N9Y1RD/l9b/tfVzcCZV5w+9ff6v77u/TthVU/i/FFndwv8pI1CL8391J/F/tB9oo/9T B8YI83+d83/tQ+D/jm/mLMf/hc974//is8L/RQwrzvd/7vVYjvp/lX87ncH/+XfB+L+9/k/X Av+3LdTp/q+3C4pS+r++wf8lyAr/dwH/Z75uHv8XGapA/9fj//B/6zsQ/xcZCv8XkRX+LzIU /i8wLfzf2OH/8H/4P/FleWU17V6h3uv/ta8O//fPQ/D8+n/u4or/+7f/o/5frP/LWP8vo/8T 2fyfmbrA/32Eivd/fUX9vxv7P3thwv8FZYX/S+r/yqz/h//D/7mNVNMO/3eU/3NZ4/8E/m+a 1HGh8H/4v5VQs6Smj8zl+D+7nDPS/023YceBBfq/vinR/01Q3kn+rzNZPUcvfuZsl//Tla7+ OkH9P/xfkP+TJdb/w//RfqON/q8+MEaQ/3v+d+v/qofA/x3fzFmO/wuf98b/xWeF/4sYVmTy f2awtOL/3ON1jvp/rXuRhP/D/80a/i/S/9l1h/i/De8o8H/xoQrzf7Ju8X+xoQr0f9T/w//h /95C4f/wfws/hv/D/y2lhf/D/y382LH+zz1O4f+2eAr8X9BxMX+tPnQF+j+5Wv/PwR/838J8 Av7vov5PFen/1Jr/szZe1W3M0iLtzs3uL9TZ/k92duV1Sv8nq2X/1yj83339n6l5gP8Lywr/ h//7fDU893/mszrd/9lLQ1L/V+P/ru//3L/j/7aMLfB/+L+VUPg//N9KqFlS00fmYvxf5+Y1 XLcz1Gwbr1Bl+b9R9OD/Evs/87TzvFG17plqn/9rzPjFd/aH8H9JsrqH/2uHEv1fW+P/aD/Q Rv/XHBgjzP9J5//UQ+D/jm/mLMf/hc974//is8L/RQwrMvm/etX/ubVRWfyfe2DE/204LE72 f31lnofwf5tCne//7AKSlP6vU/i/BFnh/y7g/6j/h/9b8n/U/8P/4f/eQuH/8H8LP4b/+2n/ 59bP4f+CQuH/8H9/U6r4P/MfB/i//tXt9n9T+zIJdbj/a+ps/k91P+D/3ImF/8P/TRr+787+ 7xfq/8nB5pHS/5nL7YL/G5omtf8zOxD/F7IDxUb/Jw2zSev/6hb/F5gV/i+p/zOf1bn+r63S +z+B/8P/2R+tph3+D//3sQ0h8H8C//cl1EpW+L+NKA//l9D/aTdU0vYLtPbW/5tuw4xyS/R/ TY//S5LVm//rh2YwT69Sqr2hpO774a9zz8L4vxRZ3cL/uenutP7vdcM/y/+1ekjt/1SD/6MF t9H/tQfGCPN/yvm/5iHwf8c3c5bj/8LnvfF/8Vnh/yKGFTfyf3XlXxnj/74eFvi/wKxu7f/M v+P/tryjwP/FhyrM/1H/D/+35P+o/4f/w/+9hSrE/+ne/KFJ/Z+s8H+JQuH/8H/zPYj/iw91 G//nV0bj//B/k3aA/+uqW/k/7T4Y/N8X/1fh/y7j/15ZvV2X0vs//QP+z65yem7dL2rf5//8 xW+88NzH/5kpdur/Xcb/GbCS1P/ZC9Od/J9diJjD/zW1eVBM6v9UU6L/O7/+X1t1+L9I/+cG Z1n8nz/9Mvg/f7hl8X9+gVYO/+e/Tcger/g//N/RofB/+L+1UCtZ4f/+8dj9A/6vc3eorq73 h5ptw04m4P8+Q+H/lvxfXVfP8ezzmVu5D2mf/xvM46Dp3OhV6h/wf+4rlPB/t/R/59f/w//R fqON/k8fGCPM/9XO/+mHwP8d38xZjv8Ln/fG/8Vnhf+LGFbk8n/Vqv9zx1wO/9f4FzT4v6+H xen+z3xTMP5vUyj830dW+D/8H/5vMSv8X2Qo6v+Fhnrfg/i/BDsQ/xcZqjD/R/0//N8/QuH/ Yj4s/F98KPzf9oMd/zduBP+3/lq9yPp/1ikt+z83T4H/+7f/8/oK/3cF/6fxf1H+z4Qq0P+1 zaL/681SM1kPtY7wf27Vmu/wfzsut6f5v+ddGP8XltVp/q/M+n9F+j/zlRMF+j+B/8P/2c9o k//TbmoN/7dwE8H/2Q7/tzXUSlb4v40oD/+X0v+5KRLX7fV/0228QuH/8H8LWb35v66rzI1q qPrdoWRXmwl0301C4f9S+z87DizN/7Ut/m+L/zML9fF/tMA2+r/uwBhh/q+x/q+tHgL/d3wz Zzn+L3zeG/8XnxX+L2JYkcn/ma8VON3/uclo/N+Gw+Js/yfNG0/836ZQp/u/zq1/SOj/+gb/ lyAr/N8V/F/V4/9iQ+H/PmPh//B/+L/VUIX5P0H9v+i7CP4vegfi/1KFwv/h//6mVG/l/+oR rAix2/95kPLV/00uf7v9XzuNmNH/Zaz/J+X59f/8sy/+D/83afi/y/k/2cXc8Uf/V42hCvR/ K/X/tFno87ysNxErzoba6kvf/Yb/c5azNP9njgf832Kojf7PHnP4v8+pH/xf0vp/+gf8X2c3 kcX/uSfUPP7Py6kM/s+lk8X/+e3m8H9udIv/2zK2wP/h/1ZC4f/wfyuhZklNH5mL8X/aDWXd BX5nqNk2XqHwf6n9n/vtsvxfq9vaDJSkn53b5f9aM1PqO/ET9f9q92iP//v2ouIH/F9Xp/Z/ 5kVFef6P+n+0HW30f/2BMcL8X+v8n3oI/N/xzZzl+L/weW/8X3xW+L+IYUUm/yf7Vf/npFAO /1e72VP8H/5v1vB/+D/8X1Qo/F/IeYX/++vwf2v+T+H/8H/rOxD/FxnqTP/X2Ud86v9tCYX/ +wiF/8P/4f+WQ+H/YtM63f/571e13e76f920k6rE+n8Z/V/d/4D/m9IN/N+a/6s1/i/O/+m2 RP/XNOf7P/tZys7v7p1Li6bIodY38n9q6FVq/zdm9flh4f8i/V/y+n9mzSP+Lywr/F9h/q/R bWr/Z79qD/8X91nh/0TYA+r7um/8X2Ao/N8RofB/+L+1UCtZ4f/+8dj9C/7PPVVqt6pzp/+b bsOOAwv0f32D/0uS1dz/qUG77y2qqt2hZGdfh/rOXHMU/i9JVrfwf02V3P815/u/uq1T+z/z LIz/owW20f8NB8YI83/a+b/mIfB/xzdzluP/wue98X/xWeH/IoYVufyf+gH/1/gXNPi/r4fF 2f5PmTcz+L9NoU73f/Z9U1L/12n8X4Ks8H/4v/es8H+RofB/oaHe9yD+L8EOxP9FhirM/0mJ /0sUCv+X2P9p+5fi/4JC4f/wf39Tqvg/8x+7/Z9qSvR/Q5fN/72yOtH/uQ8G//fF/1X4vzj/ Nyj8X2Cos/zfver/1Vqn9n8GUJ7u//x6afzfv/3f8yfxf4FZ4f/wf5+vht/8n7qX/+vcUqYc /s/N/OTxf+7SkMX/uYFEDv/n/j2L/3PPVzn8n3BPO3n8X/3qdvu/etrh/wT+70uolazwfxtR Hv4vpf9zY/bn0HN/qNk2xF+lvLL8X6dK9H9mMuHc+n91VXXPbhjcM9U+/9eYQaTvBPX/8H/4 P/wf7Tea93/6SGsX5v866/+a9iHwf8c3c5bj/8LnvfF/8Vnh/yKGFZn8n3kdcrr/k+5FEv4P /zdr+L9f8399j/9LkBX+7wr+r27xf7GhCvR/Pf4P/7e+A/F/kaHwfxFZ4f8iQ+H/AtPC/40d /g//h/8TX5ZXzvwf9f9K8H9ungL/98X/Uf8P/+e2cpL/80eg+Gj4v7UjcJv/ez42pvZ/dhXT jfyfn6a4pv97HhY38n+V9Rb4v4Wpnxv7PzlkrP/n+Vph/k+7u0eW+n/+m0qi/J9624HL/s+N four/+fH2/Z4Pdb/ufM1i//r8/k/P4KO8n/TbQiB/xP4vy+hVrLC/21Eefi/lP6v8uOXdn+o 2TbwfwL/F+D/tH6O0o3/k2pvKNk1ZtDgO/ET/k8NZfo/N0mH//u3/7PfnIX/i3u+Otst0dK0 0f/JA2OE+L/O/P/yeWbIh8D/Hd/MWY7/C5/3xv/FZ4X/ixhWZPJ/9c38n3+di//b6//M22n8 36ZQ5/s/u+6Q+n8b3lHg/+JD4f/wfx+HRXH+z4yY8H+hofB/iZ8P8H+ROxD/FxkK//cR6mr+ z41a8H9BofB/1/R/gzsG8H9bPMWy/3N/Shb/5xfOX9L/NXWB/s+SqEX/14yPy+6n8X/4P3GI /3vtwJL83+SzmoW6tP+r9Q/4v97Nfyf0f7Je9H9adcb/yS7itcjQ2Do/vnveln7A/403fLcP 8H/4P/tR2Uv6Vf2fKNL/qeZk/1cPzZDR/+lJcsX4v9Yt88no/9yVPdL//Z1XK/7P3Zyy+D8X Kov/86uw7fF6rP9z/57H/7nFdNT/w/9NkzouFP4P/7cSapbU9JEZ/zcJ9eb/al2i/+ub8/2f GyfW7o/e6//ktDOTCef6v7Z/ji1kI9vZODDQ/2nzNUu+sxs93//5CYvC/J8dleH/Fh67Z/7P zpzh/+Ker852S7Q0bfR/6sAYYf5POv9XPwT+7/hmznL8X/i8N/4vPiv8X8Sw4k7+z70uwf9t OCzO9n+1eR7C/20Kdb7/swtI8H8b3lHg/+JDleb/qh7/FxsK//cZC/+H/8P/rYbC/0Vkhf+L DHUr/+cve/g//N9qKPwf/s+3cQ0s/u891A38n1yr/yerceGH+2n8H/5PHOL/+g7/Fxjq1vX/ svm/1lzw0vq/n6j/V6T/q8xL1KT+z8wU4//CssL/JfV/p9f/q4emxv/h//B/20Ph//B/m0Ph //B/a6FWssL//fux+3T/5yYb4vzfdBuvUGf6P3ejivR//jkQ/3ek/2t6aectxonAnf5P/XX2 h/B/SbLC/+H/Xh3+j7ajjf6vPjBGmP9Tzv+1D4H/O76Zsxz/Fz7vjf+Lzwr/FzGsyOX/qh/w f1pPOvwf/s83/B/+D/8XFQr/F3JeUf/vr8P/rfg/szAL/xcaCv+X+PkA/xe5A3P5v7rH/yUK hf/D/833IP4vPtRt/J9/b4r/2+v//LvbOP/nldgX/+fH641bW77T/71/WLn8X1eV6P+qZs3/ uYsr/u+L/6vwf/g/l8i009n8n5m6oP7fR6h4/9dUbfL6f/fyf89z2+3fS/o/rfB/gVnh//B/ n6+G3/yfwv9d3/817oPB/+H/pm16A9jt/95vIvg/gf/7V6iVrPB/G1Ee/i+h/+vcjbWzjyA7 Q822YceBBfq/TuH/kmT1Xv+vq7T1f1WzN5R8Xjj7v84mh/9LkhX+D//36syzMP6PFthG/9cc GCPM/9XO/3UPgf87vpmzHP8XPu+N/4vPCv8XMazI5P+eAzD8X2yoO/m/vhb4v22hzvd/ZuNJ /Z9u8H8JssL/4f/es8L/RYai/l9oqPc9iP9LsAPxf5Gh8H8RWeH/IkPh/wLTwv+NHf7vp/2f P9zwf1s8xaL/a93jUUL/9wqF/7uu//Nry/F/H/MJM/9H/b9I/zeRcvi/H/d/VZH+r6kW/Z8a ZGr/Zw6L0/2f9jd8tw8O9X/aHQNx/s+/UMrt/54/if8LzAr/V5b/ayqbR1L/Zw92/F/cZ4X/ E2EPqO/rvk/3f24gXZz/069ut//T0w7/J/B/X0KtZIX/24jy8H8p/Z97LdGpiFCzbZiJiRL9 n67wf0myevN/aniO0mUj/XTWXv+n/7pJKPxfcv9nh7X4v4VFquX7PxMK/0cLbKP/aw+MEeb/ Guv/GvkQ+L/jmznL8X/h8974v/is8H8Rw4pM/s8Mls72f+5JEf+35bA42/815o0n/m9TqPP9 n515pv7fhncU+L/4UKX5v6rH/8WGKs//Uf9vT1b4v8TPB/i/yB2Yy/9Jif9LFAr/l9j/uQVn Kf2frPF/saHwf5GhVvyfe5zC/23xFMv1//yi0Sj/54Z4X/2f9xZR/s8v8P37sHL5v7bJ5v9U l8v/iWbN//nXIvg//N+kler//Hwo/u/jsPi5+n/200nq/9Sy/+t08vp/Y1afH1ZG/9f6r/R3 ++BI/+cgxUXr/5m78J38n33+zeP/zNxBWv+n8X/X93/+XlOa/3MPU1n8n/v3LP7PXdlz+D8/ fsni//x11h6ve/2fn+P7t/9rB7vdLP7PnVB5/J/LOs7/TbYhBP5P4P++hFrJCv+3EeXh/xL6 Pyd6nmPOZn+o2TZ+y/9FhPrzf97P6PP9n/uWs5T+T+iz/V/Xuu8t8jNne/1f+9eZa47C/yXJ Cv+3z/+Zkjb4v7BQ+L9C2+j/9IExwvxf6/xf/RD4v+ObOcvxf+Hz3vi/+KzwfxHDilz+T53v /2o3GY3/23BY4P8Cs8L/4f82vKPA/8WHwv/h/z4Oi+L8H/X/9mSF/0v8fID/i9yB1P+LDIX/ +wiF/8P/4f+WQ+H/YtPC/31khf/L5v/W6//h//B/+L/d/k/g/xau7Jfyf8NQp/Z/5sUc/i9k B4rz/N/N6v/h//B/Wfyfxv/h/+yPVtMO/1eC/9Ovjvp/G1Ee/g//txBqJSv8378fu0/3f668 ndYRoWbbsOPAAv3fL9T/K9H/DV2lEvs/JTX+L0lW+D/836TT+D9acBv9X3dgjDD/p53/ax8C /3d8M2c5/i983hv/F58V/i9iWJHJ/5lhxdn+T/X+BU0O/1cfEOpG/q81b2bwf5tC4f8+ssL/ 4f8u4//kgP+LDVWe/2t6/B/+b30H4v8iQxXm/3SL/0sUCv/38/7P3PLxf3Gh8H+RoZb93+CO AfzfFk+x6P/8W2M7ebbb/7kYSr2Fevd/bm7Ijj13+7+P9amZ/N/zll+e/7Mkasn/CX9/x//9 2/+ZB0f8X9BnNfd/UjbZ/J9Y83/jfCj+7+OwmCIHE+o2/q+pXP0/pboY/2dvRL6zV4vz/Z8H /24f4P/W/F8v7+T/KvegmMP/1ebf0/o/1ZTo/55Zne3/7Ag6l/+rJsmV4//8+lU/3t43tnj/ rJb933jhalzcI/2fv6Rn8X/uPpjD/1XuJIryf/514zf/p+2PZfF/7sKF/xP4v2lSx4XC/+H/ VkLNkpo+Mpfj/9yoTOt2f6jZNuw4EP/3GQr/t+T/msqsi5GNqvxQaZf/68yw1XfiJ/xf7Z63 S/N/9rkN/7e0SHXq/+w3Z53t/wbq/9F+oI3+rz8wRpj/65z/6x4C/3d8M2c5/i983hv/F58V /i9iWIH/CwyF/0v8aLXs/3Qt8H/bQuH/PrLC/+H/LuP/Go3/iw1VoP9T+D/83/oOxP9FhsL/ RWSF/4sMhf8LTAv/N3b4P/xf0f5vnDWL8n9q2q36PzfajKz/9/5hFej/Xlkd7f/Ma3X8X1hW c/+n8H8H1f9zs9Exk9IvcVy/hXq7LpXp/2wKqpJR/s9PsdzP/9W67Zz/i1hxNjR9/erwfzsu t2f5P6kV/i8wq9P8X1+k//uB+n918vp/ZsiJ/4v8rPB/IuwB9X3dN/4vMBT+74hQ+D/831qo lazwf/9+7D7d/7kBuu4jQs22YUa5Jfq/Mauy/F9dn13/r+27wdT/G1q1N5TsOjNe9Z3A/+H/ gvyf6lL7v+YH/F/dpvZ/Zj4Q/0cLbKP/Gw6MEeT/ZOX8n3oI/N/xzZzl+L/weW/8X3xW+L+I YUUm/2cGS6f7P7/+MIv/O4Ia4v9CQuH/Xt3B/s/8e1L/1/f4vwRZ4f+u4P+qGv8XGwr/9xkL /4f/w/+thirM/9U9/i9RKPwf/m++B/F/8aHu4v/8Uhj83xZPgf8LOi7mr9UHdSv/529P+L9/ +79a4//i/F/fZfN/Av93ff9nj6yk/k8u+7++q8v0f/68c/sA/7fi/54/eS//Z9f+4/8+p35u Xf8vvf/r1/yffxIpzf+5Qy+H/3MzP3n8n0shg/8TfrCexf/586oT+x9QZ68bxd38X//qdvu/ ftrh/wT+70uolazwfxtRHv4vpf9z11Ztb/i76/9NtmEeG0v0f5063f+p3u7nWsWE8kizn4c6 z//15kZeoP/zE674P/wf/g//d+Pm/V93pLUL83/S+r+6fgj83/HNnOX4v/B5b/xffFb4v4hh RSb/V/9A/b+6drOn+L/f93/aPA/h/zaFKtD/Uf8P/7caCv+H//s4LPB/H7Hwf/g//N9qqML8 H/X/8H//CIX/i/mw8H/xofB/2w92/N/YHe3/2le32/+10w7/F+f/hF6t/+curvi/f/s/6v9d yP9lrP+nS/R/5r1Sgf6v7hb9X9MOqf1fXf2A/+vcDsb/ffF/vcT/BWZ1mv9TRfo/81nh/8IG 0vW0w//h/+w28H/4P/Oj+L+lrPB/+D/8Xyr/515LxPm/6Tbs6LZA/zeqxjPr/7kRdFn+rzFz I2n9n/kuHPxfiqzwf/i/V4f/o+1oo/+TB8YI83+183/6IfB/xzdzluP/wue98X/xWeH/IoYV d/J/0v8p+L+vh8Xp/s+8ncb/bQp1uv+zp3hS/6cb/F+CrPB/V/B/dYX/iw2F//uMhf/D/+H/ VkMV5v+aAf+XKBT+D/8334P4v/hQt/F/7nEK/7fFU5zt//yTWJz/8x9Wdv+n22z+T3Xn+z9/ Hcf/ffF/VYP/C/us5v5PyuZ8/+eFR0L/V5fo/9br/3mnVJb/MzykwPp/+fzfSDeu6f/MNfA+ /k9Wdpfl8H/2cpvW/zkS9Z94a/i/1azO839q1f81k+Su5v/0iv+Tlf1g8vg/dznO4f/8+ZrB /0l/H8zh/9zotjT/17gjEP+H/5smdVwo/B/+byXULKnpI3NB/s+PX9r9oWbbMD9Uov8bVWNZ /s/M3Z7t/3SX2v+NWZ3p/9yYHv/37UVFkf7PLGk/2/8pk0JS//e8k+P/aKFt9H/qwBhh/q+x /q+pHgL/d3wzZzn+L3zeG/8XnxX+L2JYkcv/Vfg//N9iqEX/15k3nvi/TaHwfx9Z4f/wf/i/ xazwf5Gh8H+hod73IP4vwQ7E/0WGwv9FZIX/iwyF/wtMC/83dvg//B/+T3xZXnkD/3ez+n/4 P/zfber/4f82+b/1+n+X9n+yWvR/qkru/+wqJvxf2GGxzf/1OrX/axv8X2BW+D/83+erYfyf wP9tWZ+K/wvbgT/n/2RVvbqd18DZNoTA/wn835dQK1nh/zaiPPxfSv9Xu4FLN+wPNdvGq1Je Wf6vzPp/5/u/56Cstf6vafaGMvCv/uuePyM1/i9JVvi/ff7vF+r/4f9oP9FG/1cfGCPM/7XO /6mHwP8d38xZjv8Ln/fG/8Vnhf+LGFZk8n9KNef7v8o9WiVEeRr/h/9zvz3r8H9x/q9V+L8E WeH/8H/vWeH/IkPh/0JDve9B/F+CHYj/iwxVmP/7n727S3BVZRYw3ENhCIKKOqs9/6sdKNIx ia4WQUzw5eLj7LO6rS7jDyJPyhj8X6ZQ+D/83/MexP+lh7qM/wsro/F/u/1fWJhawP/dF34k +b9+3n2C/5svY6+n/p8Na8vxf2/zCXP/13b4P/yfJPLUfYr/05MJRD7J/xnZQWv+L7yY+07/ pxb9n2ltdv9nug/wf3auRPB/a/5PNyP+LzIr/F9W/6fN2f5PRhNZ/Z8/2Jf9XzNL7lj/55dG Z/V/7ar/k5ezRfyfXE2K+D/Zbgn/d68TXcL/yeFWwP9Z+VPK+D85AvF/+L+nT+uwUPg//N9K qKek5o/M1fi/QT6d0d+odoZ62oaft6jQ/7UW/5clq2f/Z9rmtgnd6VGms3b6P/+Gbbi7tGbE /2XJCv/3vf6vz+7/XCj8Hy2y3f1fd2CMOP9nxf91Pwr/d3xzZzn+L37eG/+XnhX+L2FYUcj/ aXu+/zPjESgP/5cYatH/je7NDP5vU6jz/Z/77az+r2vwfxmywv99g/9rWvxfaij833ss/B/+ D/+3Ggr/l5AV/i8xFP4vMi38373D/322/wvp4P/wf7P23f7vkdXR/s8VY1nxf/Lv+D/836wd 4P8eKA//t8f/tbaY/1uv/1ej/xu77P7PXW7xfzE7UJ3m/6j/90X+z+L/8H+yM+ZdQf+n8H8V +L/h0R3s/+TmhP9beDyYbUMp/J/C//0RaiUr/N9GlIf/y+j/Rhl7SLcz1NM2HqHq8n+mw/9l yerF/w3j7R7u/J8kt9P/uf936NSH1P+T4Vhl/s+PbvF/C4/dH+f//NsD/B/t7Hb3f/2BMeL8 3yD+z/4o/N/xzZ3l+L/4eW/8X3pW+L+EYUUp/9d8gP+Tl0D4vw2HBf4vMqtL+z+/oIj6fxve UeD/0kPV5v86jf9LDYX/e4+F/8P/4f9WQ+H/ErLC/yWGupT/k+U++L+oUPi/7/R/g1zH8X9b PMWi/+vl8aiI/5P//E7/Z/sK6//9w//JPAX+79/+r2vwf2n+r23xf5Ghzqr/t+7/QtY1+b+2 63Ru/+cKKJ7u/+RPKeL/wvzfd/q/UV/K/8kaWPzf+9TPaf7PdOf7vwn/l+j/5O5RxP+FdPyP Hez/5IMp4v/CAq266v/h//B/+D/833qolazwf/9+7D7b/4XKrrJGYWeop224x8bz/Z+Uc8jp /+5Z4f+y+r+2HW53d93p4WkcGO3/2t9O4f/wf/i/I/yfxf/Rotvd/9kDY0T5P9OI/9M/Cv93 fHNnOf4vft4b/5eeFf4vYVhRyP91H+D/2laG6/i/L/B/tlX4v22hzvd/Lqus/s92+L8MWeH/ 8H+vWeH/EkOV8n8j/g//t74D8X+JofB/CVnh/xJD4f8i08L/3Tv8H/4P/6f+WF6J//tO/6fU qv+Tww3/92//R/2/VP83Dvi/yFBn+T8X6jr+79bwf9f1f3qcLuX/msl3X+n/tKnS/31C/b+C /k+ywv9t+KyW/Z+s0S/i/w5Zn4r/i9uB+D/f4f/wf0tZ4f82ojz8X07/J0871iaEetqGHwfi /95D4f8W/Z+xrfg/eVe91/+Z307h//B/+D/8H+0z2t3/DQfGiPN/Wvxf+6Pwf8c3d5bj/+Ln vfF/6Vnh/xKGFaf7v/B1HiXq/41HoDz8X2KoRf83ucMC/7cp1Ir/m78PzxVqxf/J+oeM/q9r 8H8ZssL/4f9es8L/JYbC/8WGet2D+L8MOxD/lxiqMv/XTfi/TKHwf5n93+CPb/xfVCj8H/7v d0r1Wv4vLEwt4P/Ckxj+749DsO+K+T+75v/Caiz837/9H/X/8H9LCxHtx/i/MciQJP8nSHy9 /l+48lfl/wYz4f8u7P+suZT/kwMB//c+9XNl/2f7Gv3f5G/xOf2fPwJP93/drMP/fbT/k1m6 6vyfeXS7/d9sG0rh/xT+749QK1nh/zaiPPxfTv8nMyaDbveHetqGqrT+3xzlneX/5CaT0//p 9mz/Z00/eP8XZud2+j/92yn/XTj4vxxZ4f/2+T839Yj/iwuF/6u03f3feGCMOP9nxP/1Pwr/ d3xzZzn+L37eG/+XnhX+L2FYUcj/uS8lPtv/tfK6BP+34bDA/0Vmhf/D/214R4H/Sw91rv8b Zd1RPv/nvskK/5cY6mz/N7T4P/wf/g//9xpq0f9Zf8XL6v9Uj//LFAr/h/973oP4v/RQ+L/t B/u1/V94d1uk/l//6I71f0Z+O6f/G3WF/s8tW76S/xuz+7+xuZT/G7T8VDb/p5uxmP9Ta/4v LPzK6P/aFf83+VM4q/+z3bL/mzp3lBvdJLxXUmFxrXTr9f9kmVhV/q8Z9ID/u7D/a/tr+b9B uuP9X9u70URO/3e7s+H/4rLa5P/aqc/u//xU+4X8n8X/4f/e/Z9cuPB/C48H+D/f4f+2hlrJ Cv+3EeXh//L5P9305tHtC/W8jUeouvzfYGr0f11zsv9rrGms83/3icBd/s+6szF06jPq/8lh g//760VFlf7Pz5yd7P/6Jrf/0yP+jxbd7v5vOjBGnP9rxf8NPwr/d3xzZzn+L37eG/+XntWp /i8MnvB///Z/ZlzzfwFBlPB/ovHwfxsOi9P9n3slXKH/OwLlVej/zIj/y5AV/u8L/J/7Jiv8 X2Kos/3fAfX/DP4P/7e+A/F/iaEq83+twf9lCoX/w/8970H8X3oo/N/2gx3/p/B/f75WL+j/ zFDM/434vzT/Z/B/af7PMZvr+L+S9f/G3P7vH/X/yvk/fwoX8H+6n9rc/u+e1fuHhf/D/+H/ dvs/W67+n72S/xsn/N82/zfi//B//ufxf/i/raHwf/i/tVArWeH//vHYfb7/U6M8C8uVfWeo p208pFxd/q+1+L8sWT37P923o/d/+mkcGOv/3CccOuW/pAv/lyOra/g/vyy1uvp/+D/aR7Tg /8YjrV2c/+vE/zU/Cv93fHNnOf4vft4b/5eeFf4vYVhRyv+ZVf8n44kS/k+HV8b4vz8Pi5P9 3+TfeOL/NoVa8X/tAaFW/J/bOP5vyzsK/F96qMr8H/X/8H/4P/xf5A7E/yWGqsz/Uf8P//eP UPi/lA8L/5ce6jL+L0ya4f/2+r/w1riE/wsrEPF/H+P/3Gr2Zf8ndxH838J8AvX/vtT/2XL+ T9Xo/9zBvuz/wgq0Ev7PuoMqq//T7ZL/M4Oh/h/+7zr+b3x09fg//9tZ/V9bzv+Z7nT/N7rf zur/bhe3Ff9nh1lyh/q/0d/Pcvq/2+V0xf/JGtgi/m+YX9mP9X9hzFLA/6kwWC/i/+SDKeD/ BlPQ/8liugL+T01yuKX4v6dtKIX/U/i/P0KtZIX/24jy8H8Z/Z+VG75888TOUE/bcI+NNfq/ 2+j2bP8Xssrp/8zZ/s/Y/jaiug07m253KD1Yt1I4dIr6f/i/k/1fnfX/3Nwt/o8W2e7+Tx8Y I87/9eL/zI/C/x3f3FmO/4uf98b/pWeF/0sYVhTyf9qe7/+MvATC/204LPB/kVld2f+1sv4B /4f/e2pPP4b/W3khR/0//B/+D/8XuQPxf4mhKvN/1P/D//0j1Jn+zzZ+w/i/qFD4P/zfRf1f iJHk/8J65Yr9n/8K5Or8nzar/k8ON/wf/m/W8H+f5//GD6j/V6H/a2/Hem7/1zb4P/yfbxf2 f53O7v9Ulf7vA+r/5fd/XVel/zP4P/yf/3n8H/5vayj8H/5vLdRKVvi/fz92n+///G/bKWEc +LQNP29Rof+7q0b8X1b/13amn7z/a83eUHqw7nkidAr/h/872f/VWf8P/0fb0e7+zxwYI87/ WfF/3Y/C/x3f3FmO/4uf98b/pWd1qv8La7bxf3/4v2bN/0lRviL+b8yO8iz+7xj/p92bmQr9 X/gsS/i/I5DIsv/zT+T4vy3vKPB/6aHwf/i/t8OiOv/nppfwf7Gh8H+Znw/wf4k7kPp/iaHw f2+h8H/4P/zfcij8X2pap/u/eww3b5Pq/15Dvfo/++h2+7+39an1+b++O9//WfzfJv9n8H9p /u92XpXyf6pG/9faYv7PdGv+L2Rdlf/rxz63//MrOc/2f4NcbvF///Z/7i58Jf8nvgb/9z71 c5r/c59Vdf7vH/X/+lly3+b/Vuv/yQuGMv7PhD/F/134vw/2f3byeZTxf/I4X87/SZfm/+4d /k/h//4ItZIV/m8jysP/HeD//GNWov8bpqdQdfm/u+ipy//NUN5J/q/v/bzFPZ29/m/87ZRf NXW+/5PhWG3+z58v+L+FRar4P/wfbaHd/V97YIw4/zeI/7M/Cv93fHNnOf4vft4b/5eeFf4v YVhRyP91q/X/vtr/KfzfQf7PLf7C/20Khf97ywr/h/87yP+Ft/z4P/zfrFH/7x+hXvcg/i/D DsT/JYbC/yVkhf9LDIX/i0wL/3fv8H/4P/yf+mN5Jf6vtvp/+L9N/q+1+D/q/yn5/8y7cvX/ zJr/8+eVaWQQt9f/DbNuvf6fqtD/eRKV1/+5Wo34v5gdqM7zf+4Uxv9FZYX/y+r/rlb/D/+H /8P/RRwW7VOH/8P//RFqntRxofB/+L+VUE9JzR+Z6/F/vb9whZeOO/3ffBtulFuj/6uz/t/5 /q/pBlf/r5kmszeUg3/db6c+pP6fDMfwf1f0f51p8H+RofB/lba7/+sOjBHl/9pG/J/+Ufi/ 45s7y/F/8fPe+L/0rM71f2EKHv/39mj15P/W6//JU1wJ/yfDjiL+T7LG/21ZYb7k/4x7HqrQ /4VTvIT/azKEal5Crfg/v6AI/7fhHQX+Lz1Ubf7PGvxfaij833ss/B/+D/+3Gqo2/9fg/zKF wv/h/573IP4vPRT+b/vBfnH/1z66o/3f7Elst/97XeBbyP/drtfF/N8jq6P9nydRi/5PVrvj /xbmE+b+j/p/qf6vYP2/gv7PVun/mlX/F6YTZD8f6v88Lsrq/1yoBf/Xddn93z2r9w+roP8L 66VL+D8r19kC/k+7AUFe/3e74V/J/wnSKuL/huz+z675P3/uZvV/usf/RYXaXP8v7ODv9H9m xf+pSR6mSvi/8LhYxP/J3iri/8ICrQL+r5HDrYT/G3xWZfyfmJoi/k/+Pc3/zbahFP5P4f/+ CLWSFf5vI8rD/2X0f4M8FwxTwjjwaRsPKVeX/6P+X/rbxiX/1zW3QYXzf2F2bqf/07+df4LH /2XJ6t3/+Vsu/m9hkWr9/s99oRr+jxbZ7v6vPzBGnP/T4v/aH4X/O765sxz/Fz/vjf9Lzwr/ lzCsKOT/2u4D/F9Yf4j/w/89Nfwf/g//lxQK/xdzXuH/fjv8H/5PGv4P/3cZ/yfLEfB/G0Lh /95C4f/wf/i/5VD4v9S08H9vWX2k//NLIC5U/69O/2dy+z/q/6X6vzrr/5Xzf+EIVG+taP2/ Cv2fbabc/k9/Qv2/Ov2fOx6o/7cYCv/3pf7PdBX6v/X6f/g//N+5/k9eBuH/towtqP+H/1sJ hf/D/62Eekpq/shcjf+z8lRpx3Z/qKdtqErr/+H/0t82Lvm/friNX/L6v9tP4v+yZIX/2+f/ WttU6P+6Ef9Hi253/2cPjBHn/4z4v/5H4f+Ob+4sx//Fz3vj/9KzOtf/hech/N/bo9Xc/5lx zf/J2qgi/q8/AuXh/xJDLfs/N8+A/9sU6t/+L+s1cNn/+bdoWf2fwv/h/9ZC4f/wf2+HRX3+ b8T/4f/WdyD+LzFUZf7PDPi/TKHwf/i/5z2I/0sPhf/bfrBf2//1Aay4aYWj/Z/cPL/S/5Ws //cR/k9SwP/92/9R/y/V/5Wr/6fNiv9rpzAfms//teXq/42f4P/kMvGd/s9dbhf832iH3P6v +wT/F2b9C/g/bcr5P3eE4v8WQ23yf80k040l/F+X3f+15fyfmxHE/0WE2uz/goX6Tv83rvm/ UQZnJfxfP4Q/xf/Hof5PVvaW8H/3cWIR/xdCFfB/sueK+L/w7IH/w//NkzouFP4P/7cS6imp +SNzPf5PnpUHPzjb6//m26i1/t9dNeL/8vq/Ybo9Iub1f0bb8/1f+Lqruvxf76ei8X8Lj934 P/wfband/d9wYIw4/9d5/9c3Pwr/d3xzZzn+L37eG/+XnhX+L2FYUcr/Gfwf/m8x1KL/a90b T/zfplA1+r8G/5chK/wf/u81K/xfYijq/8WGet2D+L8MOxD/lxiqMv/Xd/i/TKHwf/i/5z2I /0sPhf/bfrDj/xT+76/X6nXW/3Nfwo3/i8uK+n+11f/7bv9nyvm/5lL+z/T4vwv7v9thgf+L y+o0/zdV6f+0qdH/ua/aw/+lfVb4PxX3gNrOO/wf/u9lG++h5mkdFgr/h/9bC7WSFf7vH4/d n+P/rD/00vyfDYe26fB/C6HS/V/b+PtgZf7vdjHH/61Mfr+OA/F/ObI63v+5WU78X1wo/F+l 7e7/xgNjxPm/Xvyf+VH4v+ObO8vxf/Hz3vi/9KzO9X9HLCWuz/9pu+r/RAqV8H+dDNeL+D99 QCj8X0wo/N+jO9j/uY3j/7a8o8D/pYfC/+H/3g4L/N9bLPwf/g//txoK/5eQFf4vMdSV/F8v nwz+LyoU/g//d03/1+Xwf+EC8Jf/k7mhNP8X5o8eb/Drq//XjufX/wszyfg//N+s4f8+zv+F I1C9taL+T3bod/o/F2rB//Vdi/9L8n/3Z5zv9H+3Z/wL+T/tl8Li/xamfk7zf+6zOtn/WbeJ Qv4vrHavzf/J3aOI/wtPKgX8nzxulfF/ch8s4v/CWrAC/k8GfWX8n3xI+D/83zyp40Lh//B/ K6Gekpo/Mlfj/wbt/5TBjwt2hnrahvuhGv3fvaoh/i+v/+vsVGf9P5n8TvN/sqc+x/9ZyQP/ t7BItX7/5+Zu8X+0yHb3f9OBMeL8nxX/1/0o/N/xzZ3l+L/4eW/8X3pW+L+EYUUp/9fg//B/ i6EW/V/n3szg/zaFwv+9ZYX/w//h/xazwv8lhsL/xYZ63YP4vww7EP+XGAr/l5AV/i8xFP4v Mi38373D/+H/8H/qj+WV4QJQsf/TzYj/iwz1dgTW5/9C9TX8H/7vaSGi7mqs/2er9H8r9f/a UeP/0vyfrOH/Uv93rfp/dfq/oflm//cB9f/8p4P/W/ys8H9F/F+4CuH/8H/4P/zfQqiVrPB/ G1Ee/i+j/7Oy8NHKqs6d9f/m23hIOfwf/m8hqxf/d3t26/F/K5Pf+L97h/873/+5rPB/tMgW /N90pLWL83+D939d/6Pwf8c3d5bj/+LnvfF/6Vnh/xKGFYX8nzEf4P/CO9YS/u/+Vcz4vz9D 4f/eQn2b//Mzzzn9nzb4vwxZ4f++wf+NE/4vNRT+7z0W/g//h/9bDYX/S8gK/5cYCv8XmRb+ 797h//B/dfs/mbCRHbTT/+lx3q37vzAS9If5Xv93Xxr9Eqqm+n9an+7/7hdX/B/+b9YO8H+d rdH/qWL1//B/qf7v9jC3WP9PU//ve/yfOyzwf4uhtvk/fxXC/y1M/eD/svo/cy3/18vL2RL+ r5tf2Y/1fxKqjP/rH93R/m94dPi/f48t8H/4v5VQ+D/830qop6Tmj8wV+T9/ObYp9f+etlGr /7MN/i9LVq/1/9x0Fv5vMdTn+T//3gL/t7RI9cn/jfg//B/Nt7v/0wfGiPJ/XSP+r/lR+L/j mzvL8X/x8974v/Ss8H8Jw4or+b+w/hD/9wX+z335O/5vUyj831tW+D/839f4P+r/4f/8bz35 P7eyDf8XGwr/l/n5AP+XuANL+T8z4P8yhcL/5fV/Vu5o+L+oUPg//N/vlCr+z/0P/u8s//cB 9f+0rJTA/y3MJzz5v6bD/8V9Vi/+T0/4v8hQ+L8S/q9re/zfdf2fK/h7Kf83Pjr833zqB/+X 0//5qfYr+b9y9f/Cctsi/k9SqM3/yQUP/4f/w//h/14OC/wf/u89qzf/JwN0axOugU/beISq y/+1tkb/Z4az/V9rtcb/rUx+4//uHf4P/0f7ynb3f+bAGHH+T4v/Mz8K/3d8c2c5/i9+3hv/ l54V/i9hWFHI/2n7Af5vDC9o8H9/Hhb4v8isLu3/3L9n9X/ufRL+Lzkr/N83+L+2x/+lhqrP /1H/b09W+L/Mzwf4v8QdSP2/xFD4v7dQ+D/8H/5vOdT5/i/gBvzfXv8XlgWm+T/5c2v2f44D lPJ/tj/d/z3TDfzfmv9rO/zf1/g/teL/7sIjo/+z+L+FK3sO/+eXxGT1f7pZ9H92mvB/3+L/ mtFm9n9uzeOV/J+/muD/FqZ+TvN/psP/LezADP7P33Kz+j/3MHy2/5NSg/i/hYeedt6t+7/h 0eH//j22wP/h/1ZC4f/wfyuhnpKaPzLX4v9uw5zm0e0L9byNR6i6/N/Yne7/jEwu5fR/uj3b /9nmdtWr0P81/r/bNmny28y7T/B/E/5vk/8zNfo/jf+jxbe7/2sPjBHn/4z4v+5H4f+Ob+4s x//Fz3vj/9Kzwv8lDCsu5P9aWQyE/9twWJzt/3o3L47/2xTqdP/nL374vy3vKPB/6aFq83/U /8P/+d969n+3ERP+LzYU/i/z8wH+L3EH4v8SQ+H/3kLh//B/+L/lUPi/1LRO9399GK8n+b8w lv7L/9lHt9v/va1Ppf5f1GGx1f+FteX4v7f5hLn/o/5fqv/r7On1/77a/7UW/xd5tXjxf2rZ //V2yO3/3GGB/4vZgWqr/3NXk6z+z1VywP/FZXWa/2ur9H+n1//rbq3J7P/8wY7/S/uslv3f 05Ud/4f/k1bS/42Pbrf/G+cd/k/h//4ItZIV/m8jysP/ZfR/MjF8u121u0M9b0P9Vsqry//d RrcV+r8ZyjvJ/3Xj7bDJ6//0OOH/smSF/9vn/9zU48n+z05jbv/nQuH/aJHt7v+6A2PE+b9W /J/9Ufi/45s7y/F/8fPe+L/0rPB/CcOKUv6v+QD/J+P0Mv7PHhDqSv7PvZ3G/20Kdb7/8+sO 8X8b3lHg/9JD1eb/xgn/lxoK//ceC/+H/8P/rYaqzP+ZAf+XKRT+D//3vAfxf+mhruL/Jlme h//b4ikW/V9YjVHE/4UXp9/o/0rW/9O6lP/zTmnR/4VVjvg//N+s4f8+zv9R/+8Y/9dYS/2/ 7/F/7v6f1/+5a+CF/J+/NX6r/1P4P/yf7Ix5t+r/xoL+Tx6mivg/ORlK+L9wSS/i/+Q+WMT/ yQWvMv83yuNBAf+nm+bR7bwGPm1DKfyfwv/9EWolK/zfRpSH/8vo/6xMw0i30/89beMRqi7/ N1n8X5asnv1f07s7lBsoDWZvKD3YZvrtFPX/8H8n+78PqP83dNnr/yn8Hy2+3f1ff2CMOP/X ef/XNz8K/3d8c2c5/i9+3hv/l54V/i9hWHEl/9ccgfLwf4mh8H9vob7M//Xut/F/W95R4P/S Q+H/8H9vhwX+7y0W/g//h/9bDYX/S8gK/5cY6lL+Tx688X9RofB/+L+L+r8wXk/yf+Ebnf/y fzI3hP/7Bv8nhxv+D/83a5X6P1lThP97D3VZ/3cb+9oe/4f/u4r/84se8H8LUz/4P/zf0me1 0f+JaCjh/wYZSBfxf3J3L+H/mnCwU//v7bBonzr8H/7vj1BPn9ZhofB/+L+VUE9JzR+Za/F/ xvhHkNDtC/W8jUeoM/1fLxtP83/yC/i/A/3fbXTuVhLrduqbbm8oPXRutBA6hf/D/0X5Pz8b k9f/jaf7v7HB/9E+od39nz0wRpz/68X/mR+F/zu+ubMc/xc/743/S88K/5cwrLiS/5PFQEX8 n0yx4/+2rDBf8n/WvfHE/20Kdbr/s+5qgf/b8o4C/5ce6lz/18m6I/wf/m/WbC8LCvB/G/Yg /i/DDsT/JYY61f/5PPB/W0Lh/95CfZn/6+Uwx/9FhcL/faf/k68lxv9tGXQu+7/weJTm/8Ie /Bj/p8MTY5r/Cwt8//B/JugGiXik/zM2zKmmXC42+j9Z71OZ/+tFJuD/Fg72bf7Pv6tI9X/y xu0v/ydzP0X8X1j4VcD/DT6dIv5v8CPM6vyf5HG8/7O6kfp/eth/uZ06r1lC9xn+b5APqYT/ C6Ymzf+FD+kP/+f2Fv5vMdQ2/+efpsr4Pz+5XsT/WX8NLOP/urAKM8X/zbehPsH/te55vpT/ 62fJHev//GFTyP/JoVfE/8nYo4j/k5tTEf8nA4m6/F8vn1UZ/yeP8/g//N/Tp3VYKPwf/m8l 1FNS80fmavyfPNqHbqf/e9rGI9SZ/i9s3B96u/2fXNnlwekj/J88C1fl//rRfcvZ7Zlb7uf7 /J8dp+a3Ux/i/+SJrzL/52fWKvN/bedOhur8X+um/PF/tLPb3f8NB8aI839W/F/3o/B/xzd3 luP/4ue98X/pWeH/EoYVhfyfW81+tv8z8hII/7fhsMD/RWZ1Zf/nKx7g/7a8o8D/pYc62f/J dz7h//B/s2b9Ygf836Y9iP/LsAPxf4mhTvV//oPB/20Jhf97C/Vt/k/eaeL/okLh//B/v0/D 1/J/knaa/wuTOn/5vzASTPJ/96XRL6Fe/N8oYKWE/wsvEEr4vy7MqaZcLi7t/+SmiP9bONg3 +j95iivh/2SxdhH/J2O/Mv7P3zaK+L/e7f7q/J+fsCng/3oj/k/3fUr9P3+ZCB3+b8flFv+H /1s4hfF/+L+lW2M77/B/+D+/Efwf/s/9KP5vKSv8H/4P/5fJ/00ynpVup/972sYj1Kn+T9aY Jfm/sATng/xf+EK1JP93r7r8HOo0/9dNrlLebYDW2W5vqNs1xo2zQqfwf/i/GP9nxir9n53w f7QPaHf/Nx4YI87/DeL/7I/C/x3f3FmO/4uf98b/pWeF/0sYViz6v8b6104Z/V9rx/P9n3xT MP5vw2GB/4vM6sL+T54+8H9b3lHg/9JDner/7mUcMvo/3eL/UkOd7f96fw3M6f9MN+L/8H+r OxD/lxjqVP/nj8Cs/u92F8H/5QmF/8vs/+RpGP8XFQr/953+T16+4/+2DDoX/Z+W1+rS7fV/ AVKErhtX/J8ssZVut//r592q/5Mp/PAlZDvXEnfTvGuHZf+nxtky9jz+T/Ur/q8Nc6opl4uN /k/ET23+T1LI6P/a7lL+r51k+XWT5P/0U2eW/V8rF7yc/q9d8X+tiJ+c/q9d8X9jJzfesFt3 +r/51aK1K/4vIIemy7C0SF6tuEU4Z/u/xj94FPB/nZ1uV/bbZT2swtzn/1q//jN0v1m9f1gF /V8gUyX8X1Aizezl5G7/93jhveD/On9Jx/8thtrk/xp/nS3j/9yjdiH/5w10If8nOzjN/822 oT7B/3XuKC/l/7pZcsf6P//cVsb/Cfwr4v/CAogS/k9WUJfwfyqcSUX8n6RQwv/Jnivi/wY5 Agv4v3DlT/J/T9tQCv+n8H9/hFrJCv+3EeXh//L5v9b4+1no9oV63oYb5X6A/5Nbbkb/N3bn +7++lc8sJdT9WxeeQ53n/zpzO+a06Ud5PNjl//rB/b9D53/yA/yfDMcq839+mXRt/s+PNWvz f/3orhZZ/Z+bu8X/0SLb3f9NB8aI8n99I/5P/yj83/HNneX4v/h5b/xfelb4v4Rhxen+T57A ivi/Noxw8H9/HhZn+7/BvZnB/20Khf97ywr/h//7Fv+nRov/Sw2F/3uPhf/D/+H/VkNV5v/m KA//h/97CYX/S/mw8H/pofB/2w/2i/u/O8NRqiL/J+glp/8zK/7vDihz+r+mmP9T+L8k/3cb VOL/4j6rZ/+n+mmt/l92/6fK+T/dlfJ/q/X/DvB/Zs3/BadUwP8Zv6aogP8bGyP+bzT7L7eT zNOHzq1hw/9F7UC1zf/1/mEgr/+73fAv5P+0P9yK+L/ePyhm9X92xf8NOrv/s2v+r8/g/+bb UJ/g/3R2/+duIhX6P4v/w//5n9/k/6xkjf9bu4ng//B/W0OtZIX/24jy8H8Z/V/4ghrt7687 /d/TNmRCtT7/dxvd4v9yZPXs/4ahu43S9e0Dk2eqff6vd2PJ0KnPqP8nTzv4v9VJus/xf1rj /7b4P/csjP+jRTbxf31zpLWL83/a+79W/yj83/HNneX4v/h5b/xfelb4v4RhRSH/51azn+7/ pGA8/m/DYXG6/3NHIP5vU6jT/Z9/tYX/2/KOAv+XHgr/h/97Oyzwf2+x8H/4P/zfaqhT/Z+/ DOH/toTC/72Fwv/h//B/y6HO939h0gz/h/+bZ/XV/u8R6nD/t1r/L9ye8H/4v1kr6f9G/N+H +b/WfoD/88fc8f7vdni6D+Z2WR+6/Ufg1I7to5NVTKf7P/ms8H9/+D91qfp/uvELEYv4Pzfy K+P/7Jjd/7Xl/J/pKvR/zkCf7v+a7P5vWvN/EqOI/5MRUxn/JykU8X8B5ZXwf8OjO9j/yclQ mf8LaC/J/z1tQyn8n8L//RFqJSv830aUh//L5//M1PtRetPs93/P23iEOtP/9TLdNSSsXb77 v/sd0p7u/1rZweFpJ83/Dc9H4Gn+bxrds7A2bWe7vaF037mH3NAp/N+B/s8f5XX5Pz1Nuf2f m3qs0P+N+D9adLv7P31gjDj/Z8T/tT8K/3d8c2c5/i9+3hv/l54V/i9hWFHI/922cb7/k7nW Iv5P5tbxf1tWmC/5v9F9Vvi/TaHO9n+3pyqV2f/dHu7xf+lZ4f++wP/dHlLwf6mh6vN/bYP/ w/+t70D8X2KoM/3f4BcFZvV/fYf/yxQK/4f/e96D+L/0UFfxf+HL4vF/WzxFIf/nFnYs+79w +avL/4WV1yXq/03l/N8gHwz+D/83a9/t/2w5/zf7rJ5CfbX/+4j6f/n93+1hbqH+36RH6/2f NSn+z0+BhU5WMV3H/93hXwn/587dvP7vdljg/+KyOsv/aVOl/6uy/p+7Bi77v6eF1N/m/1r8 H/7P//yn+T8twxz8n8L/PX1ah4XC/+H/VkI9JTV/ZK7G/1n/vG2sv23t9H9P2/DjwNP9n4zK avN/8ofm9H9umvhU/zdO5paHNreL3+5Qum/dcDh0Cv+H/4vyf+OQ2/+5qcez/V+P/6N9Qrv7 P3NgjDj/14r/638U/u/45s5y/F/8vDf+Lz0r/F/CsKKQ/1N2zf/JwLeI/2vDG0/835+Hxen+ z307Lf5vU6jz/Z/796z+r6P+H/5vLRT+D//3dlhU5/+o/7cnK/xf5ucD/F/iDizl/8yA/8sU Cv+X2f/JGBr/FxUK//el/k+W5+H/tngK/F/UcXGa/1ut/1fS/8k8Bf4P/zdrdfq/ThZj4/9W lxb95f/Ci7mK/J/W3TB6/9clXG6n1n/QofsM/yf33cr8n3EzWXn93+0ufCn/J9ON+D/830n1 /8LryDFlzP72LHe+/5MrUhH/N7+yH+v/5NZZwv/pRo6BIv4vhCrg/2SgXcb/yYdUxP/Nhva7 /d/T4wH+T+H//gi1khX+byPKw//l83/a+nKrejDt7lDP23hIubr8Xzfi/7Jk9eT/9O0W1Vnn //qu2xtK960efzv3z/p8/2fCpE3S5PfH+T8/O4f/W1qk+uT/xtP9X2fxf7RPaHf/1x4YI87/ deL/hh+F/zu+ubMc/xc/743/S88K/5cwrCjl/9QH+L/B/3sZ/9ccEAr/FxMK//fo8H/4v6VQ +L9Y/2dkuVlG/+e+yQr/lxgK//ceC/+H/8P/rYbC/yVkhf9LDIX/i0wL/3fv8H8f7f/GsP4X /7fT/6mwQKUu/2dksXZG/6fb/lL1/2wbspafxv/h/9zuFQeQ0/+NGv8XGSrG/+mplzM5zf+1 91AV+j+3uG3B/90iif/rUur/+T0XOvemCv8XtQPVRv/XuqWyef2fO4Wv4/+ayaOX7/R/7rxa 9n/+vpvV/+ke/xcV6sX/uc8K/5f4WeH/VNToFv+H/3M/iv9bygr/h//D/2Xyf52Ini6h/t/z NtxP1uj/BnO6/7uvL8ro/3R7tv+77V/t/F+b4v+M+2LF0KnPqP+H//se/6dz+z//zVkn+78W /0f7hHb3f92BMeL8X+/9X6d/FP7v+ObOcvxf/Lw3/i89K/xfwrCimP9rVvxfGDwX8H+tvEXD /204LM72f5P7rPB/m0Kd7v9GWf+Q0f/dHu7xf+lZ4f/y+7+AyDPW/2t7/F9qKPzfeyz8H/4P /7caCv+XkBX+LzEU/i8yLfzfvcP/4f/wf+qPNY/dU1el/7PmWv5PDjf8H/5v1g7wf313vv/r B4mI/3s7LOb+zy3CWfZ/Ievv9H/L9f9MZ01u/3fP6v3Dwv99nP9zF6Yr+T+/y77T/+kR/3eI /2utze3/3JrHS/k/OfRK+L+wBL2I/5Pzroj/k+0W8X8hFP7v77EF/g//txIK/4f/Wwn1lNT8 kbka/9f6ktOh2+n/nrbxCFWX//uA+n8H+L8ZyjvH/93u803nukmbvaF0343TbzcLhf/D/y1k dbz/0x9Q/09MLP6PdnK7+7/+wBhx/s+K/2t/FP7v+ObOcvxf/Lw3/i89K/xfwrBi0f9pqRSf 0f+597Sn+z8d1qoU8H/teECoy/g/0/g3M/i/TaHO939+QVFO/2dG/F+GrPB/3+D/xgn/lxqq Pv/XNvg//N/6DsT/JYaqzP/NUR7+D//3EupU/2f9X4r/iwqF//tO/zeFSTP8317/F+5onkTt 9n/tvNOH+r/7KuyXrKj/t8f/abPq/+5Zy0/j//B/6gj/p29P3qX8n8L/Jfm/9fp/6pv933L9 P9OP2f2f24Gn+79ww8f//dv/OfB/If+ntUw34v/wf3P/15Tzf4OcV9/p/9Sa/5OBRBH/JzM/ RfxfGLOU8H/hKlTE/8mVv4T/kwteEf8nj3ol/N/vlwmlXAPn21AK/6fwf3+EWskK/7cR5eH/ svo/P9rp/ITkbv8324Z8oVp9/u9e1RD/l9f/dbaxt24Ih94+/zc6ehq6WSj8X27/5/+Uyvyf afrs/s9U6f8M/o8W3e7+zx4YI87/DeL/+h+F/zu+ubMc/xc/743/S88K/5cwrCjl/5o1/ycn URH/Jyng/zYcFqf7P/d2Gv+3KdT5/s9lhf/b8o4C/5ceqjb/Zw3+LzUU/u89Fv4P/4f/Ww1V mf/rO/xfplD4v8z+T0Yt+L+oUPg//N/vlCr+z/0P/u+s+n9m+ID6f/g//F+J+n+jxv9Fhnr2 f7Yr5v/GVf8XphNkP9fh/8bBZvd/I/7vGP9n3GLHvP5vnK7l/zx6wf+9T/2c5v9MV6P/M/g/ /J//0Wbe4f/wf2/bUAr/p/B/f4RayQr/txHl4f9y+j//mKPbadgd6nkb7oaO/1sIle7/5DGn Mv83mNuwVt8eiPV+/2eNG/eH7vYz2uL/smR1Df/nXW1W/+deVJzu/9zED/X/aGe3u/8bDowR 5f9sI/6v+VH4v+ObO8vxf/Hz3vi/9KzwfwnDikL+z3Rr/k/Lv5fwf7I6D/+34bDA/0VmdWn/ 59cd5vR/t6sF/i89K/wf/u81K/xfYqhC/s90+D/83/oOxP8lhqrM/7Uj/i9TKPwf/u95D+L/ 0kNdxv/JMYD/2+IpzvZ/90Fnkv8LMWqu//cR/i+sLcf/vR3s+L8vrf9nq/R/zb/932hT7vh3 /yfnpr2Q/2utwf9d2P95mHwl/+dHZbX5P7mW5/R/aijm/9xnVZ3/czeRZf8XXkd+p/+z1/J/ cvHD//3xulHh/6Kvgfg/6fB/W0OtZIX/24jy8H8Z/Z/xl/TbhWLaHep5G+6/T/d/rTxYSbfX /8mwNnS/ogf/l9X/td14G47ptu8S6v/ZyU1vhk7h//B/Mf6vbYbs/u9xwz/N/2n3BTX4P9rZ 7e7/xgNjxPk/Lf7P/Cj83/HNneX4v/h5b/xfelb4v4RhRSH/516HrPg/WSlQwv/psFYlH8qz +L9j/J8/AvF/m0Kd7//cxrP6v97g/zJkhf/7Bv83Tvi/1FD4v/dY+D/8H/5vNRT+LyEr/F9i KPxfZFr4v3uH//to/zeG96b4v93+T/49zf+FIV6Y++nW6v/1j263/+vnXUH/V7D+3yOr8/xf L0c2/g//N2sH1P+bzPn+T1694P9WlxbJv7rSTSv+L1zZZT/X4f+6tsvu/8wH+L8nZoP/w//5 f5SN4/8Wpn7wfzn9n16v/yfjwMr8X++zKuL/nq7sx/q/8DatiP+T+2AR/ycfTAn/56cPCvk/ +ZCK+L/Z0H63/3t6PMD/KfzfH6FWssL/bUR5+L+M/q/xl1Hd2AT/97QNNzFRo/8bzAf4P/vo dvu/ad6d7//adhrdZG2YJt7p//zLPOnUZ/i/8Fnh//B/p/i/dsT/0T6h3f3fdGCMOP9nxP91 Pwr/d3xzZzn+L37eG/+XnhX+L2FYUcr/mVX/J4/XBfzfnW5Q/w//99Twf5/m/2yH/8uQFf4P //eaFf4vMRT+LzbU6x7E/2XYgfi/xFD4v4Ss8H+JoS7l/2TD+L+oUPi/L/V/YU0p/i/V//lF xIn+Lzx5r/o/+c/v9H8F6/8V9H9q1f/1IWv5afwf/k99uf9zr0VK+T9bzP+13SfU/6vQ/92G zrn9n9uB+L+YHajO83+2v5T/kzWw3+n/TFel/9PmdP9nutz+z615vJL/68ILhvu7VnWc/5OT oYj/C5fxEv4vsNES/i/cqNL8X2B2F/Z/0qX5v3uH/1P4vz9CrWSF/9uI8vB/+fyfGuRyO7Tt /lBP26jV/43d+f4vPG+blFAyTLh3H+D/3ITF7aGgsd3eUHpo3FAodP6H8H9ZsrqG/9NTdv9n m9P9X+eeC7L6v9udHP9Hi23B/+kjrV2c/2u9/2v7H4X/O765sxz/Fz/vjf9Lzwr/lzCsKOT/ 3GBpxf/JeKJE/T9ZnVfE/8mbGfzflhXmi/7PraLD/20KVaH/cy9P8X/JWeH/8H+vWeH/EkPh /2JDve5B/F+GHYj/SwxVmf/TGv+XKRT+D//3vAfxf+mh8H/bD/aL+z/5U/B/n+P/3GqL0+v/ dSFr+Wn8H/5Pfbn/UwXr/5Xzf59R/y9c2WU/1+H/jHuhlLn+34j/+xb/Z5rmUv7vm+v/4f+O 8n/a4P/wf/i/iGfhbf5PBoD4v4WbCP7Pd/i/raFWssL/bUR5+L+M/s/2/tZo/TqtnaGetuF+ Ev+3EAr/t+j/bvvX+b+hk0Nvn//T4/DbKer/4f+i/F+bv/5flf6v6/B/tOh293/6wBhx/q8T /zf8KPzf8c2d5fi/+Hlv/F96Vvi/hGFFKf+n1vyfHBZF6v/1Ya0K/u/Pw+Js/2fcG0/836ZQ +L+3rPB/+L+v8X/W4P9SQ+H/3mPh//B/+L/VUPi/hKzwf4mh8H+RaeH/7h3+77P9X1gZjf/b 6/9seCGZ5P8kxl/+L6xATPN/4cPC/+Xwf9qs+r82ZC0/jf9b8X8G/5fm/1yZLfxf3NTF/GrR mvGf/m+wcoCnLS2SL3NsPsD/+YM4q/9rh+X6fzZ7/T+N//sa/+dhMv4vKquz/J87r1b8n99E Vv/Xrvi/MAjuUuzLfBvyWdXn/8z5/m8Ysvu/ds3/3YWq/EWH+r8wXVPC/4UlUgX8n5rCwV7A /93XgsmW0vzf75gd/xe3A/F/0uH/toZayQr/txHl4f8y+r9BbhvS7a3/N9/GIxT+L7v/6x7d bv+n5935/q/tGvF/OsX/DcNvNwuF/8P/LWSF/9vn/6j/R9vR7v7PHBgjzv/13v91+kfh/45v 7izH/8XPe+P/0rPC/yUMK5b9n/8O85z+r12t/6fK+b8wwsH/fb7/a92bGfzfplD4v7es8H/4 v6/xf9T/w//538L/Kfzf1h2I/0sMhf9LyAr/lxjqUv5P7u/4v6hQ+D/83++UKv7P/Q/+78n/ WVPM/z2ywv/h/yr3f9T/S/R/YzH/9xH1//L7Pxdqwf8105jb/zlAif+L2YHqPP/nYPKF/J8U vfpS/2c+wP/J8SDd3iXm823IZ1Wf/1uv/zfna3v9n5ybH+T/hvCCQf6iY+v/2dkOPNb/ya2z TP0/ObIr839yeBfxf7KcDf+n8H/zpI4Lhf/D/62Eekpq/shcj/8T3jbYdn+op2087Etd/q8b z/d/MiqTbrf/s/POfXfbuf6vMUPr/F+YJt7r/5rfTn1I/T85AvF/V/R//puz8H9pz1dnuyVa nnb3f+2BMeL8nxX/1/4o/N/xzZ3l+L/4eW/8X3pW+L+EYUUp/9es+r+waOF4/9fK6rycKM+u +b/O5g6F/8P/LYc63/+5f8/q/3qD/8uQFf7vG/xfZ/F/qaHO9n/W5PZ/7hsT8H+xofB/mZ8P 8H+JO3DZ//m1UVn934j/S76L4P+Sd+Ci/+v9oY3/iwqF/8P//U6pXsr/BfHjd+Re/xdWB5tw uRhX/F94usf//XEIlqv/p9Sa/xMWWpv/m3L7PzfVjv+L+qw+sP5fn93/teX8n2SlXpvWNsfS ooAc5P46Vun/+m7J/5lJZ/d/3UfU/5MPqS7/5x8Gsvo/N1N8If/X+Ovst/q/T6j/h//b5P/8 VPui/3via/X4P7l7FPF//WwHHuz/5Lwr4v/CwV7C/8mVv4T/k3O3jP+Tx4MS/i8giCT/N9+G Uvg/hf/7I9RKVvi/jSgP/5fT/w3+cjyahHHg0zYeUq4u/2cb/F+WrJ79nxnb27MA/m8xFP7v tzvS/3UT/m+T/zP4P1p0u/u/7sAYcf5vEP/X/yj83/HNneX4v/h5b/xfelb4v4RhRSH/Z7rz /Z8Zw2x/VpSH/0sMtez/3Ntp/N+mUPi/t6zwf/i/r/F/1uD/UkPV5//cN9vj/2JD4f8yPx/g /xJ3YCn/13f4v0yh8H/4v+c9iP9LD4X/236w4//uOxL/97QY+8n/tf2a/5stY/82/6dX6//J R4f/W5hPePJ/Fv93kP+Tzwr/98fVwk1d/Kv+nw2caefSonBYhJc5F/J/bdvb3P7Pr3nE/8Ud Fm8vvMv4v9ungP+LzAr/V5n/012X2/+t1//D/+H/8H/5/d9Qzv9R/w//h//D/62Gekpq/shc jf8bG/vodoZ62ob7oRr939jh/7Jk9VL/r21veTj/15u9ofSg7fTbzULh//B/C1nh//B/tGLt 7v/6A2NE+b/b/+39X/Oj8H/HN3eW4//i573xf+lZ4f8ShhWF/J8bLJ3u/8IIB//3+f6vc/Pi +L9NoU73f4O7OeH/tryjwP+lh6rN/40T/i81VIX+b8T/4f/WdyD+LzFUXf5PNyP+L1Mo/F9u /ydr8/F/+L/VUPg//N89UvPYkbv9n+w6M7yEevF/YQXid/o/PRXzfw6kFKr/Z1f9n3ww+L8/ /B/1/xL932Twf5Gh4vxfUDxp/s/IDrqS/7vdC+us/9fNOvzfmv9zz/iX8n/+mKvN//kre17/ p4v5P21O939t9vp//qv2lv1fP0su0f/9voVe9n/+cpzV/6lV/ydPIkX83/zKfrD/C0v5U55E ruz/etEuZfyfHIFF6v/Jo1xa/b/ZNpTC/yn83x+hVrLC/21Eefi/jP7Pyj3R+rHFzlBP23A/ WaP/u1c1xP/l9X/dcHuYcv6v6/aGcvBv/O3UR9T/M2N4Mk2ZDzR63uH/vsb/uZI2Ffq/Ef9H i253/2cPjBHn/7T4P/Oj8H/HN3eW4//i573xf+lZ4f8ShhWl/J/5AP8X6Ab+D//31PB/n+b/ bIf/y5AV/u8L/J+bycL/JYaq0P81Hf4P/7e6A/F/iaEq839tj//LFAr/h/973oP4v/RQ+L/t Bzv+774j8X9Pi7HP8n+PrI72f3q9/p98MPg//N+sUf9vo/+bavR/16r/19vs9f/8Kib8X9xh 8fbCu1D9v9thgf+Lywr/h/97fzX87P/cTWTZ/0lWJfzf6CEY/m9pB+L/8H9bxhbU/8P/rYTC /+H/VkI9JTV/ZK7H/8n4ZWgSxoFP23hIubr832Dwf1myevF/fXMbX+p2CifUPv/XTtNvp/B/ +L8o/9f3uf3f7IaP/8P/Xbvd/d9wYIw4/2fE/3U/Cv93fHNnOf4vft4b/5eeFf4vYVhRyP+5 F92n+78xzPaX8H9HhLqS/3OfFf5vU6jz/Z8/5vB/G95R4P/SQ1Xm/6j/h/9b8H9th//D/63v QPxfYqi6/J8aNf4vUyj8H/7veQ/i/9JD4f+2H+zX9n/3hal+EfFe/2fm3br/CyNBP1O01//p eVfQ/3V2xf/JxnP6P7eG5HT/J/MU+L9/+7+gr/B/X+3/ZN13Tv/X9RX6PxfqOv5v6Mfc/s/Z F/xfzA5UW/2f+yzz+r/bXfhS/s+v/cf/vU/9nOb/3Gd1qv9rpz5//b8R/4f/8z/azDv8Xw3+ zzy63f7PzDv8n8L//RFqJSv830aUh//L6f+Etw1NQqinbdTq/2yD/8uS1Yv/s1Mv/q9P8n/d b6dkigT/lyEr/B/+79G1Bv9Hi253/zceGCPO/7Xi/+yPwv8d39xZjv+Ln/fG/6Vnhf9LGFaU 8n/qfP/X6rBWBf/352GB/4vM6tL+z/02/m/LOwr8X3qo2vyfNfi/1FD1+T/q/+3JCv+X+fkA /5e4A/F/iaHwf2+h8H/4P/zfcij8X2pa+L+3rPB/xfyfJ1H4v6isqP+X1f9Nppj/U/g//J/a 6v/cF+ln9n/OvuD/Ynag2ur/3Pma1/+5qwX+Lyor/F9W/3d6/b926iz+D/+H/9se6tr+b3YD 2O3/Xm8i+D+F//tXqJWs8H8bUR7+L6f/k4UmVgYVO/3ffBu1+j/q/6W/bVzyf2bsBu//mm5v KD349YWhU9T/w/9F+T+rc/s/90WF+L+4UPi/Stvd/00Hxojzf533f33zo/B/xzd3luP/4ue9 8X/pWeH/EoYVi/5P+FpO/9d+QP2/VlLIifLsqv/LHupa/q93RyD+b1Mo/N9bVvg//N/X+D/q /+H//G/h/xT+b+sOxP8lhsL/JWSF/0sMdSn/J8tX8X9RofB/+L/fKdVL+b+wLDDJ/4WxNP4v j/9rx/P9Xy8fDP7vD/9n8X9J/k/rifp/kaHO8n/uYD/b/2l/28jq/1yoBf93+4zwf9/i/4yb ycL/LYba6P/83aMy/zf4kWle/9es+b/20e32f+28U+fX/zvA/5kP8H/+K5fxf0s78NL+r3t0 B/s/GTpX5//so9vt/+y8w/8p/N8foVaywv9tRHn4v5z+r/P/aceEceDTNtwP4f8WQmXwf63c 4jP6P92e7f9uT3Jtlf5PJiwq839+JIb/W1qkiv/D/9EWWvB/5khrF+f/eqn/p38U/u/45s5y /F/8vDf+Lz0r/F/CsOJK/q8J6yOyojz8X2KoRf9n3ZsZ/N+mUOf7P7+gKKf/6w3+L0NW+D/8 32tW+L/EUPi/2FCvexD/l2EH4v8SQ1Xm/8yA/8sUCv+H/3veg/i/9FD4v+0H+7X9Xx9GMCX8 X/vo8H/rh+BH+D+Zp8D/4f9m7bvr/636PznFc/q/2Wf1FCq//wtHoHprB9T/a7oL+b/ejSry +j+N/zvK/7l1tvi/xVCb/J9u/C77Tv+nLP7vIP/X4P82+T+L/8P/+Z/H/+H/tobC/+H/1kKt ZIX/+/dj9+n+T66gdhr2h3rahvvJGv2fbfB/WbJ68X+dvQ3HtBu6j3tD3YYMblIqdG6jPf4v S1b4v33+7/dqgf/D/1293f2fPjBGnP+z4v/aH4X/O765sxz/Fz/vjf9Lzwr/lzCsKOX/mg/w fzqsVSnh/5oDQl3J/7m30/i/TaHO938uK/zflncU+L/0UPg//N/bYVGd/2s7/B/+b30H4v8S Q+H/ErLC/yWGwv9FpoX/u3f4P/xf3f5PP7pE/6eHl1Cv/i+8OPWH+V7/97Y+tZD/01Mx/6c1 /i9yB+L/vtX/2R7/FxkK/1fC/03t7YKnu9tFN8H/9f7QC91vVu8fVkH/97S+fq//e191e67/ 0+7czer/tDX4v8isTqv/Zz7B//WPbrf/6+fdB/i/tsvu/8Y1/2eHWXJf5v/8EYj/ixvGNPPu Yv5Pjocy/k/uiUX8X/hOjyT/N9uGUvg/hf/7I9RKVvi/jSgP/5fT/8mZZMeEceDTNtwoF/+3 EOoj/Z8ZzvZ/k1vOqTszdN3eUHoY3UNw6GZZner/5AiszP81Ffq/rmlr9H+tO2yy+j9jRvwf Lbbd/Z85MEac/xvE//U/Cv93fHNnOf4vft4b/5eeFf4vYVhRyP/dBmDn+z+ZF8f/bTgszvZ/ g5sXx/9tCoX/e8sK/4f/+xr/Zw3+LzVUff6P+n97ssL/ZX4+wP8l7kD8X2Io/N9bqG/zf3K9 xf9FhcL/4f9+p1Txf+5/8H9n1f9zqy3wf3H34bfV7Pi/qFP4Av7PrdGvz/91Bv8XebXY5P+6 zoUKndp5BE6y90P3m9X7h4X/+zT/5+7C+L+4rPB/+L/3V8P4P4X/27I+Ff8XtwPxf77D/+H/ lrLC/21Eefi/nP5PrqBp/m++jUeouvxfN+L/smT17P+6drpdH0K3M5Qepmn87Wah8H/4v4Ws 3vzflN3/PW74+D/837Xb3f+1B8aI8H+t//9rrY35Ufi/45s7y/F/8fPe+L/0rPB/CcOKQv5P jx/g/5qwPgL/9+dhgf+LzOrS/s+vO8T/bXhHgf9LD1Wb/6P+H/7P/xb+T+H/tu5A/F9iKPxf Qlb4v8RQ1/J//gfwf1Gh8H/4v98pVfyf+58D/J/MDeH//jgEy9X/8yRq0f+FrPF/f/i/Bv+X 5v8mc379P3n18p3+j/p/qf7PLdlbqP9nR+v9X9/tv9xOUskhdN5qnu7/wqLSuvxf07eZ/d/t r76W//Pv777U/434v6/xf2bN/4UdXMD/DePgP4h8/u+2sRX/J6qxiP/rJesS/i9cxkv4v7Dd yvyfDGuL+D9bzv/NxxZ7r4FP4xOF/1P4vz9CrWSF/9uI8vB/Of3f5C/Hg7cve/3ffBt+3qJC /1dn/b8Zyjup/p/Vg3bzFs24O9TtecqNykJ3+xltz/d/gz8nqvN//kG7Mv+ne/wf/o92ULv7 v+7AGHH+T4v/634U/u/45s5y/F/8vDf+Lz0r/F/CsKKU/zMf4P+68IIG//fnYXG6/3Nfh4j/ 2xQK//eWFf4P/4f/W8wK/5cYqpD/MyP+D/+3vgPxf4mhKvN/fYf/yxQK/5fZ/3V+d+H/okLh /77T/01yDOD/tngK/F/UcXGa/2vH8+v/4f/wf7X5P1XO/1nq/y1c2b/J/3VNP2b3fyP+7xD/ 143ucoz/WwyF/8P/bRkxvfu/WxpNbv/nD3b8X9pnhf9TUaPbrf5veHS7/d/8daO6mP+b1xbe Xf/Pzjv8n8L//RFqJSv830aUh//L5/+0kRuVdPtCPW/jEQr/9/n+7/T6f+3ksnL+r9sd6vY8 5Wb4Quc22uP/smR1Df9ndG7/557wT/Z/1tjc/s+Fwv/RItvd//UHxojzf0b8n/1R+L/jmzvL 8X/x8974v/Ss8H8Jw4oL+b+w9Ab/t+GwwP9FZoX/y+n/ugb/lyEr/B/+7zUr/F9iqEL+r+3w f/i/9R2I/0sMdab/s367Wf3fHOXh//B/L6FO9X+y3Af/FxUK/4f/+51SvZT/CwtT0/xfmE/8 y/+FkWCS/5N0yvu/oa3Q/+n1+n9yYuH//vB/Fv+X5v9sf379vz67/2tr9H/uYK/Q/7lQC/7P tNn93z2r9w+roP8bAtI63v/dR2cF/N/k+E5W/+evgVfyf/5qUcL/+fdOWf3f7bJao//T5lr+ r50l923+zz0ML/q/UR6mSvg/KwPpEv4v3N1L+D/TPLrd/m/+0KNW/d9TqJ0PqOEVdveb1aL/ szKiKuL/5IQq4/+GR7fb/w3zDv+n8H9/hFrJCv+3EeXh/zL6v8bf8LX2E5I7/d/TNtzERI3+ 755VXf6v7072f50ebw++zv/J48Fe/2d+u1moM/3fGJ5M8X9vTyIX8H/mfP+Xv/6fm5HG/9Ei 293/2QNjxPm/1vu/tvlR+L/jmzvL8X/x8974v/Ss8H8Jw4pC/u8e6tT6f+HRCv/3+f5vdEcg /m9TqAr9H/X/8H+rofB/+L+3w6I6/+e+2R7/FxsK/5f5+QD/l7gDS/k/M+D/MoXC/2X2f/J6 Ff8XFQr/h//7nVLF/7n/wf89+T89FfN/7jukz/Z/Vj4Y/N+//V/QV/i/3f7vE+r/4f82+T8X 6mz/Z/yor0D9v3Zwtw3ddbbZf7md5NYTus+o/1en/3MX2Kz+z2h7Jf/XTH7tf23+b8ju/+yl /F9ncvs/dxM52/+NXTn/F0Z+JfxfuLKX8H9yDSxZ/w//h//D/+H/FkKtZIX/24jy8H/5/N/t fu8vx8Ow3/89b8P9JP5vIRT+b7H+nx2H1vu/MFTa6f/0byfPwvi/HFnh//B/j87NB+L/aJHt 7v+GA2PE+b9O/J/5Ufi/45s7y/F/8fPe+L/0rPB/CcOKQv7PfU/r2f7PjOEFTQH/JwNf/N+W Feb4v7irBf4v88GO/0sOhf+LOa/wf78d/g//Jw3/h//D/+H/XkPh/95C4f/wf/i/5VCn+78x vDfF/+31f2EkmOb/wh78y//ZR7fb/72tT8X/RR0W+D/q/y2tIbmA/6P+X6L/a7rr+L+uGZrc /s+vYjrb/4Xlqvi/f/u/2wMa/i8yq8/zf112/9deyv/5HZzX/434v+/3f+GhCP+31//JTQb/ t3ATwf/5Dv+3NdRKVvi/jSgP/5fR/1mZObP+Tr8z1NM2/LwF/u89FP5vsf5fY27DWvzfYqgP 9H/+lov/W1ik+mn+z1j8H+0D2t3/jQfGiPN/vfi/7kfh/45v7izH/8XPe+P/0rPC/yUMK0r5 v+Z8/9fqQBHxf38eFmf7v8m9mcH/bQpVof/rGvxfhqzwf9/g/6zB/6WGqs//mRH/h/9b34H4 v8RQ+L+ErPB/iaHwf5Fp4f/uHf4P/1e1/5PrkHR7/Z8ZnroO/xcZCv+H/1uY1b+C/xvslfzf 1GT3f+OK/5tkrV5rwvr5XXf88E5FJnLce6Xr+D/dZvd/n1D/767xpNvr/6anrkr/dzss8H9x WeH/svo/91md6v/aaRyz+z/q/+H/ZCPNvMP/4f/etqEU/k/h//4ItZIV/m8jysP/ZfR/g0xY SLe3/t98G49Qdfm/weD/smT16v+62yBTd+00mb2h9OCnSEOn8H/H+T9bo/+zbW7/52fOzvV/ rR3xf7QPaHf/Nx0YI87/WfF/9kfh/45v7izH/8XPe+P/0rPC/yUMKwr5P9N9gP9rjkB5y/7v XvUQ//dnKPzfWyj8H/4P/7cWqjL/52ay8H+Joerzf9T/25MV/i/z8wH+L3EH4v8SQ+H/3kLh //B/+L/lUOf7P3mcwv9t8RSL/k9+O9H/BSUWLhdV+r/OFvN/Wpfyf55E4f+isnr2fw3+L83/ PVDeef5PFmPn9H+6P73+X37/55arLPu/4JS+0/+5UEv1/zqb2/+5F3P4v5gdqM7zf+4aeB3/ p/37WvzfwtTPs/+bLuT/uqbJXv/PH+z4v7TPCv+n4h5Qnx56PsH/yRoz/N/CTQT/5zv839ZQ K1nh/zaiPPxfRv9nZUpaur31/+bbeISqy/+1tkb/575M6FT/107T7YZfof8b8H/f4v/67PX/ uvPr/7V99vp/bj4Q/0eLbMH/tUdauzj/N3j/Z4Yfhf87vrmzHP8XP++N/0vPCv+XMKwo5P/0 iP/D/y2GWvZ/brEP/m9TqAr9n+3wfxmywv99gf/T44T/Sw2F/3uPhf/D/+H/VkNV5v/mKA// h/97CYX/S/mw8H/poa7i/6YwaYb/w//N2gH+b2iL+b92PL/+3yBZ4//+8H/U/0v0f+OA/4sM tc3/jV1u/+cO9gv5PxeD+n/LoT7O/7lLelb/d/urL+X/5EDA/71P/Zzm/7Sp0f9Z/B/+z/9o M+/wf/i/t20ohf9T+L8/Qq1khf/biPLwfzn9n1xBpdvr/+bb8CMm/N97KPzfsv9zExb4v8VQ +L/fDv93vv9z3x6I/6NFtrv/0wfGiPJ/uhH/Z34U/u/45s5y/F/8vDf+Lz0r/F/CsOJC/i8s vSnj/44Ihf+LCYX/e3T4P/zfUij8H/7v/cfwf/i/pT2I/8P/4f/wf/g//N/aDlz0fzKGxv9F hcL/4f9+p1Txf+5/DvB/Mjf0nf5PT9fyf5IC/u8P/0f9vzT/p3VXyv9pU87/Ddfyf+FyXJX/ 04PB/yX6Pz2P+F3+7zYiupb/s9LV5f/88ZDV/3U9/i8q1Kv/6zr8X+pnhf9TcQ+o84cehf/D /71s4z3UPK3DQuH/8H9roVaywv/947H7E/xf5//T+kHwXv8330at/u+eFf4vq//rbgPtrkr/ 54c5tfm/3u1g/N/SIlX8H/6PttDu/s8cGCPO/xnxf/2Pwv8d39xZjv+Ln/fG/6Vnhf9LGFaU 8n/mfP/XyusS/N+Gw+Jk/3e7jbcK/7ctFP7vLSv8H/7vW/yfm8nC/yWGwv+9x8L/4f/wf6uh KvN/fYf/yxQK/5fZ/1n/l+L/okLh//B/v1Oq+D/3P/i/J//X2Qr9n1uEg/+Ly4r6f1nr/z12 YE31/wr6vxH/F3m12OT/2nFqcvu/e1bvHxb+L9H/Ob6Tt/5f2+P/IrPC/+H/3l8N4/8U/m/L +lT8X9wOxP/5Dv+H/1vKCv+3EeXh/3L6P7lfWX+n3+v/5ttwP1mj/+tG/F+WrF7q/42DbTP7 P/ddOPi/HFnh//B/j850+D9adLv7v/bAGHH+rxX/N/wo/N/xzZ3l+L/4eW/8X3pW+L+EYUUh /+dedJ/t/8wYXtCU8H9HhML/xYTC/z26Y/2f30RW/9fh//B/a6Eq83/U/8P/Lfi/tsP/4f/W dyD+LzEU/i8hK/xfYij8X2Ra+L97h//7aP83hvem+L+9/q8PYMUv7Njr/56XV5o1/xdGgn6m aK//0/OuoP8b2mL+z5jz6/+Fww3/h/+bte/2f2rN/0k6Of1fO1yq/l/Iuir/Z62h/l+a/5NH kS/1f814Kf/n91YZ/+f2XFb/pxuD/4vL6jT/p5sq/Z/F/+H//GfUzLtV/yefFf5v4SaC//Md /m9rqJWs8H8bUR7+L6f/ky89GbqEUE/bcKPcGv3fXTXi//L6v97eHhFrrP8nn1Vl/s+PA/F/ S4tUn/yf7Sr0f+71C/6PFtnu/q87MEac/+u8/2v1j8L/Hd/cWY7/i5/3xv+lZ4X/SxhWFPJ/ 7ar/M7Kyp0T9v0NQHv4vMdSy/xtbhf/bFqpC/3d7CMH/pWeF//sG/2cN/i81FP7vPRb+D/+H /1sNhf9LyAr/lxgK/xeZFv7v3uH/8H/4PxW1vHLV/82exHb7v9cFvqX8n56K+b9uwv9F7kD8 37f6v3E4v/7fN/u/cASqtzb5tXp6DDJk59IiuVH5byn3fK1C/+eW7C34v9Ytv8zs/wz+D/8n u+apw//h/163oT7A/5l+zO3//MGO/0v7rPB/KuUBFf+H/3vexnuoeVqHhcL/4f/WQq1khf/7 x2P3B/i/SZ49GpMwDnzahqL+H/4vwv+Z4XbMOf/3NA6M9n/jb6f8qin8X46s8H/7/J+b5TzZ /3W2y+3/XCj8Hy2y3f1ff2CMOP/Xi/9rfxT+7/jmznL8X/y8N/4vPSv8X8KwopT/a873f/fh ehH/pw8Ihf+LCYX/e3QH+z+3g6n/t+UdBf4vPVRt/o/6f/g//1v4P4X/27oD8X+JoSrzf6PG /2UKhf/L7P9k1IL/iwqF//tO/xckD/5vi6co5f+aGv1fZ4v5v0dW5/k/WYyN/1uYT3jyfw3+ 72vq/xX0f7PP6ilUef+XuLRIblRyhP2j/l+YTpD9fKT/05PMf2f0f7pd9H9Db3L7v3tW7x9W Of8XFtaX8X9mFurL/J9byXkp/+ff332n/7t9Fsv+zw7uCM3q/4zB/0WF2uz/7pMOBfyfzu7/ 2jX/J6sSyvg/ORmK+D+5thbxf2HGwo9uq/F/sueK+L/wLIz/w//NkzouFP4P/7cS6imp+SNz Nf7PhiVZfnpjb/2/+Tb8OPB0/xcmG3y32/8Ns+4j/J+MoHP6PzeZcK7/G/Tt1un8X5id2+n/ 7G/nNtrj/7Jk9e7//C0X/7ewSLV+/+feHuD/aJHt7v/sgTHi/J8V/9f/KPzf8c2d5fi/+Hlv /F96Vvi/hGHFlfxfF14Z4//+PCzO9n/aHYH4v02h8H9vWeH/8H/4v8Ws8H+JofB/saFe9yD+ L8MOxP8lhqrM/1H/D//3j1D4v5QPC/+XHgr/t/1gx/+pQv4vrEDE//37EHTfIV3G/3kShf+L ygr/h/9bOgJP8n+uphz+7y1UBv9nsvs//QH1/+4lk0v4Pykb+aX+b9SX8n9ytcD/vU/94P+y +j+76v/6WXL1+D95mCrh/8LjYgn/F54FSvi/plz9Pz3OQh3r/2TQV8b/yYdUxP/Jv6f5v9k2 lML/KfzfH6FWssL/bUR5+L+M/m+QFQXS7Qz1tA1Vqf+7i566/N8M5Z3k/+xg+8z+z2h7vv+z 4ck0yf9JjA/yf74SOf5vaZHq3P+5Wc76/J/p8H+06Hb3f8OBMeL83yD+b/hR+L/jmzvL8X/x 8974v/SsTvV/YfCE//u3/3PDimX/F46HEv5P1hXh/zYcFmf7P+PezFTo/4ZZV4//cxvP6v9a g//LkBX+7xv8nzX4v9RQ+L/3WPg//B/+bzVUZf7PDPi/TKHwf/i/5z2I/0sPdRn/FybN8H97 /Z8Nodxe2+3/2nm37v/k39P8X5g/eg2F/8vr/6xkjf/D/83aAf5vHIr5P1Wj/1ut/zd2uf1f 13Rr/i+4FdnPdfi/xo65/V83foL/kxlo/N8f/q/vruT/Gu8t8H8LUz8X9n/tULL+3zjr8H/4 v/DP5fyfaWahjvV/cqPC/y3cRPB/vsP/bQ21khX+byPKw/9l9H+jvDSRbmeop208QtXl/waD /8uS1bP/M9NorPd/vdkbysG/7rdTH+H/Avyrrf4f/u9r/N9gc/s/Fwr/R4tsd/83Hhgjyv+Z Rvyf+VH4v+ObO8vxf/Hz3vi/9KzwfwnDikL+T48f4P+m8HYa//fnYYH/i8wK/4f/2/COAv+X Hqo2/0f9P/yf/y38n8L/bd2B+L/EUJX5P+r/4f/+EQr/l/Jh4f/SQ13F/41yDOD/tniK0/1f GAkm+T9Jp2r/pzX+L3IHnub/LP7va/zfter/4f/WjsAX/9c1S/7PjFOH/8P/4f+2Z4X/y+r/ 3Gd1rv/r/GeV1f+5xQn4v8TPCv+n4h5Qnx568H/4v5dtvIeap3VYKPwf/m8t1EpW+L9/P3af 7f8GuYkMfkJyb/2/+TbcYyP+byEU/m/R/90Gt5P3f/JMtdf/6d9O4f/wf/i/vjPZ/Z/F/9Gi 293/TQfGiPN/Wvxf96Pwf8c3d5bj/+LnvfF/6Vnh/xKGFaX8n1n1fzKcL+D/2kYerfB/X+D/ 3DuKCv1fOMUr839+5hn/t+EdBf4vPRT+D//3dlhU5//cyjb8X2wo/F/m5wP8X+IOxP8lhsL/ vYXC/+H/8H/LofB/qWmd7v/C6hXf7fV/9yGedKZb8X/z1c27/V8/7wr6v2Ys5v/asZj/U6v+ T04s/B/+b9YO8H+PHXgF/zc12f3fuOb//AjTNGGn7VxaFKZYZAeZZs3/yV9Uwv8NbrtZ/Z9a 9H967LL7P/diDv8XswPVVv/nLrB5/Z8ZruT/dOO/leFL/Z+QqP/US7PW36Gy+j+tL1T/7wD/ 5+7Cy/4vvI4cU8bsb89yy/7PXyay+j+F/8P/+c+omXf4v+hrIP5POvzf1lArWeH/NqI8/F9G /2flwjX48fTOUE/beIQ60//J/SrR/8m+CHMKY3e+/5NHvar8321wO2rn/8Zudyg9TG7wEzqF /8P/4f/aPnv9Pzd3i/+jRbbg/7ojrV2c/zPe/5n+R+H/jm/uLMf/xc974//Ss8L/JQwrCvk/ N8V+uv/rwgsa/N+fh8XZ/q91X9yO/9sUCv/3lhX+D//3Nf7PGvxfaqj6/B/1//Zkhf/L/HyA /0vcgaX836jxf5lC4f8y+7/RP4Hh/6JC4f++1P/J7C3+b4unON3/jY9ut/+z8w7/l+b/HEhZ 9H/3dyD4P/zfrOH/Ev1fyfp/+L8U/2cm99dS/2851Mf5P3dJz+r/brc7/F9kVvi/rP5PnV7/ T7cmt//rVuv/4f/wf/i/7/Z/w6Pb7f+GeYf/U/i/P0KtZIX/24jy8H85/Z88X9mx3R/qaRvq I+r/5fd/n1D/r0L/Z0b3ITn/1+wOpYfJDY1Dp/B/+D/8X9s3+D/aB7S7/9MHxojzf634v+FH 4f+Ob+4sx//Fz3vj/9KzOtX/hTXb+L9/+7921f/JC7sS/i8svcH/bTgs8H+RWeH/8H8b3lHg /9JD1eb/qP+H//O/hf9T+L+tOxD/lxiqMv9H/T/83z9Cner/Bn9o4/+iQuH/8H+/U6qX8n/y iJXm/8xj8tx/DjX6P2vwf5Gh3o7ACv1fg//D/yn5/8y7cv6P+n+H+L/bmT16/9eP+4/Ayfpp x9D9ZvX+YdXp/8Id4yv9n3vGv5T/k+nG7/R/tkr/d379v9uDVTn/N8h5VZn/6+VhqoT/Cw8s JfxfGLMU8H8qDNZL+D95GVSb/5PlMdT/U/i/eVLHhcL/4f9WQj0lNX9krsf/yTAmvHTc6f/m 2/DjwAr931014v+y+r/bJ9WPzv9Z2d07/Z/7kELnfwj/lyWrN//nvx4E/7e0SBX/h/+jLbS7 /zMHxojzf533f63+Ufi/45s7y/F/8fPe+L/0rPB/CcOKC/m/tpXZU/zfF/g/9z1D+L9NofB/ b1nh//B/+L/FrPB/iaEK+b/O4v/wf+s7EP+XGAr/l5AV/i8xFP4vMi38373D/+H/8H/qj+WV G/3ffeGH39KX+b+r1f+Tf8f/4f9mLb//ux1opfyfNjX6v1CBUr21/P6vtef7P+PH6SX83+1w yO3/rlb/byrl//rGnUR5/Z8Z8H+RWeH/svo/dX79P/zfRv9n8X/4P/8hNPMO/xd9DcT/SYf/ 2xpqJSv830aUh//L6P8GGUgMKePAp22oSuv/fYT/Gx/dbv83zLvz/d/tmDPe/7VmbygH/7rf TlH/D/+H/zvC/xn8Hy263f1fe2CMOP/Xi/9rfxT+7/jmznL8X/y8N/4vPatz/V9YH4H/e320 evZ/zar/k2OuhP/rwgsa/N+fh8XZ/q9zRyD+b1Oo8/2f+3f835Z3FPi/9FD4P/zf22FRn/9r 8H/4v/UdiP9LDIX/S8gK/5cYCv8XmRb+797h//B/Vfs/m8P/PZYW+s+hRv/X9lfyf2E5C/5v YT7hyf9Z/F9a/b9xOL/+n8X/bfF/n1D/r5z/u13Rc/s/053v/3QzR3nV+D/HbPB/i6E2+T9Z qPyt/k+t+j/371n9n+rxf1GhXv2fWfN/4bOszf/JoVfC/4VBRRH/J3f3Av5Ph7nuEv7PNLNQ h/q/Xk7hIv5PrrNF/F9AEEn+b74NpfB/Cv/3R6iVrPB/G1Ee/i+j/7NSCE66vfX/5tt4hPoE /2f2h/r1f5LVYPB/WbJ6rf9np8b7vzBU2un/9G+nPsT/tdJV5v/8LRf/t7BI9cn/jfg//B/N t7v/6w6MEef/rPi//kfh/45v7izH/8XPe+P/0rPC/yUMKwr5P/eaccX/iRQq4f90dv/X4v+O 8X+9ezOD/9sUqkL/51Z14P+Ss8L/fYP/swb/lxoK//ceC/+H/8P/rYaqzP/ZHv+XKRT+L7P/ kzUP+L+oUPi/L/V/sjwP/7fFUyz6v7CsWbDIXv8XJhLC5cKs+b/x0X2d/7OmmP/T+gP8X1hb jv97m0/A/+H/Fo5A/F9d/q+1psb6f/i/laxe/J/7pjj8X1xW+L+s/k+bCv2fMd2K/wv3msr8 331JhvxFx/q/drYDD/Z/kkJl/k/PSw3W4//kvCvi/8IJleT/ZttQCv+n8H9/hFrJCv+3EeXh /zL6v0GGStLtrf8338YjFP4P/7eQ1Yv/u40jOuf/+snsDaWHyc16h07h//B/+L+263L7Pzd3 i/+jRba7/+sPjBHn/wbxf8OPwv8d39xZjv+Ln/fG/6Vnda7/C69z8X+vj1ZP/k+P5/s/Y8Pb 6awoD/+XGAr/9xbq8v6P+n/4v9VQlfk/N5OF/0sMVZ//azv8H/5vfQfi/xJD4f8SssL/JYa6 lP+Tpzj8X1Qo/B/+73dKFf/n/gf/d+H6f3fsh//D/83aAf7vsQOP9n/+YMf/RYW6sP+zzZjb /92zev+wSvq/cdbh/9b8321EdCX/p5vJd9/p/2yV/k/VWP9PN/g//J//0Wberfo/0zw6/N/T YdE+dZ/g/2YWIrH+H/4P/7cx1EpW+L+NKA//l9H/WbmChpeOO+v/zbfhhhD4v4VQH+n/zHC2 /+vHbvD+T95V7/V/w2+n/Hfh4P9yZIX/2+n/DP4P/0fz7e7/7IExovxf24j/Mz8K/3d8c2c5 /i9+3hv/l54V/i9hWHEh/9fKesoi/q8fDgh1Jf/nXhzg/zaFwv+9ZYX/w/99i/+j/h/+b8H/ Uf9vT1b4v8zPB/i/xB1Yyv+1I/4vUyj8H/7veQ/i/9JD4f+2H+zX9n9hnUea/wsXgL/8X/uI uNv/hdIoNfs/23+A/zMha/lp/N+y/+sM/i/N/31C/T959VKl/9OTkTM5zf+Ze6jr+L++y+7/ PqH+n5rkgof/+8P/mQH/F5nV5/m/3mWV1/8Z/F9UqA/0f8OQ3f+11/J/h6xPvZL/k6sJ/u8v T4H/U/i/P0KtZIX/24jy8H9Z/Z//z0En+b/ZNtwot0b/N3bn+78wEZDR/+n2bP/XDZPU/wuz czv9n/3t1IfU/5PhWGX+zz+g4v8WHruvUP+vwf/Rotvd/w0Hxojzf1r8X/ej8H/HN3eW4//i 573xf+lZnev/jlhKXKH/Mx/g/3R4QYP/+/OwwP9FZnVl/+eXo2X1f+5bnfF/yVnh/77B/40T /i81VH3+j/p/e7LC/2V+PsD/Je7AUv5Pa/xfplD4P/zf8x7E/6WHwv9tP9jxf0rh/xZWcj75 P2uK+b/b6KKQ//MkatH/BbOB//u3/6P+H/7vXP/nVsYU8n+V1v9zX9m/VP9vMrn9n7ta4P9i dqA6z//1Hf4vMiv8X1b/pw3+b2EH4v/wfz5sxAPq00MP/g//97KN91DztA4Lhf/D/62FWskK //fvx+7T/Z9cxtP833wb7idr9H+2qdH/zVDeSf7Ptrcbfl7/d3uCx/9lyeoa/q/rs/u/Ouv/ 4f9o8e3u/8YDY8T5PyP+z/4o/N/xzZ3l+L/4eW/8X3pW+L+EYUUh/+cerU73f105/9dNB4S6 kP+zplX4v22h8H9vWeH/8H/f4v/cN1nh/xJD1ef/qP+3Jyv8X+bnA/xf4g4s5f9G/F/yXQT/ l7wDC/k/M+D/UkPh/xJD4f9iQ23zf2H9qp88S/V/5iXUi/8LKxA7WVu+0/+9flgV1v9rx/Pr /4WLK/4P/zdrB/i/xw48z//12f1fW87/Gfxf5NVim/8bTHb/9wn1/+4arzL/50YTWf2fW/N4 Kf/nd9mX+j+F//sa/2dX/Z8c7N/p/9Sq/5MnkRL+rx9nO/BY/ycXvyL+L9wHi/g/Owt1rP9r ZZ+U8H9yaSjj/+Tf0/zfbBtK4f8U/u+PUCtZ4f82ojz8X07/J+NEO+n9oZ62oSr1f4Op0f/1 3en+z02ZVVj/T0ZMods7+W3m3Sf4Pz+pjv9beOzG/+H/aEvt7v+mA2PE+b/O+79O/yj83/HN neX4v/h5b/xfelb4v4RhRan6f+MH+L8wXC/i//oDQl3J/7lVdPi/TaEq9H8K/4f/WwtVmf9z qzrwf4mhTvd/Y27/59bB4v9iQ+H/Mj8f4P8SdyD+LzEU/u8t1Lf5P9lwTv+nW/xfaij8X2Io /F9sqI/zfzLaxP/9lVU5/6fW6/+FteVV+T/b5/Z/2uD/vr/+XxvmQ7/R/+mV+n/a+nJAt62H W+SuO/7QzjtVpf9zod78n5p0O2b3f+Za/s8O84jf5f/cXfhC/q/x19n6/J/bbl7/p1f83/w9 w94l5k/vKm5/UIX+T3X4v+/3fwXr/xX0f2Ye6lD/Z2XPFfF/cmRT/0/h/+ZJHRcK/4f/Wwn1 lNT8kbkW/3e7JXaPbl+o5208Qp3o/4wMOdsmYe2ylhF06G4Pxfi/LFk9+T81TtPQuS9oGG23 N5QeRjeWDJ3C/x3n/yb83xb/Z7rz/d+Q3f+5UPg/WmQL/q8/0trF+b9e6v+ZH4X/O765sxz/ Fz/vjf9Lzwr/lzCsuJD/M2N4QZMP5Vn8H/5Pfvupu5b/80sx8H9b3lHg/9JD1eb/xgn/lxqq Pv/X4f/wf/i/l1D4vzX/Zwb8X6ZQ+L/M/s+XPMD/xYXC/+H/fp+Gr+X/wggmxf+FyfOq/Z81 xfyf1sv+r+2z1/8bV/xfuPTj/xbmE+b+r8P/fX/9v3aU28dX+r9/1P9zWZsm7LR9d3zbzzpX vu5s/6cnd1AdX//PmT2b2//ds3r/sMr5PzXNUV4t/k+7zzKv/7sdFpfyf/6+W8L/9Q3+D//3 7v+6OV871P+NbUH/Jw9TJfxfN8x24LH+L4xZSvi/Joxf/Oj24Pp/4yzUsf5PblRl6v/JCmrq /+H/5kkdFwr/h/9bCfWU1PyRuRr/N/h7Yuh2+r+nbbgfqtH/dWON/s9NJpzq/6bb41Xr/F/T 7Q6lh8ENa0On5MvvzvZ/8oRTm/+TdZyV+b+2ze3/3NTj2f5vGvF/tA9od/+nD4wR5/+s+L/u R+H/jm/uLMf/xc974//Ss8L/JQwrSvk/8wH+T745hPp/Gw6Ls/3f4I5A/N+mUBX6P23wfxmy wv/h/16zwv8lhsL/xYZ63YP4vww7EP+XGAr/l5AV/i8xFP4vMi38373D/+H/ruD/erdvEv2f nl5Cvfo/+VO+0/8VrP/3Cf4vrMbC/+H/Zq3O+n/tENaY5PN/ui/m/1bq/6nRuKzxf++htvg/ rYexE//XJ/m/4dHJKib8X9xh8fbCu4z/c+Af/xeX1cb6f0N2/9fW6f+ak/1fO3VNbv/np9oX /Z8Uqq3N/8mYvYj/e9qBB/s/uTQU8X/hEd+Pbg/2f3YW6lD/18spXMT/ydiD+n8K/zdP6rhQ +D/830qop6Tmj8zV+L/JP3aHbqf/e9rGI1Rd/s82+L8sWT35P637yejbQEm3YXZul/+zbkos dIr6f8f5P/9AUJv/M7pC/9dpi/+jfUC7+z9zYIw4/zeI/7M/Cv93fHNnOf4vft4b/5eeFf4v YVhxJf+Xv/4f/u8g/ze6KXb836ZQp/s/P6FE/b8t7yjwf+mh8H/4v7fDAv/3Fgv/h//D/62G wv8lZIX/SwyF/4tM69n/uVs+/i8tFP4vMRT+LzbUNv/XhWWs+L/XUJf2f2HlHP4P/zdr+D/8 38n+b5T578Pr/43d7dx2/q+zSf5PP7rL+T+5X+H/Nsydne///N0D//c+9YP/w/8tjZg2+j9Z 5lPE/zWzHXis/wtLpAr4PzXd17Qodbj/m5caxP/h/44Ohf/D/62FWskK//ePx+7z/Z/p/DEX un2hnrfxCFWX/5ss/i9LVs/1/0bjHuV0OzW22xtKD617sRI6hf/D/8X4v3aq0v8N+D/aJ7S7 /2sPjBHl/7pG/J/+Ufi/45s7y/F/8fPe+L/0rPB/CcOKQv7Pveg+3f+VrP/XHRAK/xcTCv/3 6A71fzIDg//b8o4C/5ceCv+H/3s7LPB/b7Hwf/g//N9qqFP9n19YhP/bEgr/9xYK/4f/w/8t h8L/paZ1vv8L4/Uk/xfG0n/4v4DJ0vyfzC/h/472f0PIWn4a/4f/U/i/fx3s+L8i/s/PKRXw f7az4v+aLsX/efQSOvzfjsst/g//t3AKb/V/7g/N6/8a/F9UKPyfUvi/LetT8X9xOxD/5zv8 H/5vKSv830aUh//L6P8mv4nQ7fR/T9t4hDrT/4U5xynF/4WZ1DCviv9Lf9u44P+sHm/PX7fn YWO6vaG0Hdz4JHQK/4f/i/J/bY3+r9cj/o/2Ae3u/7oDY8T5Py3+r/1R+L/jmzvL8X/x8974 v/Ss8H8Jw4or+T+D/8P/4f8SroH4v8hQ+L97V4v/C8tR0/xfeO+F/6vG//k3mvi/TXsQ/5dh B+L/EkOd6v/8NDT+b0so/N9bqG/zf53fXfi/qFD4P/zf79Mw/s/9z1f7P/nPRP8n++kv/6fn UxfH+j/57TL+rwtZy09X4v88icL/La0h2eb/dBgsFfB/csEr4v9kBxbxf/5SWcb/+X+vz/+5 3y7g//qusc7/tV3CirOp90ApdJ/h/0Y53Er4v3C4pfm/8ELp8cJ70f+5FPB/i6G2+b/RfZZl /J+7+BXyf/6zKuT/5N/T/N9sG/JZnez/Wpd1If8X1q+m+b/wevk3q2X/J2Vsyvg/GZyV8H9C Dcv4P7m2FvF/chUq4f+aaRZq5wNqO3+aUev+T1BSCf8ng/Uy/k/SSfN/s20ohf9T+L8/Qq1k hf/biPLwf/n8X6v9c0Ho9oV63sYj1Jn+T4Y5if4vPAd+jv8Lz9s1+b/e36H0bTQhI899/k/7 YYJ06jP8X+P/uzb/50fQlfk/Y92RVZ3/a/tW4f9op7e7/+sPjBHn/4z4v/5H4f+Ob+4sx//F z3vj/9Kzwv8lDCsK+T83WDrd/zXyjrWE/2uPCHUl/+e+eRH/tynU6f7P7xj835Z3FPi/9FDn +j+ZKmzDm7g0/ydHGP7v+/1fr3P7v9sgDP+H/1vdgfi/xFCn+j9/zGX1f7rF/2UKhf/L7P/k Qov/iwqF/8P//T4NX8r/zVHebv/XvuzBFf8nP+bHnrv939v61EX/FxZ8y5xqov+Tz3jN/6lw J8zo/1S/7P9M+ArkfP5Pjd2K/5P1PrX5P3mzg/9bWEOyyf+1U6j/53fNXv/XzLpV/9fKpT2n /2vX/J8JOiuf/1PDsv8bJlnZV8D/Df7CVJ3/6+X77w73f91g9HDbx/d74k7/54cJobuc/wuX qfCok+b/ft8rLfq/xn1/QV7/p8dr+T+Zbizh/9ysfl7/p3v8X1xWW/2fG3Li/5ZC4f/wf0un MP4P/7c1FP4P/7cWaiUr/N+/HrvP93+dv9yGbqf/e9qGG+V+gP+TFdlp/k8GIx/k/+SGX5X/ 625HjfN/bTft939956Y3Q6fwf/i/GP+nJ/ckUp3/s/g/2ie0u/+zB8aI83+t+L/hR+H/jm/u LMf/xc974//Ss8L/JQwrruT/2vBd1fi/Pw8L/F9kVvg//N+GdxT4v/RQJ/s/uYlk9H9Di/9L DXW6//PTtjn9n+lG/B/+b3UH4v8SQ53p/3r/IqQzcjXa6//6WafmKA//h/97CXWq/5MaR/i/ qFD4P/zf79Mw/s/9z1f7P/EWOf1fM674v/CQk9P/NSv+z2jZfymXi+elsGbV/8lrkcr8nxwW Gf1f21zL/8kJldP/PYryvfg/K8CyhP+7S7oC/s/rq5z+LxyB6q1JqJz+7/bpn+//Rg8oc/o/ F2qh/l8/Da7+n7Yp/q/z7iN0txPwfP+nhcgV8X/yjFPE/zm+k9X/3S7w+L/IrLb6v16V8n9+ pWch/zc9ut3+b5p3H+D/jLvclvJ/cl4V8H+Dj1HI/8n4pYj/G2Y78GD/J5eGIv4vXPz86PZg /zfMQh3r/2ToXML/hVm8Iv5vkOST/N98G0rh/xT+749QK1nh/zaiPPxfRv/XetnddmZ/qOdt +CmS0/2foL1E/xcG/HKB1+Z8/yfvynL6vxnKO6n+n5l67e7wdjB7Q90+on767dRH+D//JFKf //OzCLX5P/81yVn9X2ub0/3fYN05kdX/WfwfLbrd/d9wYIw4/9d5/9fpH4X/O765sxz/Fz/v jf9Lzwr/lzCsKOX/zJr/k+edIv5P1gQV8X/y7gP/t2WF+ZL/m9xhgf/bFGrF/w0HhCrl/7TB /2XICv/3Df6vs/i/1FD4v/dY+D/8H/5vNdSp9f/8Agj835ZQ+L+3UN/m/+SdAf4vKhT+D//3 O6V6Kf8nQ8BE//e6B1f8XxgJJvk/Sae4/7tdr8/3f7/vwv1/5fB/Dyn34v9kkQ7+b2E+4cn/ Wfzf1/g/VdD/NcX8ny3m/4xd83/36QTZz0f6P+Pnfgr4v8F02vu/ttl/uZ1kCWfo3E9eyf+F GPdup/97e+G96P/cJT2v/3On8HX8X0AvJfxf32T3f0Ki/lMvzdoR//c1/i+YG+kS/d/vYXG6 /5NCb0X83yAXphL+L5yvBfyfbsIjvr8+Hev/dIb6f+EV9h/+z5oq/d84Pbrd9f+meYf/U/i/ P0KtZIX/24jy8H8Z/Z/p/aVBnhp3+r+nbbifPN//yZjF+A8p1f+F1af4vyP8n536sb3d4Yex 2R1Kd4Mb8IduFgr/l9n/DU2N/s9Muf2fe2qsz/+5+UD8Hy2y3f3feGCMOP/Xi/9rfxT+7/jm znL8X/y8N/4vPSv8X8KwopD/c6+ET/d/9z8F//fnYXG6/3Or6PB/m0Kd7v+0rH/I6P+6Ef+X ISv83zf4P+r/4f/8b+H/FP5v6w7E/yWGqsz/mQH/lykU/i+z/5MHb/xfVCj8H/7vd0oV/+f+ 5wD/Zx/dt9X/U5NZ9n86rLz+Tv9n1/xfuD3h//B/s1bQ/3WmnP+TsRL+7z3Uxvp/Bf2fddvN 6v+c7H73f5MZxf81CZfbqfNXnNDJt5hfyP/JTeZ+49jp/16nfhb9n3bFw7L6v9tffSn/598r fav/syv+b+i+2f9pU6H/0+v+T47Q2vyfHHq1+T/ZbhH/J1ehIv5vmIU61v/J8VDG/8njfAn/ J7Uapdt7DZxvQyn8n8L//RFqJSv830aUh//L6P8aP2HRan+B3+n/nrbhF2id7v/kvU5O/3ev 6IX/y+r/xmlsnf+zo+32hrp9RG6cFTpF/T/8X5T/80+m+L+lUE/+z3T4P1p0u/u/6cAYcf7P iv/rfxT+7/jmznL8X/y8N/4vPSv8X8KwopD/c8OKZf8XjocC/q+9v53Oh/LaVf835A51Kf9n /BtP/N+mUCv+rz0g1Ir/88dcTv/XWvxfhqzwf9/g/9oG/5caCv/3Hgv/h//D/62Gqsz/Ker/ Jd9F8H/JOxD/lysU/u87/V+QPPi/LZ4C/xd1XDz7P9sX839mwP9F7sDT/F/X4f/iPqvP83+d rCnC/72H2uj/wvH4nf6v7xb8n276wfu/Zhz3X24nGX+H7naE4f++xf+5wwL/F5cV/i+r/1M1 1v9z96uz/d/oF9aX8X+jDM5K+L/wPrcy/xcu4/g//B/+D/+3EGolK/zfRpSH/8vn/4z190Fj /Z1+X6jnbdTq/6j/l/628d3/6aZ1U2a3Z4Mwgt7n/3o3+AndLNSZ/m+SCVf8H/7vHP/Xj7n9 n5sPxP/RIlvwf/ZIaxfn/wbv/1r7o/B/xzd3luP/4ue98X/pWeH/EoYVhfyfHtf8n2y3SP0/ 0XhF/F/X5g6F/8P/LYc63//5BSQ5/d9g8H8ZssL/fYP/Gzv8X2qo+vxf2+D/8H/rOxD/lxgK /5eQFf4vMRT+LzIt/N+9w//h//B/6t+T0vi/6vyfrLbA/y3MJ8z9X9fg/w7yf2N2/2fX/J+s SMP/vYd69n9m1f+Fga3s5yr8n56aSfyf3X8ETq1fxh66j/B/YWF9bf7PjSby+r/bXfhK/q+R 6Ub8317/N4c/e5eYv+Ghk/3faJrc/s9dA5f9n/x2bf5v8B9MdfX/5OZUpP7f9Ih4tP8zs1DH +j/ZgWX8n9wT8X/4v3lSx4XC/+H/VkI9JTV/ZK7F/+kpPHb7h559oZ63Uav/o/5f+tvGBf+n 7XQbI91u5jah/l/fjO1vpz6j/t8UJm1SQn2c/7P+Ua42/2fa3P5vdsM/y/91E/6P9gnt7v/0 gTGi/F/fiP/TPwr/d3xzZzn+L37eG/+XnhX+L2FYUcr/mTX/JydREf+n5UVSXpS34v/MAaEu 5P+0ezOD/9sUasX/HYFEVvxfr/B/y6Hwf/cO/4f/W/gx/N+K/6P+356s8H+Znw/wf4k7sJT/ MwP+L1Mo/B/+73kP4v/SQ13F/43hG/vxf7v930y57fZ/dt6t+z/5z+/0f5Mp5v8eWR3t/9xM 8Ur9P0kB//dv/0f9v1T/99iB+L9d/q/5AP8XPrqa/J+xfZvb/zmrebb/uw+b8X/4vyf/N/ju O/3f7SZSof/T5mz/NwzZ6//9w//dX0fKf+was3+e/5MjtIj/68NK9Pm674P8n9w6y/g/GUiU 8H9BNZbwf3IKF/F/crjh/xT+b57UcaHwf/i/lVBPSc0fmavxfyZswnc7/d/TNh6h8H+5/Z98 t0BO/6fbk/2f6Tvd3rphGuzeULqf3Pe/hU59hP8L8A//t/Ak8mH+z+gq/Z/u8H+0D2h3/2cO jBHn/7T4v/ZH4f+Ob+4sx//Fz3vj/9Kzwv8lDCsK+T/3aHW6/5PXJfi/DYcF/i8yq0v7P7/u MKf/60b8X4as8H/f4P/6Af+XGqo+/0f9vz1Z4f8yPx/g/xJ3IPX/EkPh/95C4f/wf/i/5VD4 v9S08H9vWV3e/5Wr/4f/o/7fyf5v1Pi/yFCn1f9z3xS37P8Cw5H9XIX/a9tJ5/Z/7nJ7Jf8X 3q0X8H/GfZZZ/Z8ep2v5v9533+n/FPX/DvJ/Bv+3yf9Z/B/+z39Gr6dwKf9n8X/4vz9CzZM6 LhT+D/+3EuopqfkjczX+r/VvQEK30/89beMRqi7/N3b4vyxZPfu/9jaOmNwAzbRmbyhtB1e2 OnSzUPg//N9CVq/+z9PTvP7PNhX6P9Ph/2jR7e7/2gNjxPk/I/6v/1H4v+ObO8vxf/Hz3vi/ 9KzwfwnDikL+z02xL/u/1h/ZRfyfaLycKM+u+j+dO9TF/J97p47/2xRqxf8dcQ1c8X9GZfZ/ rcX/ZcgK/4f/e80K/5cYivp/saFe9yD+L8MOxP8lhsL/JWSF/0sMdS3/5/9S/F9UKPzfl/q/ gBvwf3v9X3i/6ru9/s8M8661K/6vM49ut/97/bAq9H+PrJ6XtrX3ic6Uy8XzUli75v/CUyL+ 79/+j/p/qf6vL1f/T53v/6Ymt/9zL3sW/d/oOYDpdMJ7pXAZCOCkM82a/wsDW9nPVfg/M3TU /7uw//MXpgv5P0Ev+L/3qZ+t/m82ut3t/8y8O93/dXrK7v/8wX4h/9fLMp8i/k/+vYj/k7t7 Zf4vLPzC/+H/8H/4v5fDAv+H/3vP6tX/jX4kFrqd/u9pG49Q+D/830JWr/X/+tH5v8EO+/3f YNyeCZ275hj8X5asLuH/2qHP7f/cLOfZ/s8vO8tb/8/g/2jR7e7/ugNjxPm/Vvzf8KPwf8c3 d5bj/+LnvfF/6Vnh/xKGFaX8n1n1f/J67Dvr/+H/DvJ/xrQK/7ctVIX+z3T4vwxZ4f++wf+1 Df4vNRT+7z0W/g//h/9bDYX/S8gK/5cY6lL+Ty7tOf2fGfB/qaHwf4mhVvyfzN7i/7Z4itP9 X//odvu/ft7h/xLr/41r/k8W1uP/FuYT8H85/d9tcHGh+n9jl9v/rdb/y+//XKhl/xey/k7/ 50It1f9rh9z+z69iOtn/qbAitSr/101uB+f1f+7CdCH/5xc9fKv/syv+b2wK+r/u0e32f928 0+Zs/3cbRxf0f3KE1ub/5EmkiP+TrEv4v3C4lfB/4T5Ywv+Zeaha/J+WGj5F/N8o97Mk/zff hlL4P4X/+yPUSlb4v40oD/+X0f9NHiiFbqf/e9rGI1Rd/u9e0Qv/l9X/3e5Q0+D8X5fi/7S7 xoTu9jPa4v+yZHUN/2en7P7P1Oj/3IQq/o8W2e7+rz8wRpz/67z/6/SPwv8d39xZjv+Ln/fG /6Vnhf9LGFYU8n9uWLHi/+TxuoT/8190mxvl4f8SQy37v7FV+L9toc73f43C/y2Hwv/dO/zf mv+j/h/+z/8W/k/h/7buQPxfYqgz/d/gr7D4vy2h8H9vofB/WuP/UkPh/xJDrfg/WZ6H/9vi KQr5P9PV6P9sX8z/maGY/zNr/q+Xiyv+D/83a/i/j/N/bmXM+f5Pzonv9H/L9f/avumr9H9h hF6V/+tvlz3838bzatn/+acp/N/C1M+V/Z+2Vfo/f2nI6v/Uqv+TJRdF/J9cLYr4v/A2LeVJ ZGv9v3lRvmrq/8mfktP/tR/g/6j/h//D/+H/VkM9JTV/ZK7H/8nNcBr3XwOft/EIVZf/0+YD /J88RWT0f8qe7f/MNIr/C0Olff7PPUGHTn2G/wsLivF/V/R/rW0q9H+mw//Rotvd/9kDY8T5 v178X/uj8H/HN3eW4//i573xf+lZ4f8ShhWl/F+z5v/k1VYR/9eFFzT4vz8Pi7P9X+sOC/zf plAV+r9uxP9lyAr/h/97zQr/lxiqkP9rG/wf/m99B+L/EkNV5v9Gjf/LFAr/9/H+z93y8X9p ofB/iaHwf7GhzvJ/2qz5vxmo2+3/7Lwr6P8K1v/D/32N/+sa/B/+T8n/Z9bZGuv/OWq44v/C dILs5zr8X9tN2f2f+QT/JzPQJfxfuGOU8H9uNJHX/7lrIP4vKquz/J82Vfo/91nh/+IG0vi/ Iv5P0ini/0zz6Oqp/1ep/2sf3W7/1847/J/C//0RaiUr/N9GlIf/y+n/fP1S0/iHnr3+b74N N8qt0f/ds8L/ZfZ/7rPS7dB23d5QetDuyhk65d934/9yZIX/2+f/6qz/p0f8Hy263f3fcGCM OP9nxf/1Pwr/d3xzZzn+L37eG/+XnhX+L2FYUcj/ua8VWPF/8nqshP/rw9vpAv6v7Q8Ihf+L CYX/e3TH+j9vX/B/W95R4P/SQ9Xm/+yI/0sNVZ//o/7fnqzwf5mfD/B/iTuwlP/rO/xfplD4 P/zf8x7E/6WHuoz/C+t/8X97/Z98w28Z/ycjwTT/F+r/Ffd/V6v/N6cb+L81/0f9v1T/13fn +z+d3f+1F6v/Fyq7hqXbVfi/2wNjjfX/AvyrzP8Zd77i/xZDbfR/fpfh/96nfrb6v/7R7fZ/ /bzD/x3l/wa/iZz+z+L/8H/+M2rmHf4v+hqI/5MO/7c11EpW+L+NKA//l9H/ycBF23HaHep5 G36BFv7vPRT+b9n/dbfRrfN/YSJwp/8bfjtF/T/838n+r876fy4r/B8tst3933hgjDj/N4j/ G34U/u/45s5y/F/8vDf+Lz0r/F/CsKKQ/3NfK7Ds/1qZCizh/2Q2E/+34bA42/917s0M/m9T qPP9nz/mcvo/0+H/MmSF/8P/vWaF/0sMhf+LDfW6B/F/GXYg/i8xVGX+zwz4v0yh8H+Z/Z9f II3/iwuF/8P//U6p4v/c/+D/tvk/2XhO//fI6jz/Jws/8H8L8wlz/3ex+n9deGDM6P9GXcr/ aYP/S/J//6j/J39RVf7PNH1u/+e+mBP/F7MD1Vb/587dvP7PwWT8X1RWZ/k/ZfF/x/g/Y/B/ W/yfF6j4v7hhTDPv8H81+L/Z6ubd/m++Qlrh/xT+749QK1nh/zaiPPxfRv/X++dt3fsJtJ3+ 72kbfnSL/3sPhf9b9H/NOPj6f31S/T/H70Pnfwj/lyUr/N8+//cJ9f+6Lrf/66j/R4tvd/83 HRgjyv/ZRvyf+VH4v+ObO8vxf/Hz3vi/9KzwfwnDikL+zz0wLvs/Iyt7Cvi/+6NVEf93RCj8 X0wo/N+jO9j/+QUkOf2fe3mK/0vOCv/3Df6v0/i/1FD4v/dY+D/8H/5vNRT+LyEr/F9iKPxf ZFr4v3uH/8P/1e3/5N+L+D8J9Z3+bzLF/N8n1P+zYW05/u9tPgH/l9H/6Wak/l9kqKerRWv/ 7f9aE4BCkv/7/brqCv3fqBf935C//p9fyXmy/1OTXPDwf/i/uf/zayLxfwtTPxf2f41frJ3V /90ubiv+L6xf/Ur/p1br/3Wir0r4v/CkUsL/hXO3hP/Td2CpVD3+r598Hjn9n+7X/J88zuP/ 8H/zpI4Lhf/D/62Eekpq/shcjf9rJnlv3yX4v6dtuJ+s0f/dszrR/xmZCMzq/9qz/Z91Cx+c /0uq/+c+6NDNQuH/cvs//xng/5YWqc793yfU/2sM/o/2AS34v+FIaxfn/7T3f237o/B/xzd3 luP/4ue98X/pWeH/EoYVhfyf+7KEFf8nr8dK+D+ZbsT/bTgsTvd/7p06/m9TqPP9X6/wf8uh 8H/3Dv+35v96g/9LDYX/e4+F/8P/4f9WQ1Xm//oO/5cpFP4P//e8B/F/6aHwf9sP9mv7vzBr lub/woqOv/zf7PL3df6vYP0/V5DqbP834f+2+L+2w/99Tf2/h9V8uS7l93+qRv9Xaf2/Ff/X dzq7/1P4P/yfb/i/jP5Pm3L+z5bzf7eBdH3+r+tW/Z+cV7X5P7l7FPF/IR3/Ywf7P7m7F/F/ YcbCj26P9X9P1PBY/+ePwDL+rytY/0/SSfN/s20ohf9T+L8/Qq1khf/biPLwf/n83210JLK7 2e//nrfhbujn+z/5dPB/76E+zf/1zTDdurFrdofSQ+t+OXR+o/i/LFnh/77W/7XW4v9oH9Du /k8fGCPO/xnxf/2Pwv8d39xZjv+Ln/fG/6Vnhf9LGFYU8n/tav2/Q86rRf8XZjPxfxsOi7P9 X+/KQuL/NoU63//J+gf8H/7vqT39GP4P/7fwY/g//J80/B/+D/+H/3sNhf97C4X/w//h/5ZD 4f9S0zrd//Uy8e3v9bv93/PySvuH/+v9ltL832N1YH3+7xPq/8lyFvzfwnzC3P9R/y/R/7ml RaXq/3Vr/m/A/+H/Xv2ftdn9n1vvc77/kyFTXf6vdR9MXv/nTuEr+b9Gum/0f6pg/T/832H1 /+S8wv/h//B/+D/8H/4P/3d0KPxfZv9n5XHe2nZ/qKdt+HFghf6vG/F/WbJ69X9jr73/k8eD vf7P/Ha3n9EW/5clqzf/51e44f+WFqk++b/mfP/X61Zl9n9dh/+jxba7/zMHxojzf533f13z o/B/xzd3luP/4ue98X/pWeH/EoYVpfxfs+r/ZGVPifp/sl3834bD4nT/N7YK/7ct1Pn+zyj8 33Io/N+9w/+t+b9hwv+lhsL/vcfC/+H/8H+roSrzf2bA/2UKhf/D/z3vQfxfeij83/aD/eL+ T9JO838y6fNYXrns/9oAvb7S/03mWv4vrC3H/73NJ1D/L6f/a8Zi/u+R1fN16QD/Z4v5P4fy 8H9vodL932Bve053tx2X4P86/y45dPi/HZfbjf7PXZjy+j9XmBT/F5XVtf3fbLi42/89DTnr 9H9m1f/JZ1mZ/5PvVyni/+S3y/g/uTSU8H/NHOUd6/9MMwt1rP+TPZfT/7kb/qL/k3O3iP8b Z6ub914D59tQCv+n8H9/hFrJCv+3EeXh/3L6v2F6dHv933wbj1D4P/zfQlYv/s+6LyxyA6Vu dyg9WP+MJp36EP8XJm2SJr8/zv/5Vye1+b+hz+3/Zjf8ivyf+y4c/B8tst39X3tgjDj/14v/ Mz8K/3d8c2c5/i9+3hv/l54V/i9hWFHI/5luzf/JC7si/u/+7bT5UJ5d9X86dyj8H/5vOdT5 /q9R+L/lUPi/e4f/W/N/1P/D//nfevJ/bYP/w/+t70D8X2Koyvwf9f/wf/8Idar/C48E+D/8 32oo/B/+L7QQI83/yTb+8n/z6ib4v/VD8BP8n8X/4f8K+D/PbAr5P1uj/1ut/zf5qQ0Tvh0x 0f/5bXyE//MvZ7P6v3ZY9H966PB/1/V/HiZfyf/10n2j/9Nmxf8NQ3b/1+L/kvyfsWv+z4ZJ h6/0f2rN/0mhtyL+756O/7Fj/Z+8mCvj/+RyXJn/k1O8iP8LX3FZpP5fBv/3tEJa4f8U/u+P UCtZ4f82ojz8X0b/N8gNX7qdoZ628QhVl/8bzOn+r5X/zOr/mrP9XzPY1g2Uhq7bG0oP/dT+ dupD/J//U/B/C08in+b/Rp3b/7knfPxfXCj8X6Xt7v+6A2PE+T8r/q/7Ufi/45s7y/F/8fPe +L/0rPB/CcOKQv5Pj6v+T465Av4vzGaWqf+H/0vyf9Ydgfi/TaHO9n/ylUVZ/d9g8H8ZssL/ 4f9es8L/JYai/l9sqNc9iP/LsAPxf4mhKvN/1P/D//0jFP4v5cPC/6WHwv9tP9iv7f/CSrc0 //e6vBL/FxfqNP83rvo/+WDwf//2f12D/0vyfyXr/1Xp//6q/6eHlDt+WFwr27iW/xsN9f8S /V+Ypijg/4w7X/F/i6E2+r9OOvzf69QP/q9M/T/8H/4P/4f/w//5Dv+3NdRKVvi/jSgP/5fR /9lg90y7P9TTNh6h6vJ/H1D/r0r/N/S3sYfzf2EicKf/M7+dPAvj/3Jkhf/b5//chCr+Ly4U /q/Sdvd//YEx4vzfIP7P/ij83/HNneX4v/h5b/xfelb4v4RhRSn/Z1b9n0wFlqj/14QXNCX8 X3NAKPxfTCj836M71v/5d39Z/V9H/T/831oo/B/+7+2wwP+9xcL/4f/wf6uh8H8JWeH/EkPh /yLTwv/dO/zfR/u/KUx44f++wf+FhfNf6f9sX8z/PbI62v95p4T/i8qK+n/U/1s6Al8XIuL/ Infgp/m/Xrt1dHpIWIQzdf6XQ+e59en+Lzx44P/+7f/8KXwh/6f9+7vv9H/uyo7/i8oK/1fK /8mhV8T/SdYl/N/9bVrKk8g2//f7iO9Ht8f6v5BCCf/X+vMV//fHCmmF/1P4vz9CrWSF/9uI 8vB/Gf3fEF47+253/b/ZNh6h8H/4v4WsXv3f1E9u3qKbEvyfdemETn1G/T/Jozb/p/2hV5v/ G3L7P039P/wfTdrd/9kDY0T5v9v/7f2f/lH4v+ObO8vxf/Hz3vi/9KzwfwnDitP9n3yhTJH6 f/KOIifKs/i/Y/zf4N7M4P82hVrxf8MBoVb8n/vtrP7v9nCP/0vPCv/3Df5vmPB/qaHq839t g//D/63vQPxfYqjK/F/f4f8yhcL/4f+e9yD+Lz0U/m/7wX5t/zdfdXuw/wtPYmn+T+aXqP93 dP2/Od3A/635P+r/4f+WFiJerP5fcEo1+b+uMa2r/9c1Q0L9P+sXC4XO70D8X8wOVFv9n/ss 89b/Gyf8X2RW1P/L6v/cZ3Wu/zN6zO3//MF+sv+b/BGa1f/ZNf83yuCshP8L73Pr8n863Afx f/g//B/+byHUSlb4v40oD/+Xz//pxvaPbl+o5208QtXl/+4VvfB/ef3fZIf2tpNvj0bd3lB6 mPr2t5uFwv/h/xayevF/nc5f/+9xwz/L/3X95M6JnP7PhcL/0SLb3f8NB8aI839a/F/7o/B/ xzd3luP/4ue98X/pWeH/EoYVhfxf9wn+7xCUh/9LDIX/ewuF/8P/4f/WQtXm/6j/h//zv0X9 P4X/27oD8X+JofB/CVnh/xJD4f8i08L/3Tv8H/6vbv8noYr4P7mcfKX/03qq0f+ZFf93XwqL /8P/zVp+/6ebEf8XGSrO/zUJ75Xu/s+GL3P8AP/nD5us/q/rF/3fbSjr/F/f9Sn+bxoe3e06 gP/7Fv93+xQu5f/kQKjN//lrYFb/N/QXqv9X1P/NK5F/m/8z3Qf4v0nPur3+r513F/N/Zh7q WP831en/hke32/8N8w7/p/B/f4RayQr/txHl4f9y+j9fW/g2kG53h3rehhvl1uj/TIf/y5LV s/+7jZD06L63SF577/N/Y+PGxKFT/rtw8H85srqG/zNTjf7PehOL/6Od3O7+bzwwRpz/M+L/ +h+F/zu+ubMc/xc/743/S88K/5cwrCjk/9x72mX/F46HEv5PNB7+b8Nhcbr/s63C/20LteL/ 7AGhSvk/M+L/MmSF//sG/0f9P/yf/y38n8L/bd2B+L/EUJX5v1Hj/zKFwv9l9n/yNfr4v6hQ +L+v9H86zN7i/7Z4imX/J8Mz/2yV6v/ChrsV/xcW1qf5v37elfN/F6v/J+WA8H9L8wlz/9d2 +L/vr//XZfd/7Yr/m5rs/m9c83+CHMwUbpH7/F/Q4bJObtX/hRdzNfk/Y3Wb2/+5IxD/F7MD 1Vb/587XvPX/9LXq/5mw5Bj/9zr1c5r/M93p/q9tyvm/b67/t+7/QvXYIvX/5GpRxP/JeVfC /zXzonzV1P8r6f/knljE/8m/p/m/2TaUwv8p/N8foVaywv9tRHn4v3z+Tw3yZUKjSaiB+rSN Wv1fN+L/smT17P9MPxg3b9FZmRbc6//Mb+cnC873fw3+71v8nz/0svo/9y1nJ/u/1mav/+fm bvF/tMh293/TgTHi/F8r/m/4Ufi/45s7y/F/8fPe+L/0rPB/CcOKUv6v+QD/NwSKiP/787A4 2/+N7nuG8H+bQq34v/aAUCv+z8885/R/7tUV/i85K/wf/u81K/xfYqhC/q+1+D/83/oOxP8l hqrL/7n3Ifi/PKHwf5n9n4xacvo/M+D/UkPh/xJDLfs/WVOK/9sy6Fz2f31YvuB30F7/F16r 4/++zf+t1v9r5CzC/+H/Zq3S+n/l/F/J+n+et922Hm6R+/xfQC/tPdRl/F/bNNn9X/sB/u9e D7KE/wvX1q/0f5er/9dK95X+b6zS/51f/69pTG7/566B+L/Ezwr/p+IeUOcPPQr/h/972cZ7 qHlah4XC/+H/1kKtZIX/+8dj9wf4Pytjdmun/aGetlGr/7PN+f4vrJetyv9N49g6/9fLkHOn /3NXztDNQuH/8H8LWb36vz57/b9P8H+9eyjC/9HObsH/jUdauzj/14n/a34U/u/45s5y/F/8 vDf+Lz0r/F/CsKKQ/3OT0Sv+Tx6vS/g/eV2C/9twWOD/IrPC/+H/NryjwP+lh6rN//UG/5ca qkL/1+D/8H/rOxD/lxiqLv9H/T/838f6P7mmU/8vKhT+7yv9X1gshv/bMuhc8X8yPEvzfxLj 4ZRW/J/82Hf6P9tX6P88iVryfypcx/F///Z/ZsT/Uf9PEpl3Vfo/972Sy/4vZP2d/s+FWvB/ 01Rl/b9K/Z87d/P6v9td+FL+r5GuLv/nl3Jk9X/tUMz/uc/qVP/XTn2X2/+5NY/1+T9/BC76 P9F4+L8N61Pxf3E7EP/nO/wf/m8pK/zfRpSH/8vp/2RIOvhXtHv933wb6rdSHv4P/7eQ1bP/ ayfbNs7/hemsvf5P/3Zuft/i/7Jkhf/b5/9a29To/wz+jxbd7v5PHxgjzv/14v/Mj8L/Hd/c WY7/i5/3xv+lZ4X/SxhWFPJ/bjL6dP8nGq+I/+uOCHUl/ze2Cv+3LdSK/zsCiSz7P3+UZ/V/ ZsT/ZcgK//cN/o/6f/g//1tP/s90+D/83/oOxP8lhqrM//Ud/i9TKPxfZv8nQ3T8X1Qo/N93 +r9RruP4vy2eYtn/yZ9Swv/dB51J/i98WNT/O7T+nxrlg8H//dv/Uf+vCv/XSET832uoZ/9n r+T/2n7I7f+cfcH/xexAtdH/te6Dyev/3DXwQv6vkelG/B/+D/+X0f/JQLqI/wvlgkr4v/D4 UML/haO8hP8zzSwU/g//d3Qo/B/+by3USlb4v388dn+A/wsvXqTbGeppG49Qdfm/u2qsy/+5 udtz/Z8ZbmML5/8GszfUbTTbT7+dwv/h/072f37mDP+X9nx1tlui5Wl3/2cOjBHn/6z4v+5H 4f+Ob+4sx//Fz3vj/9Kzwv8lDCtK+T+z5v/khV0R/6fl0Qr/9/n+b3JHIP5vU6gV/9dkCNW8 hFrxfy6rrP5Pdfi/DFnh/77B/5ke/5caqj7/R/2/PVnh/zI/H+D/Encg9f8SQ+H/3kJ9m//r fQ74v6hQ+L8v9X/hG/vxf3v93728ndtru/1fuAC0L6Fe/Z/8ux977vZ/rwt8K/R/fXe+/wv3 d/wf/m/W8vs/fXvyPt3/iW7I6f90X6P/W6//F6YTZD/X4f+mXuf2f6Y73/+pUQ63Iv5vfhM5 1P817nVjXv93uwtfyv8NvvtO/2fwf0f4v84MJrf/8wf7sv+TI7Qy/ycor4j/68Ptt4D/C0uk itT/C1/x40e3B9f/a2ehDvV/ti/m/8INv4j/m1uIvdfA5XpK+D/831qolazwfxtRHv4vo/8b e7mxTu3+UE/beIQ60f+14XGxSVi7rGUEHbrbT+L/smT14v/GsRu8/5O5m73+b/zt1Ef4PyMn A/5v4UkE/3fvDvR/feNmQbP6PxcK/0eLbHf/1x4YI8b/aff/17czQ/8o/N/xzZ3l+L/4eW/8 X3pW+L+EYUUh/+e+p3XF/8kxV8L/yWxmTpRn1/xfewQ1vI7/a/2bGfzfplD4v7es8H/4v6/x f73B/6WGOtv/WZPb/7lFdPi/2FD4v8zPB/i/xB1I/b/EUPi/t1Df5v9kzIT/iwqF//tS/xcY E/5vr/8LRSPS/F/71HUr/k+W2CbW/+vnXZ3+r1z9P0+iluv/yTxFZf5PDsiM/i/oK/wf/m+T /5sawRphUmqn/5uv0V/1f5M/ifRoU+74ATnIv3bjqv8LV3b5ww71fz7rrP5Pt0v+Tw/ugpfX /92zev+wCvq/MClXwv+FvVXA/2lnX6j/txhqk/9r/HUW/7cw9XOa/9PmdP83Zq//p1b9n6w1 LuH/xslfijL6v9uD6Jr/kytSEf8nV4si/k8+mCL1/8JX/PjRTC31/6zcE8v4P/mQ8H/4v3lS x4XC/+H/VkI9JTV/ZK7F/91uG/4kavX+a+DzNtyIqEb/N36A/5Np4pz+Tzcn+7/b9eE2HNNd Fy4TO/1fN/52Sv2qRvwf/m8hqwL+z5zu/1rrjsCs/s99awz+jxbZ7v6vOzBGnP/T4v/aH4X/ O765sxz/Fz/vjf9Lzwr/lzCsuJL/68ILmqwoD/+XGAr/9xbq2/yfX3eY0/9pg//LkBX+7xv8 H/X/8H/+t57r/1n8H/5vfQfi/xJDVeb/qP+H//tHKPxfyoeF/0sPdRn/J8vz8H9bPAX+L+q4 eF6MbfsK/Z9er/8nRzb+D/83a/i/jf5v9lk9hTrA/41r9f/84hE9TAnvle4lhYRmdKZK/+cu twv1/5qmTv9n7+ed7M99/i8c5Z/j/9xogvp/i6E2+j9/38X/vU/9XNj/6bag/+vuq939R/dd /k93a/4vVFAp4f/CDizi/+S8K+L/woyFH80cXP9vTg0P9X+9jG6L+L9BHg+K+D/59zT/N9uG Uvg/hf/7I9RKVvi/jSgP/5fR/zV+RYFu/GrEnf7vaRtuOFij/2st/i9LVs/+z0x9P7nxqAlD pX3+z01KhW4W6kT/F+Bfdf7PvwzB/y0sUn3yf+fX/2vH/PX/LP6PFt3u/q8/MEac/zPi//of hf87vrmzHP8XP++N/0vPCv+XMKwo5f+aNf8nK3SK+D99BMpb8X/dAaGu5P9sq/B/20L92/9l vQaW8n+txf9lyAr/9w3+j/p/+D//W/g/hf/bugPxf4mh6vJ/btEy/i9PKPwf/u95D+L/0kNd xv+F9b/4v8/xf9qs+L82QK9v9H9aT8X8X9+d7/9kOQv+b2E+Af+X0f+5r9K4kP/z9ZTK1P8r 6f+CU6rK//V2qNL/dXK5lYWpif5vtur2XP9n3MMA/m8x1Kf5v66ZVF7/pxT+7xj/19mC/k9O hq/0f+v1/8LgrIj/C2tL6/J/Tbn6f0/UcOcDajt/mlGr/s/67Zbxf7K3qP+H/5sndVwo/B/+ byXUU1Lzp4ha/J8bbLpu0AnjwKdtPKRcXf7vXtWwLv83Q3nn+L+2b28DQN112ib5P/3buWuO Od//yR9am//z712q839tdv/3AfX/8vu/Fv9Hi293/2cPjBHn/1rxf8OPwv8d39xZjv+Ln/fG /6Vnhf9LGFYU8n+m+wD/F76uA/+H/3tq+L9E/yfrHzL6v27E/2XICv+H/3vNCv+XGAr/Fxvq dQ/i/zLsQPxfYqi6/J9bG4j/yxMK/4f/e96D+L/0UBfxf1rWKeL/tgw6T/d/1P/7NP/nSRT+ LyqrJ//XWvzft/i/2yUb/xcZ6sn/ue+VvIz/67Tps/s/+wH+T8oB1eb/3GeZ1//dDotL+T+/ 9h//9z71c2X/Z8bc/s9Vclj2f+GzxP99gf8L5yv+7wv8nxwPZfzf+Oh2+79x3uH/FP7vj1Ar WeH/NqI8/F9+/2f9IDjN/9nHQBr/9x4qg/+Th6mq/J+bt2i8/+vN3lB6bNwIIXSzUPg//N9C Vsf7PzfPjv+LC4X/q7Td/d9wYIw4/9d5/9fpH4X/O765sxz/Fz/vjf9Lzwr/lzCsKOT/buP2 Nf8nr8dK+D/RePi/DYfF2f5Pu4Vb+L9NoSr0f9T/w/+thsL/4f/eDovq/J9bRIf/iw2F/8v8 fID/S9yB+L/EUPi/t1Df5v8Gf3zj/6JC4f/wf79Tqtfyf2FhKvX/XkM9L8aeTDH/50BKofp/ 46r/kxTwf//2f241O/4v6rN69n+ulHap+n/dmv/rwlKTKv3fff18kv/r76Eq9H+OWy/4v2bI Xv/PXW7xfzE7UOH/VCH/568Wtfk/f5PJ6v/0iP+LCnUN/2fwfwf5P3lDU8b/DY8u0f+1vwvn 8X9xOxD/Jx3+b2uolazwfxtRHv4vo/8b5NY4+KHSzlBP21CV1v+7ix78X17/13R2yOz/qP+H /8P/4f9oH9Hu/m88MEac/+vF/7U/Cv93fHNnOf4vft4b/5eeFf4vYVhRyv+ZNf93yHm17P/k HQX+b8Nhcbr/G1uF/9sWqkL/515d4f+Ss8L/4f9es8L/JYbC/8WGet2D+L8MOxD/lxiqMv83 avxfplD4v8z+T1YW4f+iQuH/vtP/yXpv/N+WQeey/+uz1/97hKqp/l9B//fICv/36f7P4P++ pf5fSf9nP8f/5Vta5JarLPu/8GLuO/3fcv2/tmmm3P7PFVC8kv9r8X/f4v8Ek+H/FqZ+TvN/ 7rM62f/pJrv/MxfzfyIaivi/cPqV8H/ywRTxf+ER349mDvZ/klUJ/yePIPi/BU+B//Md/m9r qJWs8H8bUR7+L6f/kwmL0d+M9/q/+TbccBD/txDqI/2fm0w41f+ZqW967//kmWqv/7O/3SzU mf5PHh/wf39M0j1u+DX5P/fUeLb/82ubs/o/lxX+jxbZ7v5vOjBGnP+z4v/6H4X/O765sxz/ Fz/vjf9Lzwr/lzCsKOT/7qFO9X/ylIf/23BY4P8is8L/5fR/3Yj/y5AV/u8b/J/p8X+poerz f25lG/4vNhT+L/PzAf4vcQfi/xJD4f/eQuH/8H/4v+VQZ/u/sLYN/7dl0Hm+/5utbt7t/+y8 K+j/bF9h/T/vlBb9n1z68X8L8wn4v9rq/+ns/q8t5/9G/F/k1WKb/+tMdv/XfUL9PxtWIJXw f3K4lfB/7nzN6//cNfBK/s9/KwP+733qB/9Xpv6fSLnq/J8cekX8X7j9FvB/oVJeCf8XpnmK +L/ukdzB/k8OvSL+b5R7Iv4P/zdP6rhQ+D/830qop6TmTxHV+D8r8xaD38jOUE/bwP8p/N92 /9e29nYt19390Nvr/8xvd/sZbfF/WbLC/+H/Hp17Fsb/0SJb8H/TkdYuzv8N3v+19kfh/45v 7izH/8XPe+P/0rPC/yUMKxb9nwxsC/k/GU+U8H82vDLOh/Lsmv+T9034vy0rzJf8nxeo+L9N oc73f27jWf1fa/F/GbLC/32D/xsm/F9qqPr8H/X/9mSF/8v8fID/S9yB+L/EUPi/t1D4P/wf /m851On+b5TrOP5vi6dY9H/3WbMC/i8s8PXdbv83H7bPQtVU/6+c/9Nmzf/JXQT/tzCfgP+r rf5ffv+nrlX/L2Rdl//rdPb6fxb/d5D/c+duXv/Xd/i/yKxO838W//f9/i9k/Z3+zz0ML/q/ TgZnRfyfnOJF/J/srSL1/+5PKkod7v/kgleZ/+tloRn+D/83T+q4UPg//N9KqKek5k8R1fi/ Qe5XQ5twDXzahl+gVaH/u6tG/F9m/zfeRunO/w1mbyg9Nv4ZTTr1Ef7PyERgov+TEfLn+L/B YzL838Jj95P/a22D/4sMhf+rtN39nz4wRpT/0434P/2j8H/HN3eW4//i573xf+lZ4f8ShhWF /J8bLJ3u/7rwgiYrysP/JYZa9H/+CMT/bQp1vv/zM8/4vw3vKPB/6aFq83+9wf+lhqrP/1H/ b09W+L/Mzwf4v8QdiP9LDIX/ewuF/8P/4f+WQ53v/0JxAPzfXv/X5/B/4Wt125dQr/X/wopZ /N+/D8F2/AD/Jyng//B/s/bV/u92yV7xfwP+D//36v96nb3+3z2r9w+rpP8LH1IB/xeurV/p /25/9aX8nx8x1eb/rLdQWf2fmor5P23O9n/NZAr6vzDpUJn/k4epIv5PrhZF/F9Yyp/yJLK1 /l/4ih8/mjnW/4UZpSL+z/8pZfyf7K0i/i9YiCT/N9uGUvg/hf/7I9RKVvi/jSgP/5fT/8lN ZPBX3b3+b76NWv3fJ9T/C6s/Mvo/3Z7t/27Pwm1m//c4LM73f0krR+/+Tz+FOrP+30T9vy3+ j/p/+D9aaHf/Zw6MEef/tPi/9kfh/45v7izH/8XPe+P/0rPC/yUMK0r5v2bN/8lhUcT/yVMe /m/DYYH/i8wK/5fT/3Uj/i9DVvi/b/B/1P/D//nfwv8p/N/WHYj/SwyF/0vICv+XGOpS/k8+ GfxfVCj835f6v/DeFP/3Df5P/v07/Z/t8X+Rod6OQPyfijmvruD/dDOeX/8P/5fq/8J0gvxh dfi/Tmev/6fHa/k/ET8l/J92o4m8/m+c8H+RWZ3m/xT+72v8n8H/4f/8jzbzDv+H/3vbhlL4 P4X/+yPUSlb4v40oD/+X0/8N06Pb6//m23iEqsv/jV2N/m+G8s6q/2f60fs/+ZD2+j/726mP qv+H/7ui/6u0/p/B/9Gi293/tQfGiPN/Rvxf/6Pwf8c3d5bj/+LnvfF/6Vnh/xKGFef7P5FC JfyfDa+M8X9/Hhan+z/3Shj/tylUhf7PdPi/DFnh//B/r1nh/xJDFfJ/flEC/i8yFP4v8/MB /i9xB+L/EkPh/95C4f/wf/i/5VDn+7/AmPB/e/1fJxPfvds3e/1fmDzX00uoF/8XBp1p/i+s Ty3u/+qs/2e7Ff8Xnn3xf//2f25dAv4v6rM6z/89snq+LnUyzfSd/i8cgeqt5fd/XdOd7//8 ZSKr/3OhFvxf22Sv/3f748/3f71cbov4P0mhgP/zF9is/u/2k5fyf37whv9bmPp58X/Nhfzf MDS5/Z8/2Jf9n5wM3+n/7Kr/kytSCf8XzFkR/yd39yL+Lzzi+9HMwf5PDrcS/s9/304h/yem poj/k39P83+zbSiF/1P4vz9CrWSF/9uI8vB/+fzf7ebhb4bGb2lfqOdtqE+o/2fC42Ka/5Pd EAbSg6nR/7kvEzrX/+mp7b3/k8eDvf7P/HZ+wHy+/5MdXJ3/83ng/xYWqX6Y/xtun5LK6/9c KPwfLbLd/V93YIw4/9eK/xt+FP7v+ObOcvxf/Lw3/i89q1P9Xxg84f/+7f/ca8Zl/yff0F3C /7VNeEGD//vzsMD/RWa10f8Nsw7/t+r/Wov/y5AV/u8b/F9v8H+pofB/77Hwf/g//N9qqMr8 X9/h/zKFwv/h/573IP4vPdRV/F+QPPi/LZ5i2f9J2mn+L8w2/+X/ws0T//fvQ1DrYv6vWfN/ YZUj/u/f/o/6f1/k/2yN/q8by9X/61b9n1wmvtP/rdT/a3Wf2/+5I/B0/yclkyvzf8Y9DOT1 f+4UvpD/839oEf/XG/zf1/g/i/9L9H8iGkr4PyljXMT/hfO1hP8Lc91p/k/S+cv/hRQK+D95 hVWf/5se3W7/N807/J/C//0RaiUr/N9GlIf/y+f/1CQPPVOXcA182ob7SfzfQij836L/M/3t IVh37TSZvaH04KdIQ6c+o/4f/g//V5n/09T/o8W3u//rD4wR5/867/86/aPwf8c3d5bj/+Ln vfF/6Vnh/xKGFYX8nxtWrPg/eT1Wwv/p7CjP4v+O8X+dmx7H/20Kdbr/81/fm9X/dSP+L0NW +D/832tW+L/EUPi/2FCvexD/l2EH4v8SQ1Xm/6j/h//7R6hT/Z/1x1tO/6db/F9qKPxfYqgV /xcmvPB/u/2fTNgU8X/yn2n+L8wf4f+Orf8na4nxfwvzCU/+b8T/fYv/02bN/8llIqf/s+X8 n/mE+n8V+r++GXL7P3e1ON3/TVX6P3fuZvV/t7/6Wv5vfHRf5/8s/u8Y/9dl93/uGrjs/4K5 KeH/bDH/dzvOlY9Vl/+TdKrzf8Ojw//9e2yB/8P/rYTC/+H/VkI9JTV/iqjG/4VjbvQ3kZ2h nrbhF2h9jP8z+0P9+r8wq93g/7Jk9eL/OnO7Pjj/J2O0vf6v/e0U/g//d7L/8zNn1fm/tsH/ 0aLb3f/ZA2PE+b9e/F/7o/B/xzd3luP/4ue98X/pWeH/EoYVhfyfe7Q63f/JRC31/zYcFqf7 v7FV+L9toc73f/6Yw/9teEeB/0sPhf/D/70dFtX5P/f1Uvi/2FD4v8zPB/i/xB2I/0sMhf97 C4X/w//h/5ZD4f9S0zrd/92XsSb5v2nerfs/mRv6Tv9n+xr932r9v7ByDv/3h/+j/l+i/3PM 5uz6f/i/TUuL/lH/L8wkyx9Wh/9rR43/u67/c8/4+L+4rM7yf0524/+istrq/xr8H/4P/7c9 FP5P4f+2hsL/4f/WQq1khf/760nkZP8X5kZS6v89bcONcs/3f3LM5fR/d9WI/8vr/25t8v5P nqn2+j/9281C4f/wfwtZFfB/pkb/11H/jxbf7v5vODBGnP+z4v/6H4X/O765sxz/Fz/vjf9L z+pU/xdWfeD//vB/as3/HXJeLfo/E1YSlfB/wxGhLuT/evfGs0L/Fz7LEv7vCGq44v/8giL8 34Z3FPi/9FD4P/zf22FRnf+j/t+erPB/mZ8P8H+JO7CU/+s7/F+mUPg//N/zHsT/pYe6iv+T l8L4vy2DzvP9XxgJ+sN8r/+TdB4LfCv0f8acX/8v3J7wf/i/Wcvv/zyzOdv/9dn9X1vM/7X2 A/xfcErf6f9uD3OF6v/ds3r/sAr6vzGsQML/PYd6rf/nCpNeyf+10h3v/zq3A/PW/1P4v2P8 X9tl93+mSv+n8H/H+j+/+VT/95sV/i8yFP7viFD4P/zfWqiVrPB/fz2JnOv/rJxJ1t/kd4Z6 2oYfB1bo/+qs/zdDeSf5v75tB/F/u0M5+Nf8drNQJ/q/AP9q839+mIP/W3js/rj6f417HZ63 /p/p8H+02Hb3f+OBMeL83yD+b/hR+L/jmzvL8X/x8974v/Ss8H8Jw4pC/q9drf9Xzv+197fT +L8/Dwv8X2RW+L+c/u/2EIL/S88K/4f/e80K/5cYCv8XG+p1D+L/MuxA/F9iKPxfQlb4v8RQ +L/ItPB/9w7/99n+L7w3xf/t9H86LMj3Q+q9/i+4j9DZVf9nH11q/T/837H1/wY5i/B/f/i/ Ef+XVv/PMZuz/V8b5kML+D8fo22nlHuj7IbQrdb/mxrvQrSsRN95x5f/t7KT7KCmRv836iX/ Z7q2rbL+H/5vm/9zhUnxf1FZneb/LP7vEP83Nja3/3Of1Yr/G2fdXv/XzruL+b+wBB3/t9f/ mebR7X1ADa+wu9+sruT/pplA3XsNnG9DKfyfwv/9EWolK/zfRpSH/8vo/yZR+NPY7g/1tA33 jQj4v4VQH+n/Tq//Z1p9u4c7/ydz4Dv9nxsTh85NIln8X5asLuL/pgr9Xzu2uf2fC4X/o0W2 u/+bDowR5f9MI/7P/Cj83/HNneX4v/h5b/xfelbn+j/JGv+32//JeKJI/T8Zrpfwf509INSF /J91R2CF/i+c4pX5P5cV/m/LOwr8X3qo2vzfMOH/UkPV5//ciAn/FxsK/5f5+QD/l7gD8X+J ofB/b6G+zf9JMZuc/k9Z/F9qKPxfYqgV/yezt/i/LZ5i2f/JA2ma/5Mh3p/+b1YaYbf/e1uf Wsj/TaaY/2vbD/B/kgL+7w//R/2/Cur/5fd/ujvd/4VSg7pJeK+kejk35YN2oc72f3qS77/L 6P/aYdH/jY4cVOj/wnJV/N+//Z97xr+S/2v8qKwy/zf0+L8E/3e7z2ev/+cP9gv5P3nBgP/b sD71Sv5PFhHj/xZuIvg/3+H/toZayQr/txHl4f/y+T8tE8Oh2xfqeRsPKYf/+3z/N0N5J/k/ O92ev3R3u0qMe0M5+Kd/O/Uh/k8mv/F/X+D/aqz/1zf4P9onNPF/tjnS2sX5P+39nzE/Cv93 fHNnOf4vft4b/5eeFf4vYVhRyv81H+D/5HUJ/m/DYYH/i8zq8/xfe0CoFf/n1x3i/za8o8D/ pYeqzf9R/w//53/r2f81+D/83/oOxP8lhqrM/5kB/5cpFP4P//e8B/F/6aEu4/9keR7+b4un WPZ/YW05/u8tq6fF2AXr/92ut6X8n13zf+E6jv/D/80a9f8+z/+NxfyfmyVZ9n/66QbwZf5P N8v+z/a5/d89q/cPC//3cf7v9ox/Kf8nS46/0/+pKv2f+6xO9n+6ye7/qqz/p82K/1OTPEyV 8H9DuLIX8H/h3C3h/xoJVcL/hYVfdfm/ACjL+L/ZDWC3/3u9ieD/FP7vX6FWssL/bUR5+L98 /k9N4eGtbfeHetqGe5LH/y2E+kj/d379v7EZvP8bZDi40/+5u1zoFP4P/3e2/zP4P/wfzbe7 /9MHxojzf0b8X/ej8H/HN3eW4//i573xf+lZnev/wutc/N/ro9WT/zPdmv+Tw6KI/2uOQHkr /s8cEOpK/s+2Cv+3LdT5/s+Fyur/tMH/ZcgK/4f/e80K/5cYqpD/c9NL+L/YUPi/zM8H+L/E HYj/SwyF/3sL9XX+zx/f+L+oUPi/L/V/8jiF/9viKZb8nwoX8iT/Fx6xwsL5btX/yX+m+b8w f/RYn0r9v6jD4sn/qW61/l9YW47/ezvY5/6vtfg//J+S/8+sq9P/2Qv5v7a3ddb/G8MKpAL+ r50j8kP9X2un3P7vavX//Ps7/N/71A/+D/+3dGv8OP9nw5W9hP+TrIv4P9lbRfxfGCr5gfSh /q+X6T/834abCP5P4f/+FWolK/zfRpSH/8vo/wbJY5ja/aGetvEIVZf/Gwz+L0tWz/6v7dyr v/r8n5EdXJ3/c1nh/5YWqdbv/9wXquH/aJHt7v/MgTHi/F8r/s/+KPzf8c2d5fi/+Hlv/F96 Vvi/hGFFIf+nxw/wf4egPPxfYij831uoLP7vCCSy4v/cxqn/t+UdBf4vPRT+D//3dljg/95i 4f/wf/i/1VD4v4Ss8H+JofB/kWnh/+4d/u+z/V9YGY3/2+v/xlDzIMn/yXUC//dt/m+9/h/+ b5P/o/5fov+7XcGL+T9Vzv8Na/4v3HjDbt3p/+ZXi3AEqrdW0v+pJwBeh/8b9JDb/7kdiP+L 2YHqPP/nLkxX8n/+7lHE/7llzXn9n63S/2lTo/9TNfo/fwTi/+KGMc28w//V4P/so9vt/+y8 w/8p/N8foVaywv9tRHn4v5z+L8yNtAnXwKdt+LFFhf6P+n/pbxuX/J/tBu39X5id2+n/9G+n 8H/4P/wf/o/2Ge3u/9oDY8T5v877v7b5Ufi/45s7y/F/8fPe+L/0rM71f0csJa7Q/5lV/ydS qIT/k9cl+L8Nh8XZ/m9w8+L4v02hzvd/bp9Q/2/LOwr8X3qo2vyf6fF/qaHq839uYRb+LzYU /i/z8wH+L3EHlvJ/fYf/yxQK/5fb//kNZ/V/Lf4vNRT+LzHUiv8L6eD/dvs/WeCY5v/CaDKs HbUr/k9Gm9Lt9n+vH1Yh/6f1VKP/a1b9n8xT4P/+7f+o/3eY/5PZ6Jz+r+vO938+hpnCpNRO /zdfo79a/2/yUxtGtwF477rj333NdA91Gf93u3e0uf2fpv7f1/g/X5j0Ov6v8Uco/m9h6ufS /s/m9n9uccKy/7PDLLl6/J8cekX8n5wMJfxfONwK+D8VButF/N/9CFX7H1A/z//JEL6M/xsf 3W7/N847/J/C//0RaiUr/N9GlIf/y+n/5LYh3V7/N9/GI1Rd/q8ba/R/M5R3jv8zoxtI4P8W Q+H/frtD/d+U3f+Np/u/ts/u/5xqxP/RItvd/3UHxojzf734P/Oj8H/HN3eW4//i573xf+lZ 4f8ShhWF/J+bjD7d/8mfgv/bcFic7v/cGjD836ZQK/6vyRCqeQmF/4sMhf+7d/i/Nf9H/T/8 n/8t/J/C/23dgfi/xFCV+b9R4/8yhcL/ZfZ/sowuq/9r8H+pofB/iaHwf7Gh8H856//Zvpj/ U/b8+n/y0eH/Fg72uf+j/h/+72T/t1b/7wD/Z1b939MN4FD/5weYJer/Wd3n9n/3rN4/rDr9 X5imwP99g//zuwz/9z71c5r/M92l/N831/9zWS37P1mVUMT/hWK9RfyffDBF/F9YoFXA/5nm 0R3s/2REVcb/yRr+Iv4vDACT/N9sG0rh/xT+749QK1nh/zaiPPxfTv8nN5nBP/Ts9X/zbTyk HP4P/7eQ1Uv9v37sxf/1Zm8oPUxufBI6d80xH+D/WvnI8H9vTyIf5/+y1/9rbVOj/xvxf7To dvd//YEx4vyfFf/X/Sj83/HNneX4v/h5b/xfelb4v4RhxZXq/4WVREX83xGh8H8xofB/jy7X NbCU/zMd/i9DVvg//N9rVvi/xFD4v9hQr3sQ/5dhB+L/EkPh/xKywv8lhsL/RaaF/7t3+D/8 3xX8n88+0f/9ohb8X2So0/zfav0/WViP/1s42PF/X+r/HrUan69LreisnP6vHU73f2Of2/+1 9kL+r9N6yu3/uovV//tm/3f7oSv5PxlC4/8Wpn7wfzn9n/us6vN/arX+H/4vzf/pRkIV8X/t o9vt//S8w/9FXwPxf9Lh/7aGWskK/7cR5eH/Mvo/K7xtaBJCPW3D/VCN/m/savR/t6fGc/1f 1/RD7/2fDDn3+r/xt1MfUv+vlY8M//f2JFK//6u0/h/+jxbf7v7PHhgjzv8N4v/sj8L/Hd/c WY7/i5/3xv+lZ4X/SxhWXMn/hfeLGVGexf8d4/9G98YT/7cp1On+r3M3J+r/bXlHgf9LD4X/ w/+9HRb4v7dY+D/8H/5vNVRl/s8M+L9MofB/+L/nPYj/Sw+F/9t+sOP/FP7vz8XYkynm/9r2 /Pp/vRzZ+D/836zh/z7P/43F/N8/6v+FQgVh6XYN/q9tjcb/fYv/65zZwP8thrqA/1NV+j/3 WeH/4gbS81ujwv/h//xGPs7/WQmF/1u4icy2oRT+T+H//gi1khX+byPKw//l9H+SR3jpuNP/ zbfxCFWX/2st/i9LVi/1/0x/+5Bq9H8y+Z3m/yTGB/k/68ealfm/bsjt/9oG/4f/o/l293/D gTGi/F/biP/TPwr/d3xzZzn+L37eG/+XnhX+L2FYUcj/ucno0/2f/ClF6v+10wGhLuT/JncE 4v82hTrf/7nfxv9teUeB/0sPhf/D/70dFtX5P7eyDf8XGwr/l/n5AP+XuAOp/5cYCv/3Furr /J/fXfi/qFD4v+/0f2F5Bf5vi6dY9H9hiVSa/wsrOv7wf/NBJ/5vPauC/m+1/p+sdsf/LRzs +L+M/k83Y43+z+gK/d8/6v8V83+mkfnvjP5PLfu/ybb4vwv7v767lv8z0n2j/9OmnP+z+L8k /+c+K/xf4meF/1NRo1v8H/7P/Sj+bykr/B/+D/+Xy//J5db6x6y9/m++jUeouvyfbc73fzIk zen/dHu2/xun28NUvf6vSZr8bubdB/i/Qcaa+L+FRapP/s82+L/IUPi/Stvd/40Hxojzf1r8 X/uj8H/HN3eW4//i573xf+lZ4f8ShhWl/J/6AP83hcI6+L8/Dwv8X2RWl/Z/fkFRTv/n3ifh /5Kzwv/h/16zwv8lhqL+X2yo1z2I/8uwA/F/iaEq8399h//LFAr/h/973oP4v/RQ+L/tBzv+ T2X1f6qrsf6f7Yv5P2WL+b9uXPN/Mk+B/8P/zRr1/1L9n8nt/1r7CfX/ZIdW5f+0zl7/z3T4 v2/xfx4m4/+isjqt/p+t0v9pU6H/U9T/w//JRpp5dzH/N/rt4v8WbiKzbSiF/1P4vz9CrWSF /9uI8vB/Of3f6P/T+jmmvf5vvo1HqLr8XzfW6P9mKO8k/9f0t0dE/N9iKPzfb4f/w//RvrLd /d90YIw4/9eK/7M/Cv93fHNnOf4vft4b/5eeFf4vYVhxIf/XNkegPPxfYqhl/+eKkOP/NoU6 3f/5pRj4vy3vKPB/6aHwf/i/t8MC//cWC/+H/8P/rYbC/yVkhf9LDIX/i0wL/3fv8H8f7f/C 4Yb/2+Iplv2f/LtfarLb/4WzMsz9rPm/NkCvr/R/Bev/lfN/asT/pfk/V0AR/xfzWV27/l92 /xcEqnprRev/fbP/M8OS/2tsM1VZ/28ISOt4/xfWRH6n/7ta/T+/6AH/tzD1g/8r4//sMEuu Gv8nKK+I/7s/qRTwfzq8TUt5Etnq/2RvlfB/IasS/k8OiyL+T55Uyvi/MJkgN9Kd/m+2DaXw fwr/90eolazwfxtRHv4vn//TrX/eDt2+UM/beISqy/9Ntkb/5yYTTvV/TWdvZ5Lu2l7mwHf6 v3b87RT+7zD/J8QX/7e0SPXT/J/tc/s/Fwr/R4tswf/pI61dnP/rvP8zw4/C/x3f3FmO/4uf 98b/pWeF/0sYVlzJ//VhYT3+78/DAv8XmdWF/V8r6w7xfxveUeD/0kPh//B/b4cF/u8tFv4P /4f/Ww2F/0vICv+XGAr/F5kW/u/e4f/wf/g/9e9Jafxfff5PDjf8H/5v1vB/+L9r+L/b2Ne0 4v9Mkv/rH931/N8ckeP/Ptr/NTLdiP/D/+H/8H+/OxD/974D8X/4vyyh8H/4v7VQK1nh//56 EjnV/5kmEDnf7Qv1vI1HqDP9n1z10vxfJ3cd/N+B/u82Om9vD7C6u49f9vk/68YBoVP4P/xf lP8zU27/52fOzvV/Xavxf7QPaHf/pw+MEef/eqn/p38U/u/45s5y/F/8vDf+Lz0r/F/CsOJK /o/6f9/i/7rGTXjj/zaFOt3/yTGH/9vwjgL/lx7qXP8n0yL4vy2hLuT//AwM/m/THsT/ZdiB +L/EUGf6Pzu4vYX/2xIK//cW6tv8nyxIw/9FhcL/fan/k+V5+L8tnmLR/4VlzUn+L6yq+NP/ hdXNx/s/LasHE/2fXP3+8n9h5XUJ//f7sKLU/iUQ2/xfmFCuzP9JDPzfwhqSbf5PbhlF/J9w gCL+T94c1Ob/fNam6VKWFt19jczDfYD/056vFfB/Vg+993/hyr7T//lJ39B9hv+z4UMq4P/C KqY0/xfO1T/8n0sB/7cY6uP8n9PEZfyf1N3M6v/aVf8XHu73r/t+3ob7g873f+5PKeX/zCy5 Y/2f13iF/J8Mzor4P7mJFPF/cm2tzf+FoZI/Xg/2fz6FIv5PPssy/k/SSfN/s20ohf9T+L8/ Qq1khf/biPLwfxn9X+8/ndDt9H9P23iEOtP/yf3K+KH9bv83zLpP8H93U5bm/+Tj/xT/10/u Q7o9FFhJZ5//a9woPHTqM/zfIKt8a/N/fqxZl/9r7eDHs5X5Pz+hiv+jnd3u/s8cGCPO/1nx f+2Pwv8d39xZjv+Ln/fG/6Vnhf9LGFZcyv/5+Tv834bDAv8XmdWV/Z9/L4b/2/KOAv+XHupc /yevnfF/W0Jdx//1E/4P/4f/w/+9hlr2f/638X9bQuH/3kJ9m/+TlWb4v6hQ+D/83+/T8KX8 n3wpc6L/C0O8MPez6v/k39P8X5g/eqyMWfZ/so6ohP/T86mLQ/2fmcKcasrlYqv/k4trZf5P nhjxfwtrSLb5P/msivg/YTjV+T+3g8v4Pz95Vp3/83ytgP/rTevr/3U24V3FZP0SqNB9hv8L p3gJ//eEyI/1f06J4P8WQ23yf42XcmX8n6NWhfzf4D6rMv4vDJWS/N98G+oj/J8b3Zbyf3qW 3LH+z/+1hfyfHHpF/J9cTYr4P7m7F/B/4UZVxv9JCiX8n1zGa/N/YQSd5P/m21AK/6fwf3+E WskK/7cR5eH/8vm/tvG/Hbp9oZ638Qh1pv+T+5nco3b7v37WfYT/Cy/J0vxfGER+iP/rpm40 txvV7T61O9TtGtM1v53C/x3n/2yF9f/M5PKozf/1pm8V/o92erv7v/bAGHH+bxD/1/8o/N/x zZ3l+L/4eW/8X3pW+L+EYcWi/zN+HVtO/2dsd7r/MzILjf/bcFjg/yKzurL/86/g8H9b3lHg /9JDner/wleFtWGabqf/m6/Xc6s68H+Joc72f53/pHP6Pzdiwv/FhsL/ZX4+wP8l7sBF/9f7 5d5Z/d8c5eH/8H8voU71f63/AfxfVCj833f6vylMmuH/9vq/MIgO3zi9z/8FuXPfsFnzfzMm uNv/6Xm36v/uNZuS/F877/pu2f+pIX/9v3bZ/+lwTc/o/x5S7tX/hbXlVfm/3voUMvq/truU /2uFdoRh8D7/97IEYtTL/k8OhKz+T635P9mdOf2fbpb93zDIjrkz5n3+z8y6IFDVWxvccpXb oOy+qH2f/wt3IPkeruYD/J+/Bmb1fy7Uu//rJvcF+rprx3H/5Xbq/b4I3W9W7x9Wyfp/9/IL PtSh/k8m16S03G7/F87dxwvvJf/Xursw/m8x1Eb/54+5Iv6v1yqz/1Nr/k+u5Tn9n1r1f+Ea mOT/ZttQn+D/mtHk9n9qzf/JYL2E/xv8p1PG/8l2i/i/cDIU8X+SQpH6fzKQKOL/5I5Rwv/Z cvX/ZJeV8X/To9vt/6Z5h/9T+L8/Qq1khf/biPLwfzn9n7+Mto3dfw183sbtHm7O939yfZAv VNvt/7pZp7qxEv8nB/U4PIU6z/8NzdTfPoE+VI/c5f96616shG4W6kT/F+Bfdf7PH+WV+T/T 1Oj/bhdzldn/WfwfLbrd/V93YIwo/9c14v+aH4X/O765sxz/Fz/vjf9Lzwr/lzCsON3/yQTo l/o/i/87yP+5b9HH/20Khf97ywr/h//7Gv/Xjvi/1FAV+r8G/4f/W9+B+L/EUKfW//MDTPzf llD4v7dQ3+b/ev+X4v+iQuH/8H+/T8P4P/c/+L923rkvdi7l/5q1+n/hySDlcvHs/+ya/wtL zPF//55PuFj9vwP83+28Wq7/15bzf12YD83n/1Qx/xcEqnpr+f2fGbvT/Z+sving/8bRNN7/ DUNC/b/ej4dD95vV+4dV0P/dkVZV/q9rbGb/5wuT4v/iruzdvFvzf70u5v8E/n2t/2su5f+G bpYc/i/e/8meK+L/wmW8hP8L2y3h/+TfS/i/wZTzf/KoV8T/yaEn3d5r4HwbSuH/FP7vj1Ar WeH/NqI8/F9O/+fnLW5duzvU8zbcKPd8/xc2ntH/me58/zeFL/GqyP+NfX8bVNxu+veh0i7/ 1/vvaJHO/bPG/2XJ6hr+rxnxf/g/2kHt7v/6A2PE+T8t/s/8KPzf8c2d5fi/+Hlv/F96Vvi/ hGFFKf/XrPo/eT1WxP+FFzRZUR7+LzHUov/T7o0n/m9TqPP9n595xv9teEeB/0sPVZv/sz3+ LzVUhf6P+n/4P/zfS6ha/J9XAPi/LaHwf2+h8H/4P/zfcqjT/d8Y3pvi/3b7v7AG1u+gvf4v rOio2f+t1f/TMqea0/89qOF5/k/W8OP//phPoP5fFf7P/3uV/k9P4fqU5v9+Qy37v7CgqoD/ M/4IzOr/3OX2zf/ppp1G7/9st/9yO/V+0jd0v1m9f1gF/V8orFPC/w3F/J//WsS8/m+cruT/ ZNHDt/o/W87/2VX/1z+63f6vn3cf4P90V87/2XaW3LH+z2b3f2rV/8lSpiL+T24iRfyfXFuL +L+wQKtE/b8w3k55QP1A/ycfUhH/1z663f6vnXf4P4X/+yPUSlb4v40oD/+X0/819tHt9X/z bahfKXem/wtzjhn93101foD/Mzn8n3kKdZb/uz1X9bdN3MYwNsX/SY126Wah8H+5/Z/MVNTm /wz+D/9HO6jd/Z89MEac/zPi/7ofhf87vrmzHP8XP++N/0vPCv+XMKy4kv+TqRf834bDAv8X mRX+L6f/0wb/lyEr/N83+L/J4P9SQ1Xo/6j/h//D/72EqsX/jdT/w//h//B/66Hwf/i/3ylV /J/7n/3+r1nzf+2j+zr/t1b/L4SqrP6fbuRww//h/2atpP+bivm/Tl74faf/c0X5Cvk/ba/k /0zfef/Xm/2X26n3p0jo3OI1/F/UDlQb/V/j7ldZ/Z8/hfF/cVf2bt5dzf+Nj263/xvnnTYn +z/baIv/w//h/7aHurb/mw3td/u/p8cD/J/C//0RaiUr/N9GlIf/y+j/tH+xE7qd/u9pG+oj 6v/h/77D/6lp6m/PArcxjJGpu53+z42zQnf7GW3xf1myuoT/01OT2/+19mz/p5s+v/9T+D9a dLv7v+HAGHH+rxX/Z38U/u/45s5y/F/8vDf+Lz0r/F/CsKKQ/1Pjmv9rZTxRwv+FV5n4v8/3 f8Zd8PB/m0Kt+L/hgFDL/s+/p8rq/1qL/8uQFf7vG/zfYPF/qaHwf++x8H/4P/zfaij8X0JW +L/EUJfyfzKqx/9FhcL/fan/k+V5+L8tnmLR/3VhEO322m7/F76nun0JVZP/W63/l9//lav/ d/tJ/F9kVvi/rP6v74r5P1uj/ytY/89Rw7P9X2vk++8y+j93ZV/wf6MR/xdmH3f6v358dP5y ez3/d3/USfN/v2OLRf+n3a0R/7cYapv/kwPhS/2fKuf/VDn/p86u/2ebtmD9P8mqhP8bTW7/ 567sy/4vDNZL+D+Bf0X8X3joqcz/mfbR4f/+PbbA/+H/VkLh//B/K6Gekpo/RdTi/8woRG7y 80P7Qj1vw01MnO7/WrkLS7fX/8k3U4buE/xfK/9Zk//TjW1se/sEzNQl+D+/+iR0bqMj/i9L Vvi/ff6vMx/g/2xu/6dH/B8tut3933hgjDj/13n/1zU/Cv93fHNnOf4vft4b/5eeFf4vYVhR yv+Z1fp/slKghP+TlxNF/J9MweP/tqwwX/R/A/4v0f/ZA0Kt+D+/7jCn/+tG/F+GrPB/2f2f kVWI1P/bEgr/Fzc7gv/D/23dgfi/xFBn+j9ZbJvV/7Uj/i9TKPwf/u95D+L/0kPh/7Yf7Jf2 f09rHvf6v+c1j3bV/02Pbrf/e1ufWl/9v3L+T63V/1OjXFzxf/+eTwjV1/B/u/1fwfp/H+D/ plGmb6eUe6PshtB1Y7Ps/yZ/zJnWBKCwz/+FgaB8CF1To/8b9XL9P1fkSHdtuFHt9X/m0ckq Jvxf3GHxihwW/Z9x83hZ/d/tdncp/+cnQr/V/xWs/4f/S/N/7iZyJf83yOAM/4f/mzU7Zfd/ Lf4P//dHqHlSx4XC/+H/VkI9JTV/iqjG/03t+Oh2+r+nbTxC1eX/JvzfAf5PTZPutfN/fZid 2+f/3DRL6BT1/w7zfwL/qvN/Nrv/G8/2f6ofstf/6/B/tPh293/TgTHi/F8v/s/8KPzf8c2d 5fi/+Hlv/F96Vvi/hGHF6f5PyzFXpP6fvEjC/32D/zMK/7ct1Ir/aw8Itez//Oo56v9teUeB /0sPVZn/c99khf9LDHW2/7NNbv/X2gb/h/9b3YH4v8RQ+L+ErPB/iaHwf5Fp4f/uHf7vs/1f SAf/h/+bZ4X/S/R/g5xFdfk/a7LX/3uYMvzfLv93rfp/o994q8Nu3en/5lcLZ8qW/Z//pI0e Uu744e+UbbjlKsv+L7yYq8j/qXGw1vs/nXC5nXrvPkInq5jwf3GHxRNyKOf/PEy+kv/za//x f+9TPxf2f6YrWP/vbs2/0f/5I3DZ/wU6H8bb+8YWr5/Vsv+TJ6oi/k+ugUX8XyNHdgn/p8N4 2x+v1fg/+UPxfwr/N0/quFD4P/zfSqinpOZPEbX4v/BoH7p9oZ638Qh1ov8zQ3gu6PaHci7N d/i/A/3f2LnJhtvNfOwS/J9u7G+n8H/4vyj/Z2v0f7bJ7v9cKPwfLbIF/2eOtHZx/s96/9e2 Pwr/d3xzZzn+L37eG/+XnhX+L2FYUcj/dd2q/5PhfBH/J+8X8X+f7//aFv+X6P/MAaFK+T/q /+H/VkPh//B/b4cF/u8tFv4P/4f/Ww1Vmf/TGv+XKRT+L6//s3JtwP9FhcL/4f9+p1Qv5f9k xXyi/wvXtbD08QP8n6wl/lL/98jqRP8nhxv+D/83a9T/+x7/N/bZ/Z/5AP/nLw1Z/Z+7si/U /2vdxnXXNmb/ETj1/qIZusv5P3nGKeH/fJVL/N9iqG3+zz//lvF/Q3b/p9b8nz93Q7fb//Wz zt1Elv3fHP7sXWL+hofOrv/XZPd/7iZSof9Ta/4vPImU8H82XNlL+D+5NNTm/8IqbH+84v/w f0eHwv/h/9ZCrWSF//vrSeTc+n/jIMMxs/8a+LwNv0DrdP8Xph4z+r8W/3eA/7sNs7tucHf4 ye4OpbvJ3X5Dp/B/+L8o/9d3uf2fm2c/2f8NzZjb/91+Ev9Hi213/6cPjBHn/wbxf/2Pwv8d 39xZjv+Ln/fG/6Vnhf9LGFYU8n/tuOb/ZPRZwv/p8IUx+L8v8H8uD/zfplAr/u8IJLLi//wx l9P/ua+uxP8lZ4X/+wb/1/b4v9RQ+L/3WPg//B/+bzVUZf6P+n/4v3+EOtX/SSL4v6hQ+L/v 9H+hTBn+b4unWPJ/apKzKKP/c4sFFv1fZx7dbv+3IuUO9399V2H9P/cCetn/WfzfJv/X4P++ xf9pU87/2WL+LwhU9dby+7/Wrvm/kHUB/2cm+f67jP7PXdkX/F/vzIbuzNSm+D9/cQudty+n +7+wXLUu/9e5QgX4v8VQF/B/q/X/svs/dxNZ8X+z4eJu//c05NQG/7ewA/F/5/u/sN6khP8L 28X/4f/wf/i/hVArWeH/NqI8/F9G/yezc6bzbH2n/3vaxu0ebmr0f9rg/7Jk9eL/zHgbv9zu 8GEEvdP/9f1vp/B/+L8o/+dnUvPW/zOn+z87Za//574PDP9Hi2x3/2cOjBHl//pG/F/zo/B/ xzd3luP/4ue98X/pWeH/EoYVhfyfsav+TyajS9T/G8Lb6QL+rzuCGl7J/434v+/xf4PC/y2H wv/dO/zfmv+j/h/+z/8W/k/h/7buQPxfYij8X0JW+L/EUPi/yLTwf/cO//fR/u/+PZr4v93+ Tx5IM/o/M9bo/0ZdzP89qOHR/k+t1v+TPYf/+2M+gfp/3+P/VMH6f+X8X8H6f5fyf8avB9Sd GRMut1Pvz7nQ4f92XG43+j93iuf1f5O5kv9r/HX2S/2fNiv+b/Bji6z1/0xXzP+ps+v/9ZNp cvs/940J+L/Ezwr/p6JGt5/n/2TjOf2f7vF/Cv/3z1DzpI4Lhf/D/62Eekpq/hRRjf9r/Kdj dLt/HPi8DT/k/BT/52e9U/1fWBBA/b8j/J8e7W1EpY0O04K7/F/vkWboFP4P/3ey/9Pj+f7P Tybg/2hnt7v/aw+MEef/jPi/9kfh/45v7izH/8XPe+P/0rPC/yUMK0r5v2bV/8nxUML/ydAF /7fhsDjf/1mF/9sWasX/NRlCNS+hVvyfX1CU0/91I/4vQ1b4P/zfa1b4v8RQ+L/YUK97EP+X YQfi/xJDVeb/bI//yxQK/4f/e96D+L/0UBfxfzrcCPF/WzzFov8b5SxK8n9tEFx/+b/x0e32 f3beFfR/Vdb/+4f/C2vL8X//nE+4mP/rjCzKyOj/Rl2j/1Mr/m/yk4CtnV3Gdvi/+TXQrSFZ 9H+Tv3AZa1OWFoUR4ChYbN3/hekE2c91+D+rR/F/XVL9v/bR+SMQ/xezA9Vp/k/rCf8XmdW1 /d/06Hb7v2nene7/buOl7P7PH+z1+T+L//t+/yf/jv/bMrbA/+H/VkLh//B/K6Gekpo/RVTj /6TwQeh2+r+nbTykXF3+rxvxf1myevZ/pmtvA21tpjCdtcv/We1mfEKn8H/4vxj/d7tu5fZ/ 3fn+r5tG/B/tA9rd/3UHxojzf634v/5H4f+Ob+4sx//Fz3vj/9Kzwv8lDCsK+T/drfq/I86r Zf93f0FTwv91B4S6kP/rOvxfHv+X9RpYyv9R/w//txoK/4f/ezss6vN/Df4P/7e+A/F/iaHw fwlZ4f8SQ13J//WjP7Txf1Gh8H/f6f/CdvF/WzzFv/yfHwcn+r/Q1en/rlb/Tz4Y/N+/5xNC 9TX8H/5vk/8b++z+b7X+3+iyxv+9h9rk/9p+MNn9n8L/4f98+zT/JxvH/y1M/Wz0f3336PYu MZ9vQz6rc/3f7XjI7f/cmscV/2dmyX2b/1Or/k8epkr4v8AF0vyfedmBK/5PrpFF/J/cB4vU /wvjbX+81uL/5PAu5P+aR7fb/zXzDv+n8H9/hFrJCv+3EeXh/zL6Py12T6f4v6dt1Or/bIP/ y5LVs/9r2/E2vtRtr2XIuc//jVP726mP8H9Grg/4v4UnkQ/zf22T3f/9Xi1O9H+jxf/RPqDd /V9/YIw4/9eJ/xt+FP7v+ObOcvxf/Lw3/i89K/xfwrCikP9T46r/k+F8Cf83yYukjCjP4v8O 8n9uNIr/2xSqQv9H/T/832qo2vyfnvB/qaEq9H/U/8P/4f9eQuH/1vxfO+L/MoXC/+H/nvcg /i89FP5v+8GO/1P4v6WVnO28q7L+n1s4j/+Ly4r6f1n93+28KuT/tMH/Jfk/t1xlxf/JZ/md /s+FWvJ/1ub2f3q8lP/TMh67dzv939sL7zL+73YU4/8iszrL/ym15v/G7P7PzQhex/81Fv+3 yf+t1/+Thyn8H/5v1krW/+sK+j/96Hb7Pz3v8H8K//dHqJWs8H8bUR7+L6f/8wsfQ7fX/823 Uav/u2eF/8vt/7rJPRSEQ2+X/xsa91uhm4XC/+H/FrJ69X/aZvd/jxs+/g//d+1293/2wBhx /q/3/q/TPwr/d3xzZzn+L37eG/+XnhX+L2FYUcr/mTX/d8h5tez/uvCVsVlR3or/MweEupD/ 690QMXQ7Q2nrX6aHzofC/0WGWrpaLPg/v+4wp/8bDP4vQ1b4P/zfa1b4v8RQ+L/YUK97EP+X YQfi/xJDVeb/tMb/ZQqF/8vt//xyIPxfVCj831f6PyXfT4v/2zLoXPZ/g3wyaf5PhoB/+j8Z CeL/Psb/qdX6f1a2i//D/81afv+nm/ED6v+F1Rhf6f9sV8z/mVX/Jzv0O/2fq+y64P9ud/jc /q/7BP83htMP//cc6tX/teOl/J8fAH6r/7NV+j9tzvd/TTn/10+z5L7M/7nvFljxf3JFKuL/ 5BSX17qJ/m+27nvJ/8mjXhH/J8tty/g/2Vsl/J88f+X0f+6Gv+z/5HG+hP8bw3cLpPi/+TaU wv8p/N8foVaywv9tRHn4v3z+T4/+sUOPtt0d6nkbfjnnx/g/sz/Ur/+TKzv+L/1t44L/M5Pb wbrtJ7M7lLbT1Px26jPq/8kXFVbn/3rp8H+vj90fV//Pjvg/2ge0u/8bDowR5/+s+L/2R+H/ jm/uLMf/xc974//Ss8L/JQwrCvk/tyjhbP/XNvi/r/F/pv/tdobSVh5kbPt7XuH/IkMtXS3w fwnvKPB/6aHwf/i/t8MC//cWC/+H/8P/rYaqzP9R/w//949QZ/o/Kycs/i8qFP4P//c7pYr/ c/+D/2vn3QPlVeT/9Gr9P/wf/q9I/b9Rn+//hi/2f+EIVG8N/7d2BD77PydQF/yfGXX2+n9+ FRP+L+6weHvhvej/3G/n9X/uFMb/xV3Zu3mH/4teYv5p9f+aqcP/bfF/ar3+H/4vzf9p/N/X +D/q/+H/8H/4v9VQT0nNnyLq8X9+qKRHu/8a+LwNN2Sq0f/dRQ/+L6//s4Px/m+UD2mn/3Ov J0OnPsL/BfiH/1t4EsH/3btD/Z/B/9E+oN3933hgjDj/N4j/638U/u/45s5y/F/8vDf+Lz0r /F/CsKKU/2tW/Z+MJ0rU/+sDRSzg/w4JdSX/52ahQ7czlJuVenQ+FP4vMtTS1aKE/3OvrvB/ yVnh/77A/6nJ4P9SQ+H/3mPh//B/+L/VUJX5PzPg/zKFwv/l9X+94Ab8X1Qo/N93+r9RruP4 vy2eYtH/yStG5a8ae/1fWFXRti+hXvxfGK/7lba7/V8/7wr6v3Ys5v8eoU70f/Lv+D/836wd 4P/6bs3/NdKV8H9BJuTzf7Zc/T9TzP+19kL+r9VDdv9H/b+j/F/vbp1Z/d/tdof/i8zqLP+n TZX+7/z6f/i/9R2I/8P/LT01bvN/8iHh/xZuIvg/3+H/toZayQr/txHl4f8y+r/Bj8RuD492 d6jnbajfSnl1+b9PqP8ns8bS7fZ/7bxz3912qv9rm8404v92h3Lwr/ntwhQJ/i9DVvi/7/V/ vZv4yev/ug7/R4ttd/83HRgjyv/ZRvxf86Pwf8c3d5bj/+LnvfF/6Vnh/xKGFYX8n+k+wP/J SyD834bD4mz/Z90zVeh2htLyviZ0PhT+LzLU0tWihP/rRvxfhqzwf/n9n3ypVs76fyP1/6LP q7fDojr/5xbR4f9iQ+H/Mj8f4P8SdyD+LzEU/u8tFP4P/4f/Ww6F/0tN61L+Lww6k/xf+LD+ 7f9aWWvcto3sP+kWQv3ruHha4OseHOvzf94p4f+isnqaTwj66ir+r5cPJnT7/J8Wo3PvbucV /i8u1Fn+r876f64C5YL/05MZs9f/U/i/g/yfW2pG/b/FUNv8X+N3Gf7vfeoH/5fV/xn8H/7P /2gz7/B/+L+3bSiF/1P4vz9CrWSF/9uI8vB/Of2ff+zQg213h3reRq3+z3T4vyxZPfs/fXvm MW6y1ib5PzesDZ3y34WD/8uR1TX8nxlz+z891uj/bndy/B8ttgX/1x5p7eL8n/b+r9U/Cv93 fHNnOf4vft4b/5eeFf4vYVhRyP+5wdKy/5PDooj/68JXxuL//jwsTvd/7t1H6HaG0tbPMofO h8L/RYZaulos+D+jMvs/6v/h/1ZD4f/wf2+HRXX+j/p/e7LC/2V+PsD/Je5A/F9iKPzfW6hv 838yj4D/iwqF//tS/xcmzfB/e/1fF15IJvm/8I3O7UuoV//XPSLu9n9hgW9x/2fNtfyfzFPg //49n9A2+L80/3c7r0r5P1Wj/wsVKNVbC/6vl+QS/V97D3UZ/2c6a3L7P3e1ON//yb/j//7w f7fDAv8XlxX+ry7/15vOZPd/F6v/14evZA7j7X1ji9fPasX/ydWiiP+T866I/5OBRBH/F64m /njF/+H/jg6F/8P/rYVayQr/99eTyLn+T/shqdbjsDvU8zYeoeryf59Q/0/L005G/9c1J/s/ 4yeXdNuH//dO/+e+4CF0bn7fnu7/zHSfcE0I9Xn+z6/kwP8tPHY/+T/TNaf7v6ZvVeb6f7dn YfwfLbLd/Z8+MEac/zPi/9ofhf87vrmzHP8XP++N/0vPCv+XMKwo5f/MB/i/QDeK+L/mgFBX 8n/u4T50O0Np671n6Hwo/F9kqKWrxYL/8zPP+L8N7yjwf+mhKvN/biYL/5cYqj7/R/2/PVnh /zI/H+D/Enfgsv/zLzHwf1tC4f/eQuH/8H/4v+VQ5/u/8I39+L/d/k/+FP9stdf/yTIK9XBK K/5Plkj4sedu//e2PrW++n+2x/9F7sDT/J/F/1H/T8n/Z9Z13afU/8P/vYV68X99t1j/b7T5 6//ZD/B/YblqXf6vc3wtq/8zDfX/vsb/jVX6P/dZnev/uj67/3PXQPxf4meF/1NRo1v8H/7P /Sj+bykr/B/+D/+Xyf+1/k4fup3+72kbj1D4P/zfQlav9f+G1t2oenn1t9f/+QVQ0vkfwv9l yQr/973+b5xaldf/uVD4P1pku/s/c2CMOP/Xiv/rfxT+7/jmznL8X/y8N/4vPSv8X8KwopD/ c5PRK/5PEEQJ/ycvgfB/Gw6Ls/3f4DYRup2htPWHXuh8KPxfZKilq8WC/2tUZv/XWvxfhqzw f/n9n7xczVn/zxr8X2qo+vwf9f/2ZIX/y/x8gP9L3IH4v8RQ+L+3UPg//B/+bznU+f5P9hb+ b4unWPR/QXil+b+wSgD/l6f+X/sB/k8ON/wf/m/Wvrv+X5X+b73+n1/GntP/deOF/J8x2ub2 f24Hnu7/xrAC6Xj/FyTKd/o/fw28kv/zx9x3+j9lq/R/p9f/s1qP2f2fWvN/klVt/k9uv0X8 n5WBdBH/JzenEv4v3D1K+D/TPrqK/J+soMb/4f/mSR0XCv+H/1sJ9ZTU/CmiGv/X+xUFuu/b 3aGet+HHFhX6v9voFv+XI6uX+n/N0Hj/Z2Q6a6f/cysMQjcLdar/C0dg0uR3M+/wf/i/f2T1 4v/Gzk384P9oZ7e7/2sPjBHn/zrxf8OPwv8d39xZjv+Ln/fG/6Vnhf9LGFaU8n/qfP8Xlt7g /zYcFqf7P7cDQ7czlLb+l0PnQ+H/IkMtXS1K+D/q/+H/VkPV5v+aEf+XGqo+/+eml/B/saHw f5mfD/B/iTsQ/5cYCv/3Furr/J/fXfi/qFD4vy/1fzJ7i//b4imW/J9sInR7/V94bO+al1Av /k9Gm9Lt9n+vHxb+7y1UDv8nS9Dxf3/MJ7QN/u9r6v+p0/1fLxO2vZ7C+7ld98a31ewL/k9P fulh6Pbe8YNTvHPFK9X/uz02Zq//564Wp/u/ISCtqvxf726dWf3f7XZ3Kf/n9xb+b2Hq58r+ zy/4LuX/7Cy5b/N/as3/jeEFQxhv7xtbvH5Wy/6vD1jf/9ix/k8eH8r4P9luXf4vfNdyEf8X XnHh//B/86SOC4X/w/+thHpKav4UUY3/M37IebtQ7B8HPm/jEaou/3dXjSf6PzNl93/mdP9n Tdt7/2e6vaG0ndxgPXS3n9H2fP8ns3P4v4UnkQ/zf4O1uf3f7IZfkf+7/ST+jxbb7v6vOzBG nP/rvf/r9I/C/x3f3FmO/4uf98b/pWeF/0sYVhTyf+0n1P8bwwsa/N+fh8Xp/s/NdIduZ6jb EMA8Oh8K/xcZaulq8e7/5JjL6f+6Ef+XISv83zf4v3HC/6WGqs//Uf9vT1b4v8zPB/i/xB1Y yv/NUR7+D//3Egr/l/Jh4f/SQ13G/8njFP5vi6dY9H9hsjuj/7NV+j9rivk/Zc/3f1JLBP/3 x3wC9f++yP99Qv0/Px67XSXCNPiue+PT1IWrKbdc/8/vMjOYhPdKagglhWQFprmQ/3ML6cT/ tfsvt1NvzKP7jPp/+L9t9f/McC3/5xcifqn/U1X6P9Od7/9sQf83zrpv83+r9f8K+r/wPreE /ztkfSr+L24HfqD/M49ut/8z8w7/p/B/f4RayQr/txHl4f8y+j9Z16ubadgd6nkbfoHW2f5P 4F9W/zdHefi/bP5P685aN1nbdLtDaTuOzW+n8H/4vxj/1/pRelb/52fOzvV/7ZTd/7ms8H+0 yHb3f/2BMeL8nxX/1/4o/N/xzZ3l+L/4eW/8X3pW+L+EYUUp/9ec7//updVL+L9uOCDUhfyf fz0Wup2htPXvQULnQ+H/IkMtXS1K+D/q/+H/VkPV5v+swf+lhsL/vcfC/+H/8H+roSrzf9T/ w//9IxT+L+XDwv+lh8L/bT/YL+3/1JTB/7VzwXXr1vxfWBr5lf6vYP2/gv7POaVF/xduT/i/ f88nOBKF/4v6rD6w/l8f1pjk83/GrPi/Nrv/M/i/yKvFtvp/7TDi/67r/y5X/w//h/8r4f/s mv974mt7/d/r40Eh/+cqOeD/4rLC/9Xn/2Y3gN3+7/Umgv9T+L9/hVrJCv+3EeXh//L5v9uV 3f+hw9DuD/W0DfdDNfq/2+gW/5cjq5f6f2a6XfV0201ST3un/3N3udAp/B/+72z/Z5rT/V/v Lsf4P9rZ7e7/7IEx4vzfIP6v/1H4v+ObO8vxf/Hz3vi/9KzwfwnDikL+z3Tn+z8T1h/i/77A /7nPKnQ7Q2nbj4/Oh8L/RYZaulos+L9B4f+WQ+H/7h3+b83/tT3+LzUU/u89Fv4P/4f/Ww1V mf/rO/xfplD4P/zf8x7E/6WHuoz/Cyuj8X+7/Z/Mf6f5P9lieHo3Y431/wr6v7Yt5f9uR/Ga /5MU8H/4v1k7wP9Zc379P3ltgv9bGAjO/Z+bJbmO/7M6e/0/jf/7Gv+n7MX8n7974P/ep35O 83/a4P8WdiD+71L+Txf0f/bR7fZ/Zt7h/6Kvgfg/6fB/W0OtZIX/24jy8H8Z/Z8VdjU0en+o p22oXylXl/9rLf4vS1Yv/q+3U+/9n90dysG/5rdT+D/8H/6v7V1Vefwf7ex293/DgTGi/N/t //b+r/lR+L/jmzvL8X/x8974v/Ss8H8Jw4pC/s+9Zjzb/7WNvF/E/32+/5vcM1XodobSVlaf SOdD4f8iQy1dLfB/Ce8o8H/poWrzf9T/w//538L/Kfzf1h2I/0sMVZn/GzX+L1Mo/B/+73kP 4v/SQ+H/th/sF/d/ssCxiP+TP+U7/d/twbGU/7NNsfp/tlnxf4GF4v/+PZ/QWvzf1/g/Vc7/ jR/j/2w4bdP8n8zDXcr/TUN2/0f9P/zfh/o/Waj8rf7PVun/6qz/p1b9nxyhX+n//BG47P9k cFbE/7WzHXis/+vkcMP/7fR/Vq4PZfyfLKbD/+H/5kkdFwr/h/9bCfWU1Pwpohr/N/iJ4dtT VoL/e9qGe2ys0f/dqxqe6f/G7P5Pn+7/xvZ2w3f+r+n2htJ2tO1vpz7C/wX4h/9beBL5NP/X dtn934j/w//RfLv7v/HAGHH+T4v/Mz8K/3d8c2c5/i9+3hv/l54V/i9hWFHK/5k1/ycToEX8 nw5fGYv/+/OwON3/uXcfodsZSlv/pBg6Hwr/Fxlq6WpRwv8NBv+XISv83zf4v6HF/6WGwv+9 x8L/4f/wf6uh8H8JWeH/EkNdyf9Z7Z/A8H9RofB/+L/fKdVL+b/7tKPbyG7/F0aT4TpQpf8r WP9P2fP93xjWluP//jmfgP/7Iv9XsP4f/u97/N/tYW7B/7W6H+v0f3KXxv/94f/aEf8XmdVZ /s+98Mb/RWWF/yvk/2QOpYz/m+/Ag/2fHIFF/J/cB4v4v9lsAv7v32ML/B/+byUU/g//txLq Kan5UwT+bxbqxf/dK+XV5f/uVQ3xf1n9X9sM0+j83zjuDuXgX/PbKfmKJPxfhqzwfzv9H/X/ 8H80aXf/Nx0YI87/GfF/3Y/C/x3f3FmO/4uf98b/pWeF/0sYVhTyf24y+nT/J+8wyvg/e0Co K/k/N/Mcup2htPV7P3Q+FP4vMtTS1eLd/zXZ/V+P/8P/rYWqzf91Fv+XGgr/9x4L/4f/w/+t hsL/JWSF/0sMdSn/J29q8X9RofB/+L/fKdUr+j+/6xL9X3ufVqzR/xWs/9e2xfyfWvV/sl38 H/5v1g7wf21/vv+TkURO/9fpUv4vHIHqreH/1o7Abf6va7vc/s85pdP9X1iuWsD/3eFfCf/n xhZ5/V/fXcv/+WOuhP/zkyh56/+pKv1fa0/3f92Y3f/ZKv2fwv/h//xnhP/D/20Nhf/D/62F WskK//fXk8i5/s/KI/PgR7Q7Qz1tw/1Qjf7vXtUQ/5fX/7XTbaCd1/9R/w//d67/c1OP+L+4 UPi/Slvwf92R1i7O/7Xe/7X9j8L/Hd/cWY7/i5/3xv+lZ4X/SxhWlPJ/as3/heOhhP9rsqM8 i/87xP/1jRvRhm5nKG3t8Oh8KPxfZKilq8WC/+sV/m85FP7v3uH/1vwf9f/wf/638H8K/7d1 B+L/EkPh/xKywv8lhsL/RaaF/7t3+L+P9n+THAP4vy2eYtn/BY2D/3sNdVr9v3L+z4GUZf83 yAeD/8P/zdoB/u92XuH/4kKd5f86cyX/Z3V2//cR9f/wf/i/Jf/nssL/LUz9nOb/tKnR/6kq /R/1//B/8hnh//B/W0Ph//B/a6FWssL//fUkcrL/k8cHKw/BO/3ffBvOAdbo/+6iB/+X1//d noVd/T/byaG3y/8NjXuwCp3C/+H/TvZ/esT/4f9ovt39nz4wRpz/68T/DT8K/3d8c2c5/i9+ 3hv/l54V/i9hWLHs/2xu/+fe057t/8wYXtBkRXn4v8RQy/7PDTNDtzOUtn4mO3Q+FP4vMtTS 1aKE/xss/i9DVvg//N9rVvi/xFD4v9hQr3sQ/5dhB+L/EkPV5f90M+L/MoXC/+X1f/0o3x2L /8P/rYbC/+H/Qivo/+aDzt3+r335sPB/b6G2+z9Popb9nxwW+L9/zye4qXb8X9RndZr/06ZG /xeOQPXWgv/rJVSi/wsvcz7A//Uy/53R/7XDov8b3ZNihfX/xrACCf/3HOrq/s8vRPxS/2er 9H/us6rO/7lr4LL/u99r/F9Uj/+TwVkR/9fNuoP9n2y3iP/rH93R/i9MjhTwf/JAUMb/yT2x hP+Tucc0/zffhlL4P4X/+yPUSlb4v40oD/+X0//JgCDN/8234X6yRv83dh/g/8I0cT7/p/qz /d/Y3O7uup3CjWqf//PXmNCpj/B/ZgpHYNLkdzPvPsD/2dEvZarM//Umt/+b3fDxf/i/a7e7 /zMHxojzf733f53+Ufi/45s7y/F/8fPe+L/0rPB/CcOK8/2fPF6X8H8yf4f/23BYnO7/3Ex3 6HaG0jKhHTofCv8XGWrparHg//y6w5z+z3b4vwxZ4f/wf69Z4f8SQxXyf27EhP+LDYX/y/x8 gP9L3IGl6v/1Hf4vUyj8H/7veQ/i/9JD4f+2H+zX9n9yjuP//ljgq625lP+zYW05/u+f8wld 0+H/4j6rF/93O68qrP9n+k+p/4f/e8dDm/xfP2av/4f/+x7/577j51L+z9898H/vUz/4v6z+ b7yY/5MlF5X5v0PWp57u/0Io/B/+D/+H/3s5LPB/+L/3rN78n5xJ1j9m7fV/8224US7+byEU /m+l/t/tocj5vzbF/7nBeOgU/g//h//D/9E+o939X3tgjDj/Z8X/tT8K/3d8c2c5/i9+3hv/ l54V/i9hWHEl/xfWH+L/vsD/udFo6HaG0nZoH50Phf+LDLV0tSjh/3qD/8uQFf7vG/zf2OH/ UkPV5//aBv+H/1vfgfi/xFCV+b9R4/8yhcL/ZfZ/sjgQ/xcVCv+H//udUr2U/7PB//mFHXv9 Xzfv1v1f+LGU5ZXv61Op/xd1WGz0f70c2fi/f88ntB3+D/+n5P8z6y7m/8KCqqr8X+du8Xn9 nzsC8X8xO1Bt9X/u1pm3/t/tGf9K/s+zi2/1fwr/h//zP/r6LFfK/6kP8H+TnnV7/V877z7B /5nm0e32f08PPfi/g/2f7xL9X+jwfwr/90eolazwfxtRHv4vp/+z/iYy6IRx4NM2VKX1/wZT pf9rzvZ/7ThJ/T95PNjr/4bfTsnkN/4vQ1YX8X9jdv9nz/d/nZtwzer/bndy/B8ttt39X3dg jDj/N4j/638U/u/45s5y/F/8vDf+Lz0r/F/CsKKQ/3PvaZf9n6yNKuL/7q+M8X9/HhZn+z// Ci50O0NpK69cpfOh8H+RoZauFgv+r1X4v+VQ+L97h/9b83/9gP9LDVWh/7P4P/zf+g7E/yWG wv8lZIX/Swx1Kf8nqy/xf1Gh8H/f6f/G8N4U/7fb/8kexP/h/+axZNky/u+P+QT8XwX+r5Xj Iaf/m31WT6G+2v+575W8jP8z0zDm9n/u+75P93+DZI3/+7f/u1j9P8Fk+L+FqR/8X07/Z7o1 //dUvq4a/ydHaJn6f3K1KOH/wkNPwfp/RfxfmBxJ8n9ynf3L/8lKnRL+Tw7vMv5vah/d3mvg fBtK4f8U/u+PUCtZ4f82ojz8X07/1/trq/UTaHv933wbqtL6fx/g/1q54Vfl/27DiNutU7fj 1Ju9oZxHm3479Rn1/8Yq/Z/1z0b4v4VFqnP/d/tJ/F9kKPxfpe3u//oDY8T4P+P+//p2Zugf hf87vrmzHP8XP++N/0vPCv+XMKwo5f+aD/B/8hII/7fhsDjd/7lZ6NDtDKWtfycVOh8K/xcZ aulqUcL/dQ3+L0NW+L9v8H/U/8P/+d/C/yn839YdiP9LDIX/S8gK/5cYCv8XmRb+797h//B/ Vfu/PoP/M+ERK+zIVf8nSyTS/J+kg//L4v/ca/Vl/xfKQuL//j2f0DX4vzT/dzuvKvR/tpj/ cyjvX/6v6+RgT/J/0n1E/T9/eGf1f3pc9n9ddv/XfkL9v7BctYD/C5TnO/3fxer/ycbxfwtT P6f5P23O9n/NaHL7v261/l+l/k9EQwn/F6ZrSvi/Vg63Iv4vzFj40e2x/q8JQyV/vCb6v9/L 7bL/k6O8SP2/RhbTFfF/s9XNu/3ffIW0wv8p/N8foVaywv9tRHn4v4z+b5BpMul2hnrahh8H 4v/eQ+H/Fv3fONyOOef/5Jlqr/+zv536DP833Nc2J4TC//123+X/FPX/8H80aXf/Zw+MEef/ tPi/9kfh/45v7izH/8XPe+P/0rPC/yUMKwr5P/cVeyv+T/69gP8LS2/wfxsOi7P9n3HPVKHb GUpbP1seOh8K/xcZaulqUcL/mRH/lyEr/N83+D/q/+H//G/h/xT+b+sOxP8lhqrM//Ud/i9T KPwf/u95D+L/0kNdxv8FxoT/+xz/p7pL+b/5MvY8/s825/s/+bZl/N8f8wn4v1T/R/2/Y+v/ ZfR/jm4s+79wOf5O/+dCLfi/YeiqrP83hhVI+L/nUK/+7/aMj/+Lywr/l9X/me50/zfY7P7P rPm/ISyk9n9RNf5PSvmU8X/h9lvC/4W3aSlPIhv9X1Ou/l+4UZXwf2GfFPF/8iHh//B/86SO C4X/w/+thHpKav4UUY3/szKLMPg75N76f/NtPOxLXf6vG/F/WbJ68X9Dc7vq6XYcxyT/p387 hf/D/53s/3Sd9f8M/o8W3e7+bzgwRpz/M+L/+h+F/zu+ubMc/xc/743/S88K/5cwrCjk//T4 Af6vCy9oCvg/e0SoK/k/9+4jdDtDaeuff0PnQ+H/IkMtXS2o/5fwjgL/lx6qNv/XNvi/1FD4 v/dY+D/8H/5vNVRl/o/6f/i/f4Q61f/JExj+LyoU/u9L/Z8sz8P/bfEUy/5P/pTR7Zvd/k+G eAFyrfu/MBJMWV5593+vWR3t/8yjquHh/q9c/T9Popb9n6SA//v3fELb4f/wf0r+P/PuWvX/ qvR/vc3t/9Qn1P/D/23yf7fbHf4vMiv8H/7v/dXws//zU+34v7TP6nT/d8j61JX6f5JCCf9n wuRIygMq/g//tzkU/g//txZqJSv8319PIifX/xPeJt3e+n/zbTxC1eX/qP+X/rZx2f/dRr/O /0k6O/1f3/526kP8n0xYVOb//NoE/N/CY/cV6v/h/2jx7e7/xgNjxPm/Vvzf8KPwf8c3d5bj /+LnvfF/6Vnh/xKGFYX8X7fu/0QKlfB/Wl4k4f++wP+53w7dzlDayjtrO/5emPB/kaGWrhb4 v4R3FPi/9FC1+T/q/+H//G+9LaLD/8WGwv9lfj7A/yXuQOr/JYbC/72Fwv/h//B/y6FO939T mDTD/32Q/2tq9H9NU8z/KYv/i9yB1P/D/y19Vu28W/d/cvv4Sv9XsP7fuv8LWVfl/9o2u//z 32J+Hf8X5MF3+j/q/x3l//o2u/+zVfo/91md6//aocnt/xT+D/8nG2nmHf4P//e2DaXwfwr/ 90eolazwfxtRHv4vp/+Ty+3gH7v3+r/5Nh72pS7/N3bn+z+Zesnp/8xwtv9r9dh4/xeGSjv9 n/7tZqHwf7n9n398wP8tPHZ/mv/rpuz+zxXqwf/RItvd/00Hxojzf533f53+Ufi/45s7y/F/ 8fPe+L/0rPB/CcOKK/k/0Xj4vw2Hxdn+z49oQ7czlLZ+AVnofCj8X2SopavFgv/zC0hy+j8z 4v8yZIX/y+//Rrmy5/N/7pus8H+Joerzf9T/25MV/i/z8wH+L3EH4v8SQ+H/3kLh//B/+L/l UPi/1LRO93+jDN/S/N/01K3V/wtLSjohBzv9n513dfq/T6j/J3Oq+L8/5hPwf/i/KP835fZ/ 7mXPov+bjAttTJOCh4KvGWQtjrmQ/9O9Nbn9n/usTvd/NnxIx/s/mfH+Vv/nTuEL+b/G7zL8 3/vUz6X9nwuV1/+pVf8n18Dv9H921f/JUqYS/i9ImBL+T9Ip4//Cxc+Pbo/1fyGFEv5PLn4l /F84LPB/Cv83T+q4UPg//N9KqKek5k8R9fg/eVwchhT/N9+Ge2ys0f/dRc+p9f8kq4z+T7cn +z/dTbc7lG7HQcZoO/2fewgOnftnfbr/C/AP/7fwJPJp/m/M7v/c1OPp9f+G3P7PZYX/o0W2 4P/6I61dnP/rpf6f+VH4v+ObO8vxf/Hz3vi/9KzwfwnDiiv5v+4IlIf/Swy17P/cMDN0O0Np 62evQ+dD4f8iQy1dLfB/Ce8o8H/poSrzf3qc8H+pofB/77Hwf/g//N9qKPxfQlb4v8RQ+L/I tPB/9w7/99n+LxQHwP/h/2Ytv/9zTqmU/7MN/i9yB57m/yz+L83/DW0p/3f7yfP9n9T/s7PL 2A7/N78Gts1a/T+b2//9o/5fmE6Q3V2H/5uaDv+XWP9vnHeH+j+31Cyv/zMD/i8yK/xfVv+n zen+b5zwf2n+T+Zhivi/8D63svp/pnl0R9f/ax8d/u/fYwv8H/5vJRT+D/+3EuopqflTRDX+ z8qnM7Tt/lBP2/DjwAr931014v/y+r/RTK3zf/1k9obSQ+sXQEmn/Lem4/9yZHUR/2dy+7/2 /Pp/+D/aZ7S7/9MHxojzf1b8X/ej8H/HN3eW4//i573xf+lZ4f8ShhWF/J8bLJ3t/8wY/pQC /k9el+D/tqwwX/R/bqY7dDtDaSsLTe19igf/d5T/8zPP+L8N7yjwf+mhKvN/1P/D/y34PzcR g/+LDYX/y/x8gP9L3IH4v8RQ+L+3UPg//B/+bznU6f5vDO9N8X97/d9Q0P+FhfNf6f/GqcL6 f55ELfq/Xi6u+L8//B/1/xL9Xz8s+79WFEnO+n+qRv/XGfxf5NXixf+ZYdn/mVD/L+FdxdT7 Ioyhu52AH+D/wimO//vD/92e8S/l/1rflfB/TXb/1+L/vsb/Wfwf/s//aDPvLub/wm/j//B/ +D/830Kolazwf389iZxc/0/uUEn+72kbt75K/3fPCv+X2f+5spH6dpGQqbud/s8dgaFT+L8D /Z8/yvF/C4tU8X/4P9pCu/s/c2CMOP83iP+zPwr/d3xzZzn+L37eG/+XntWp/i8MnvB/n+// wjeH4P82HBZn+7/ODRFDtzOUtv6lX+h8qPP93zDr8H/4v4Ws8H8f7f/k5Wqi/5NLeqj/Zw3+ LzVUff7PfYk+/i82FP4v8/MB/i9xB5byf2bA/2UKhf/L6/9sWJuP/8P/rYbC/+H/QsP/fZz/ e2R1nv8b5IPB/+H/Zq2g/+tkVh//98c10NWUK+T/3HKVFf8nl4mq/F/fBP+XsOJs6v2/hc7v QPxfzA5U+D9Vxv/JzeFL/Z/C/x3j/0x2/+e/aq8+/6fW/F/QV0X8n5ziJfxfFwZvKU8iG/1f 2G4J/6fDeNsfr/g//N/RofB/+L+1UCtZ4f/+ehI5u/6fv7YO/nK7u/7fbBuPSnl1+T/q/6W/ bVzyf52bG9HtGJLb5/+MOwJDp2TyG/+XISv83z7/52fOqvN/bqE+/o8W2e7+rz0wRpT/0434 P/2j8H/HN3eW4//i573xf+lZ4f8ShhWl/F/zAf5PRrRl/F9zQKgr+T/3DiN0O0NpOw2Pzoc6 3/+FzxL/9/Zo1c06/B/+D/93zGGB/0sMVcr/Wfwf/m99B+L/EkNV5v+o/4f/+0co/F/Kh4X/ Sw+F/9t+sF/c/0naaf5PthgglzY1+j9rivk/B1LK+D9XtmTZ/1m5uOL//u3/2g7/l+b/2uZ0 /9fJp/Od/s9NXfzL/931VZL/kw+6Uv/nQi34v9GOuf3fPav3D6ug/wuLsgr4v0B5ivg/d+vM 6v9uf/W1/J+RDv/3OvWz0f9146Pbu8R8vg33B9Xo/8Yq/d9q/T/8H/4P/4f/WwyF/8P/rYVa yQr/99eTyMn1/zr/n/L+ZW/9v/k2avV/94peZ/o/oTw5/Z+yZ/u/0Y6D8386zM7t83/uG59C Nwt1ov+TZ3r839KTCP7v3uH/8H/Vt7v/6w6MEef/jPi/7kfh/45v7izH/8XPe+P/0rM61f+F Ndv4v3/7P9N9gP/rwgsa/N+fh8XZ/s+vfQ3dzlB6aJpH50Od7//CKV6X//NvZrL6P/c+Cf+X nBX+7wv8nxo1/i81VH3+T+H/8H/4v5dQ+D/838KP4f/wf0tp4f/wfws/hv/D/0n7av9XsP5f Qf+n8H9J/k/ZBv8X91l9Xv2/A/yfLeb/3MueJf93uyDl9n963f/JDq3I/6lxMuL/wkh6p//z pCB03r6c7v96CYX/w/89+b/x0R3s/yz+78L+r8r6f/7WiP+LG8Y08w7/V4P/mx7dbv83zTv8 n8L//RFqJSv830aUh//L5/+0vGYM3b5Qz9t4hKrL/00W/5clqyf/dxvMNrcRk24H0yT4P/8h hc5NItkP8H8yaYP/+3z/5++7Wf2fK2lztv/r29z+z4XC/9Ei293/9QfGiPN/rfg/+6Pwf8c3 d5bj/+LnvfF/6Vmd6/8k68r8X5Pb/7nXjGf7PyMvgYr4v1D1EP+31/91/W+3M5Qe5CWPdD4U /i8y1NLV4t3/+ZsD/m/LOwr8X3qoj/B/YVVqmv+TP5H6f/g//1vP9f+6Dv+H/1vdgfi/xFD4 v4Ss8H+JofB/kWnh/+4d/u+z/Z/M3uL/tniKRf9nZcLGLyne7f+CEgvTimv+r52tbq7H/0ny X+r/Vuv/9XIW4f/+7f/cugT8X9Rn9eL/xm7F/8m5W8T/ddn9X3t+/b/JeP/X3NfP71taJOem laef8QP8n78GZvV/7nK74P8Gbbz/s+P+y+0k8x2hu5z/k6/sL+H/usbm9n9tfyn/1/hdVsL/ +btwGf83+o2Hbrf/s7POjZhK+T89nuz/+mEYsvu/q9X/k5ezJfzfEORUAf8XHnyL+L8wY+FH t8f6P9M+Ovzfv8cW+D/830oo/B/+byXUU1Lzp4hq/F8nmEzcyk7/97QNP7ao0P8NBv+XJasX /3cbtHfu6dVKOrv8n5369rdT+D/8X5T/6/PX/xvP93/D5M4J/B/t5Hb3f/bAGHH+r/P+r2t+ FP7v+ObOcvxf/Lw3/i89K/xfwrCilP8zH+D/wvpD/N8X+D/326HbGUoPfj1c6Hwo/F9kqKWr RQn/Zzr8X4as8H/f4P/aHv+XGgr/9x4L/4f/w/+thsL/JWSF/0sMhf+LTAv/d+/wf/g//J/6 Y3kl/q82/yerLfB/C/MJT/6P+n9H1f+Tgz2n/7M1+j/3smfR/402t/9zB/tl/N/Ud434v2b/ ETj1fpAaut+s3j8s/F+i/3O/ndX/uWf8S/k/X3LkS/2fLef/FP6P+n9+X2ys/4f/w//h/7bv QPyfdPi/raFWssL/bUR5+L+M/k/7r90J3U7/97QNv0CrQv83dvi/LFk9+7+ps7cnfN124flq n/8b3LA1dMqvmsL/5cjqGv6v7fB/W/yfm1DF/9Ei293/DQfGiPN/vfg/86Pwf8c3d5bj/+Ln vfF/6Vmd6//C61z83+uj1ZP/c8OK0/2fCS9oSvi/4YBQV/J/buY5dDtD6UG+P1Q6Hwr/Fxlq 6Wqx4P/8ApKc/q+1+L8MWeH/vsH/jRP+LzUU/u89Fv4P/4f/Ww1Vl//TzYj/yxQK//fx/s8M +L/UUPi/xFDL/i9IHvzfFk+x6P8CB8D/fY7/e2R1tP9zy5ZX/J+kgP/7w/9R/++o+n/5/Z+q 0f+t1v8T/6cneRGT6P/MPVSF/q/vFvyfblor9f9SvhZx6v0wIXS3E/AD/F8nR09l/o/6f6n+ z993v9P/eX2F/0s7r073f+H9fWX+T+6gRfxfkDBF/J98MCX8X3PfwUod7f90GG/74/VQ/9dP PlQZ/ydjjyL+L9wAkvzfbBtK4f8U/u+PUCtZ4f82ojz8Xz7/dxtM+O1ObUKop2244eDp/u8+ 9Zjm/+QG90n1/+QpIqf/a8/1f7q5JeX8X9vJfX+f/7MundCpD6n/FwRq0uR3M+8+wv/5+ZfK /J/JX//PfID/cxM/Wf2fU434P1pku/u/8cAYcf7Piv/rfhT+7/jmznL8X/y8N/4vPSv8X8Kw 4kr+rw9/SgH/J19hjv/bssJ8yf9Zt4nQ7Qylh2Z8dD4U/i8y1NLV4t3/Ndn9n8b/4f/WQtXm /6zB/6WGqs//mRH/h/9b34H4v8RQdfk/6v/h//B/r38S/g//t/Bj+L/P9n8hhttru/1fO+/c VyAv+r/AQ77T/1lzqfp/Vs4i/N8f/o/6fxXU/5M/NKf/0/2H1P/D/72H2uL/1DR0nfd/3ZhQ /6/zl5rQ+SPwdP8XBhUF/N8d/n1n/T93DbyS//N3j+/0f4r6f1/j/9w3Jqz4v7CQ2v9F9fg/ uXsU8X9Bdif5v/B+/vcauOL/JOsi/q8LO1ipw/1fWIXtj9dj6//JYVHG/8k9saT/c12q//v9 rPB/Cv/3r1ArWeH/NqI8/F9G/zfIxNAw2v2hnrahPqH+3wH+zzbn+z8ZNWf1f825/k9NQ2Pd jcoYOfT2+b++HX47JTPSZ/u/8f6FawmhPtD/+fOlMv/nZ3yq83+9WyuWt/7f2OH/aLHt7v+m A2PE+b9B/J/9Ufi/45s7y/F/8fPe+L/0rM71f0csJa7P/7nV7Kf7v7D+EP/3Bf7PDTNDtzOU HvwwM3Q+FP4vMtTS1WLB//mZZ/zfhncU+L/0ULX5v6HF/6WGqs//dQ3+D/+3vgPxf4mh8H8J WeH/EkPh/yLTwv/dO/wf/g//p/5YXtnOuzr9X5X1/5Ra9X+yXfzfv/1f0Ff4v93+z46n+79W joec/k8Vq/9X0P915jr+7za6HBrxf32S/xsenf++79P9n7zlwf+9hnr1f7fDAv8XlxX+D//3 /moY/6fwf1vWp+L/4nbgs/+z+D/83x+h5kkdFwr/h/9bCfWU1Pwpoh7/Jy92xpT6f0/bUJXW /8P/pb9tXKr/Z6fbSOx2oxrM7lDadm7+N3TqM+r/Ver//C23Mv/nrw95/d9Yo//rOvwfLboF /2ePtHZR/s803v+1zY/C/x3f3FmO/4uf98b/pWeF/0sYVpTyf+Z8/9c28n6xhP+7KxH835+h lv2fG42GbmcoPfg3BqHzofB/kaGWrhb/s3e3Wa6q6hqGqyk0QVBRe7X6/2sFXlIxFZ0RQUzw 5oxx2HvPKp/C+IHIFfB/Ce8o8H/pUbX5v87i/1Kj8H+vWfg//B/+bzWqMv83avxfpij8X17/ 18vxltP/6Rb/lxqF/0uMwv/FRm3zf10YNUvyf9LFe+v/5Me+0v/5KRAXWv8vPPvi//B/s1Kn /+v6iv3fGGRIkv+776Aq/Z+73C75P23F/yXgoanz8z9D9Rn+r5OoAv4vUB7834axs7P9X+Pv iV/q/7TB/1Xg/+QILeD/Bv9ckNP/uTV6VvyfiIYS/i/8KbIDE/3f701k2f/Jp1PE/4Wx7hL+ zzSzqL3+r5lXq/5PjtCc/q9d83+9TA8o4v9ms5t3+7/5DGmF/1P4vzdRK63C/21Eefi/nP6v 8dfWoU/oBz5t4yHlPsH/JUQ9oxY1GPxfllb99X/9pN2NKgwL7vR/7uVaqGZRp/o/GbDA/328 /zOTwf/h/ygHlbv/0wdmxPk/Lf7P/Cj83/HFneX4v/hxb/xfeqvwfwndikL+79ZvP9//aXmR hP/7fP83uMHqUO2M0oN/GRUqH4X/i4xaulqU8H9mxP9laBX+D//3t1X4v8SoQv6v7fB/+L/1 HYj/S4yqzP+ZAf+XKQr/h/973oP4v/Qo/N/2gx3/p/L6v2bF/4X+epr/kwzW/8vi/25H8Zr/ k3/H//3b/7UW/5fm/zqN/4uMOs3/XWn9P930Y3b/Z/B/3+L/bn81/i+yVVfwf7ac/1O2Qv9n Ovwf/s//aDOv8H81+L/hUe32f8O8wv8p/N+bqJVW4f82ojz8X07/J2eSVHv933wbrpd7vv+T Lmea/+vkrhP839jh/7K06o//m6Z2ut2omjHF/7X98Fupj1j/L8A//N/Ck8gF/J+p0v+NDf6P Elvu/s8cmBHn/4z4v+5H4f+OL+4sx//Fj3vj/9Jbhf9L6FaU8n/NB/g/mUCC/9twWJzu/9wo dKh2RunBe89Q+Sj8X2TU0tXixf+ZMbv/U/g//N9aFP4P//dyWOD/XrLwf/g//N9qFP4voVX4 v8Qo/F9ks/B/9wr/h/+7hP/zk4gT/Z/5E7Xs//ztONX/PWZbFPJ/1lS4/h/+j/X/8H/4v23+ z2HX6/g/ozvxf2b/ETjJ4RsqvwPxfzE7UJ3m/24PaFfyf9rvrSL+r3dXpKz+z80lrtH/NRX6 Pz2u+b8w2vCd/s89DC/6vzDNp4T/k98u4v/kGljE/zWh/+J7t8f6Pz3Ooqrxf4M8zhfxf9Oj 2u3/pnmF/1P4vzdRK63C/21Eefi/jP7PyqJ9Q5NgoJ+24boQNfq/e6vwf1n9n9b9rTlOKdnd UbdrjGl+K4X/w/9F+b/R4v/wf5SDyt3/tQdmxPm/Vvyf/VH4v+OLO8vxf/Hj3vi/9Fbh/xK6 FYX8nxk/wP818n4R//f5/m90z1Sh2hmlBxk0Hx6PVvi/yKilqwX+L+EdBf4vPao2/ze0+L/U KPzfaxb+D/+H/1uNqsz/jRr/lykK/4f/e96D+L/0qKv4v/ugGf5vr//rA3op4f/Ci9Mk/xfG jx6zLVj/L+qw2Or/5IPB//3b/7H+X6r/s2Mp/6dNOf9ni/m/cASql8L6f2tH4Db/12qb2/+5 ta/O938BaR3v/+7wD//3Df7P33fxf69DP6f5P23wfws7MIP/8zeRrP7Prvk/6UAV8X+Dne1A /N8n+79eerc5/Z/u8H8K//fPqHmjjovC/+H/VqKeGjV/iqjH/8klfdAJ18CnbdTq/2yD/8vS qj/+z4y3hyndNvLqb6f/M+72GyolQyT4vwytevF//pzA/y08duP/8H+UpXL3f92BGXH+r/P+ r2t+FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FKf9nPsD/deEFTQn/d0TUlfyfe/cRqp1RejDto/JR +L/IqKWrBf4v4R0F/i89qjb/pyf8X2pUff7PfWMC/i82Cv+X+fkA/5e4A0v5v77D/2WKwv9l 9n/ypjan/1MW/5cahf9LjML/xUZt9H9h1KyE/5P/Wpn/k41/5/p/qsP/4f/8z5/l/+pc/w// d5T/8+vVZvV/uln0f7ppxP/p/ZfbqfMWKlReoOL/YnagOs//3e7Cl/J//mpRm//zJ1FW/9de yv9NfW7/5w92/F/aZ4X/U3EPqE8PPfg//N+fbbxGzZt1WBT+D/+3FrXSKvzfuyeRz/B/Sev/ zbfxSf7PTAlzl+/+rwtTrS3+L0ur/vi/Zrj1A3Xr+MbeKG2N6/eHynX3evxfllZdxP81+L8t /s+N3eL/KJHl7v/6AzPi/F8v/s/8KPzf8cWd5fi/+HFv/F96q/B/Cd2KQv7v1qs83//18o4V //cF/s/9dqh2RulBLlrDY4gd/xcZtXS1KOH/3KwO/F9yq/B/3+D/Oov/S42qz/91Df4P/7e+ A/F/iVGV+T/W/8P//SMK/5fyYeH/0qMu4//Ce1P8327/FzJK+D+ZIoH/+xj/t77+n5WzCP+H /5uVr17/b9aq5+vSV/u/zuD/Iq8W2/yfGW1u/+e+7/tC/k9Nxfxf6y5cWf2ftuZS/s9fhb7V /9kG/xfXqm3+b2w0/i/J/2npaOP/NsxPxf/F7UD8n6/wf/i/pVbh/zaiPPxfTv8nZMqO7f6o p208pBz+D/+30Kq/6/+Ztrt9AtOkzd6o27NvO/1Wt5/RFv+XpVX4v53+b8T/4f8ovtz9nz0w I87/WfF/3Y/C/x1f3FmO/4sf98b/pbcK/5fQrbiS/5OpNzlRnl31fzp31MX839D/Vjuj9ODf EIXKR+H/IqOWrhav/s9m938K/4f/W4uqzP+ZpsH/pUbh/16z8H/4P/zfahT+L6FV+L/EKPxf ZLPwf/cK//fZ/k/2Fv5vi6dY9n+hB1PC/82exFL9398o/N8u/2ca/F9kq578X9BX+L9v8H+r 6/+Z7P6vxf8tXNm/yf8ZPRnv/9qEI3DqpvZR4f92XG7P8n9XW//vq/2fqtL/me5k/2eblvX/ tvk/hf/D//nPqJlX+L/oayD+Tyr839aolVbh/zaiPPxfRv83yrOyVDujnrahKl3/bzD4vyyt evZ/Rrv1MPTtk+p2Rzn41/xWSkak8X8ZWnUN/zd0uf2fk3In+7+uG3L7PxeF/6NElrv/Gw7M iPN/g/g/+6Pwf8cXd5bj/+LHvfF/6a3C/yV0Ky7k/8wYXtBkRXn4v8SoRf83Nf1vtTNKD/50 C5WPwv9FRi1dLRbW/3Otwv9teUeB/0uPqsz/sf4f/g//h/+L3IH4v8Qo/F9Cq/B/iVGX8n/W /6X4v6go/N+X+r/AmPB/e/1fF6JK+L/w4hT/9+9D8CP8nxzZ+D/836xU6v/CIAD+D//3ezee bCPr/7UJk3AmOYqn+8H8Cf5P/tAy/i+c6QX83zDl9n/uGngl/zc+KvzffOgH/1fG/9k5X6vG /4U33SX8n+1nO/Bg/yeXhiL+b47yDvZ/dhZ1rP+Tgz2n/3M3/GX/J6YG/4f/mzfquCj8H/5v JeqpUfOniFr8n+6m4VHti3rexiPqTP8n96tE/zeEPeQ3ObH+3wH+7/bwdeu1O/9nZDhrn//T ro8aKsX6f/i/k/3fB6z/1zf4P8onlLv/Gw/MiPJ/bSP+T/8o/N/xxZ3l+L/4cW/8X3qr8H8J 3YoL+b9WvksN/7fhsDjd/7luZqh2Rt2eYJpH5aPwf5FRS1eLF//X+rfP+L8t7yjwf+lR+D/8 38thgf97ycL/4f/wf6tRp/o/f47j/7ZE4f9eor7N//X+RWRW/9fi/1Kj8H+JUfi/2KiN/i/0 YFL8X+hL4//q8X+9XFzxf/i/WcH/4f9O9n/+IC7g/4amlfX/moSvRZw6/20cobqc/wvPOPi/ L/B/jd9llfm/wd89svo/3a/4v3BPblP833wbbjP4v4Ud+GX+Tx6mivi/brYDj/V/4TJewv+F 7Rbxf90sCv+H/zs6Cv+H/1uLWmkV/u/dk8ip/s9o/9IkVPuinrfxiDrT/wnak3vUbv/Xz6qP 8H/yCqkq/2dHN0SijW3G3VG6H1w/IFQK/4f/i/J/fnZqdf5vaPF/lA8od/83HZgR5/+0+L/2 R+H/ji/uLMf/xY974//SW4X/S+hWlPJ/zfn+z8jzEP5vw2Fxuv+z/W+1M+r2BKMflY/C/0VG LV0tXv1fx/p/+L+r+D95a4r/2xJ1Jf/nbxv4vy17EP+XYQfi/xKjTvV/flIg/m9LFP7vJerb /J+8dMH/RUXh/77U/8n0PPzfFk+x6P/Cu9uM6/9ps+b/Zk9ix/o/E3RDCf+n50MXx/q/sMuK +L8wt7wu/9f4PwX/t3Cwb/J/3f07xf2uOdb/ybNpEf/XTLPGHev//C5r2ynl3ii7IVRuZsyK //OX9K5L8X8yd1wN0z3qdP/nD5sC/q+35vZIoLvbjkvxf/5dcqg+w/+FaWIl/F8Yaizh/5xX x/8tRm30f/79XRH/5ybQFfJ//vpVyP+F3m2S/5ttQ32E/3NXoUL+r58vX7fX/0nGO/8Xbo0l /J+MUhTxfwHrF/F/0oQi/i+MWPje7V7/J4fFO//XTLOonQ+o7fxpRq36PxmlK+L/rDzOF/F/ 4QaQ5P9m21AK/6fwf2+iVlqF/9uI8vB/Gf2ftdOj2un/nrbxiDrV/8mM7DT/J/fSz/F/4dG+ Kv93u5KPg7uZd924N+rWr3NdulCpj/B/RgYCq/N//iivy/9pa2v0f/6rXLL6P9Ph/yjRJfi/ 4UhrF+f/jPd/bfej8H/HF3eW4//ix73xf+mtwv8ldCsK+b/uE/yfDEbj/zYcFqf7PzfSHaqd UbcnGPOofBT+LzJq6WqB/0t4R4H/S4861//JVAv835ao6/i/fpTxWvzfhj2I/8uwA/F/iVFn +j/rD/as/q8d8H+ZovB/mf2fmBf8X1QU/g//9/s0fCn/1wf0kuT/JOO+/p893//dJ3Y0sv+k WohK939qCrNapDk5/J9uV/yf9D7K+D9pQm3+z28X/7dwsG/zfzLGXsL/tWN2/9eu+L+2k9tH Rv+n+xX/5+fRlfF//spem//T/rZRwP91w3Q75nQ7TWb/5XYSXxcq/N+Oyy3+r4j/ayYZbsT/ fZD/a873f+4vwv8tReH/ivo/v/lU//d7BOL/IqPwf0dE4f/wf2tRK63C/717EjnV/7XSkQ7V vqjnbTyiTvV/8mCV5v/kFz7I/w1hICDJ/8lB/Sn+r+ubW6u0di5jb5TuWr9Gu1QK/4f/i/F/ zdTV6P+Me9PD+n+Us8vd/+kDM+L8Xyv+z/4o/N/xxZ3l+L/4cW/8X3qr8H8J3Yor+b8uvKDB /709LE72f7ZxXcRQ7Yy6PcF0j8pH4f8io5auFq/+z73oxv8tRuH/7lUt/i/Mh8no//SE/0uN Ot//+fdUGf1fa0b8H/5vdQfi/xKjzvV/fl5fTv83R3n4P/zfn6hT/Z/srqz+r8H/pUbh/xKj 8H+xUZf2fzIkmNH/tX0x//do1R//J04po/9T9lL+r5djLqP/a5uL+b/wFOd3TRb/19oV/xfe ZRTxf0INS/g/Pz6e1f813Yr/8+eVaUc5wPfd8cMKBMMvdj3d//mNZ/V/ann9P61vp4puJ90n rP9n/J4L1W+rXj+sgv5Pbo1F/J9cPIr4PzdVFv+3GLXR/3lfU8L/de4VViH/59lVVv/nRgQX /d+9X5Di/+bbkM/qZP83uMeDQv4vQI4S/s+fRFn9n131f3LoFfF/3WwHHuv/wqLnJfyfTLct 4v9M86j2PqCGV9jv/J+8dyri/+QJv4j/CzMKkvzffBtK4f8U/u9N1Eqr8H8bUR7+L6P/M2L3 2m7YHfW8DTcw8QH+Tz6YjP5vMOf7P7k1Jvo/ebD6GP83TnZw35rQjbujdDu6XlmoZlGn+j+/ g2vzf35QvTb/599QVOf/BvdFGvg/ytnl7v/MgRlx/q/z/q9rfhT+7/jiznL8X/y4N/4vvVX4 v4RuxZX8n4wQ4/82HBan+z/3DiNUO6NuTzDDo/JR+L/IqKWrxYL/8xOK8H8b3lHg/9KjavN/ rP+H//O/hf9T+L+tOxD/lxh1qv/zM2Dxf1ui8H8vUd/m/3r/ngz/FxWF/8P//T4NX8v/ybyF NP8XLgDv/J/81+/0f9Ys+7/7ohGV+T9ZNAL/tz5HH/+Xw/+p0Sz7v85m939qxf91TXb/N/us nqK+2v+1ds3/hRtAAf8n878K+L+x67z/G6d2/+V2Mh4ohcpfLfB/MTtQbfR/nQNKef3fqPF/ ka3auP6fLub/Rt9LL+T/pke12/9N8+p8/6c99Crr/6Rxif7vN6qU/1P4P/yf/4yaeYX/i74G 4v+kwv9tjVppFf5vI8rD/2X0f9o/LrZ62H8NfN7GR/k/f+il+j/zFHWm/5O3Va380Yn+Tz9F neb/Rt3fngVuz3PdYPZG3R4p3AcdKiWD3/i/DK168X9Tjf7PuN5vdf5vcgNDWf3f7Sfxf5TY cvd/7YEZcf6vF/9nfhT+7/jiznL8X/y4N/4vvVX4v4RuRSH/13Zr/k8GQMus/4f/+xr/N/a/ 1c6o2xPM9Kh8FP4vMmrparHg/3qF/1uOwv/dK/wf/m/hx/B/+D8p+D/831X83+Af8bP6v77D /2WKwv/h/573IP4vPeoy/k8ep/B/WzwF/i/quNjo/+bT2PP4PzMU839q1f/JiYX/e+P/LP7v mPX/Svo/+83+z17K/5lxUkX83zQF/zeY/ZfbSV6Dhep2AuL/DvJ/bqpsVv93+6uv5f/8Mfel /s9W6f+0Od3/eTVUyv8Ns8bV4v/UFK78sp+P9X/Savzf5/s/K59Vdf4vdACT/N9sG0rh/xT+ 703USqvwfxtRHv4vp//T0ksPDxP7/N98G753W6H/ay3+L0urnv3fZMfbnf729Do99QNj/Z/r KoVqFoX/y+7//IN2Zf5Pu64z/m8pCv9HSS13/9cdmBHn/6z4v+5H4f+OL+4sx//Fj3vj/9Jb hf9L6FYU8n/GrPo/eT1Wwv+NR6A8/F9i1KL/013/W+2M0oMfqwiVj8L/RUYtXS1e/Z8/yvF/ W95R4P/So2rzf22D/0uNwv+9ZuH/8H/4v9WoyvyfGfB/maLwf5n9n0xbwv9FReH/vtP/TWHQ DP+31//Z5lGl+r/mT9Rf/zd7EsP/rR+CBf3f6vp/Q3hcxv+9jCfg/4r4P5kikdP/2Rr9XzgC 1UsZx9z+rzMf4P+8Einh/zo3I1W3o0n4WsTJ+HfJofpt1euHhf/7OP/X9lfyf7KM8bf6P4X/ O8b/tX12/2c/wP9N+D/8H/4vIirK/40Z/N+I/8P/4f+OjsL/5fV/ZvBX9tvNw+yOet7GZ/g/ GQHI6f+0wf9ladUf/6fH2wPs7Zl7aBL8n5+NHCr/BH++/xtlwKIy/yezfGrzf24Tef2fOd// WfeAmtX/OdWI/6NElrv/6w/MiPN/g/g/+6Pwf8cXd5bj/+LHvfF/6a3C/yV0Kwr5P23P939t mFiP//sC/zf0v9XOKD10/aPyUfi/yKilq0UJ/9eN+L8MrcL/fYP/a1r8X2pUhf5vxP/h/9Z3 IP4vMQr/l9Aq/F9iFP4vsln4v3uF/8P/1e3/2ke12//pebXu/2azm3f7v78TfEv5v7a/lv+7 tzrsT4X/W/R/Df4vyf+pqS3m/1SV/q8p5v/0qv8LL+ZK+L9JdmBG/+cuty/+Tzd9WP9P2yT/ px/Vb6teP6yS/k8Ovcr8n7tw4f8Woy7g/+pc/899Vuf6v3bI7/8U/g//53+0mVcX838yUwf/ t+ApZttQCv+n8H9volZahf/biPLwfxn93+jXKbs9purdUc/bUL8r5dXl/z5g/T95zKnK/+mm dfOWbs/cfcr6f/3Q/la3/zBO+L8srXr1f2734/8WHrs/zf/Zrsvt/1wU/o8SWe7+zx6YEeX/ ukb8n/5R+L/jizvL8X/x4974v/RW4f8SuhWl/F+z5v8OOa+W1/+TN8f4vw2Hxdn+zzT9b7Uz Sg/d8Kh8FP4vMmrparHg/2T+Q0b/Nxj8X4ZW4f++wf+x/h/+z//Wk/8zFv+H/1vfgfi/xCj8 X0Kr8H+JUfi/yGbh/+4V/g//h/9Tb6ZXbvR/8l/T/F8YP/qd81jK/3X2Uv4v3N/xf/i/WTlg /b9uYP2/yKgn/+dmxvzL/wmYS/V/fhutvZD/09bK+n/hurfT/zXTo/pt1euHVaX/u8O/7/R/ 43Qt/+ff332p/1Mf4P/CtGZf7Z1iPt+G+6Ea/R/r/+H/ZCPNvLqW/xuacv5POm9l/N/0qHb7 v2le4f8U/u9N1Eqr8H8bUR7+L6P/sx69GDvtj3rehv+C9gr9331VQ/xfVv+nu36aXGXH3VG6 a92gR6hmUfi/zP5vMDX6v84deln93+/Voir/p1n/jxJf7v5vODAjzv9p8X/tj8L/HV/cWY7/ ix/3xv+ltwr/l9CtKOT/utX1/8r5v9BLwv9tOCxO93+2/612RunBfwih8lH4v8iopavFgv9r Ff5vOQr/d6/wf2v+rx/wf6lR9fk/1v/b0yr8X+bnA/xf4g4s5f/6Dv+XKQr/h/973oP4v/Qo /N/2gx3/d6/wf6sTfPXQFvN/j1bh/z7d/1n8X5r/Mw3+LzJqo/8z4v/kAr/X/0lz5Gvg1/1f aHVV/q/N7//cDjzd/4XpqiX8XztfRHav//s79FPK/zXjlfyfTFTG/y0M/Tz7P1vO/6nT1//T 3ZDb/3Xj+f5v7LP7P7vi/8JLpCL+T/ZcEf8n18Ai/k/j//B/+L8sUfNGHReF/8P/rUQ9NWr+ FFGN/2v9jAIjsxF3+r+nbbhHtRr9H+v/pb9tXPJ/tx7n6L6goQldpV3+z8/jDJV/gsf/ZWnV Nfzf5H47q//TVa7/1+H/KPHl7v/GAzPi/J8R/9f/KPzf8cWd5fi/+HFv/F96q/B/Cd2K8/2f 9CdKrP83hvkR+VBei/87yP9N/W+1M0oP/ssHQ+Wj8H+RUUtXi1f/55+psvq/29UC/5feKvzf N/g/1v/D//nfevZ/Bv+H/1vfgfi/xCj8X0Kr8H+JUVfyf1ZYHP4vKgr/953+T0aZ8H9bOp3L /u8+rdmN22Tyf3bN/4UZiEn+7+8E3wr939r6f22T2/95fbXk/7TcDvF/C+MJT/6P9f++Zv2/ GTU83P91XY3+r6nS/90e5hb8n2maPrf/c9/3fbr/G8MMpLr8nwNKWf3f7QHtWv7Pv7/7Uv9n P8H/tY9qt/9r59X56/9pr4by+j+z5v/CDq7M/8mDSRH/FwBlCf8XLuNF/J/cB0v4v9CEAv7P yodUxP/JvBj8n8L/zRt1XBT+D/+3EvXUqPlTRDX+T5bGNdrfjHf6v6dt1Lr+371V+L+8/m/U /eCqrtkddXtUd78cKnfNMef7v+E+4JoQ9YH+z99y8X8Lk1Tn/m92wz/N/xmL/6N8QLn7v+nA jDj/14r/G34U/u/44s5y/F/8uDf+L71V+L+EbkUp/9ec7/9aGWstsv6fzU4Nr+X/WndYhGpn lB78ORcqH4X/i4xaulos+L9GZfZ/Pev/4f/Wos71f/LVlRn9n9EW/5caVaH/Y/0//B/+708U /g//t/Bj+D/831Kz8H/4v4Ufw/99tP/Lv/6fNmv+b3pUx/q/Vo6EjP7PPTievf7fAf5vXF3/ T8Yp8H9v/B/r/yX6v7avcf2/Vf8X+FoB/zd5c2baPmVqUXjeGeT+Oq76vzCcIPu5Cv93Oz61 +L8myf8Nj8oDSvxfzA5U5/k/M1zL//kxVfzf69DPs/9T5fyfOn/9P11w/T/8X6L/C+9z8X/4 v6cs/B/+D/+XfFjg//B/r6364//04IdIQrUv6nkbj6i6/N/Y4f+ytOrZ/zWjvd2XbjfzQZ6p dvm/3j8OhioMfuP/MrTqEv5Pd673m9X/me50/9f1I/6P8gEl+L/xSGsX5/868X/Nj8L/HV/c WY7/ix/3xv+ltwr/l9CtKOT/2m7N/8lhUWT9Pxlbx/9tOCxO9399/1vtjNJDPzwqH4X/i4xa ulq8+j8/ey6r/7s9WuH/0luF//sC/6fHCf+XGlWh/2P9P/wf/u9PFP5vzf+ZAf+XKQr/l9n/ ySQn/F9UFP7vS/1fmLGH//sc//eI+uv/gpz6Rv/nHhzrW//Pk6hF/xfmmOH//u3/3LwE/F/U Z4X/y+v/xrX1/zrxfybcIvf5P9lT95c5H+D//JSYrP5PN0v+r5ncjFTdjs20/3I7GX/JDpX/ rK7k/8IwxXf6P3cNvJL/83eP2vyf3/i3+r/T1//rb59Vlf7PZPd/Lf4P/+c/o2Ze4f+ir4H4 P6nwf1ujVlqF/9uI8vB/Gf2ftX54c/BL+O30f0/bcL3cGv3fvVX4v7z+b+in3t3MzZji//wb NqkU6//h//B/+D/KZ5S7/9MHZsT5v178n/lR+L/jizvL8X/x4974v/RW4f8SuhWF/N/tKe10 /xc0Hv5vw2Fxtv/zK8WHameUHmT2iVQ+Cv8XGbV0tSjh/1j/D/+3GlWb/7MG/5caVaH/Y/0/ /B/+708U/m/N/81RHv4P//cn6lT/F66w+D/832oU/g//Fwr+D/+35P+kCfi/f/s/1v/7Hv+n Df7vKP8nf1EJ/+f7pCXW/5vcAILzf8P+I3AyfrJQqPB/Oy63G/2fu3Dh/xajtvk/7y2+1f+p Nf/nO2+h2u3/hlnlekyXWf/vCP/nbiIr/q+bNe7b/J9a9X9h/moJ/yetLuH/RCYU8X9y6yzi /0zzqA72f2GflPB/cuEq4//kCE3zf7NtKIX/U/i/N1ErrcL/bUR5+L+M/q/zN/zbw87+qOdt uMfG8/2fHHM5/Z82+L8srXr2f3qYbOv9X5Pi/4z9rRTr/x3m/+wky2bg//7t/9xT49n+r2vw f5QPKHf/Zw7MiPN/Vvxf96Pwf8cXd5bj/+LHvfF/6a3C/yV0K0r5P7Pq/2QosIT/kxFi/N+G w+J0/+fefYRqZ5Qe/ASyUPko/F9k1NLVYsH/+WMup/+zHf4vQ6vwf9/g/1j/D//nfwv/p/B/ W3cg/i8xqjL/x/p/+L9/ROH/Uj4s/F961GX8n4ze4v+2eIpl/xcy3LjN0f4vPInh//59CDqQ crb/G+Z0A/+H/5Pdm9//NeOl1v/z5iyr/zPF/J+Luoz/M23bV+n/wkdamf8bJvzfxvNq0f8J JsP/LQz94P/K+D9pFf5vw2e17P8CWiri/2S7Rfyf3Afxf/g//B/+byFqpVX4v40oD/+Xz/+p QQYsRn/D3xn1tI1HVF3+764a8X9Z/d+tq95pN3wxdgn+z7OrUCkZ/Mb/ZWjVNfyfdZvI6v9m N/yz/F9rWf+P8gnl7v/aAzPi/N8g/s/+KPzf8cWd5fi/+HFv/F96q/B/Cd2KQv5P2/P9n5kC 3cD/vT0sTvd/buQ5VDuj9OD3fqh8FP4vMmrpaoH/S3hHgf9Lj8L/4f9eDov6/J/B/+H/1ncg /i8xqjL/13f4v0xR+L+P939mwP+lRuH/EqPwf7FRG/1f+6jwf6sTfP1XIF9o/T/8H/6vsvX/ 6vR/4QhUL6Wo/5Mfq8r/9fnX/7v9JP4vageqjf6vd6d4Vv/nYTL+L6pVp/k/W87/qXL+T5uz /V/v1VBW/+fmPOL/Ej+rlfX/ullVjf8LV6HK/J9cH6rzf9Oj2u3/pnmF/1P4vzdRK63C/21E efi/jP7PWn/hGvz6BzujnrahKl3/z3Q1+j83dnuu/+vbfrxVQ9ftjtL95EbOQ6VkiOR0/yeD Nvi/j/d/xn9nR17/d/76f601+D/KB5S7/+sOzIjyf30j/k//KPzf8cWd5fi/+HFv/F96q/B/ Cd2KUv6vOd///c5VKeH/mgOiLuT/endChWpnlB78kEWofBT+LzJq6Wqx4P9k/gP+D//3VJ5+ DP+H/1v4Mfwf/k8K/g//h//b7f/mKA//h//7E1WZ/1Os/4f/W4w63//J9Dz83xZPcbr/k6g0 /xfGj37nPFa4/l85/+dGipf9nxwW+L+F8YQn/9fg/5L8360fVMz/qXL+b/ZZPUWVX/8vfBFj ov+7j8PV6P/c5XbB/w2Tzu3/3A483f+F6ar4v3/7P38K4/+iWnWF9f8u5f863eP/vsf/hZno /scO9n/ywRRZ/0+aUJn/kwcC/N+Cp8D/+Qr/tzVqpVX4v40oD/+X0f8FtDf4x4O96//Nt1Gr //uA9f/MJE87Gf2fbs/2f4O5PRRpMw292RulrXE9hFAp+fK70/2f7+bU5v98q2rzf12V/q9v 8H+UDyh3/9cfmBHn/7T4v/ZH4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n/dJ/i/Lrygwf+9PSxO 93+2/612RunBf2F4qHwU/i8yaulqseD//IQi/N+GdxT4v/Qo/B/+7+WwwP+9ZOH/8H/4v9Uo /F9Cq/B/iVH4v8hm4f/uFf4P/1e3/7OParf/M/MK/1eD/5vTDfwf/k92b/71/9wyW/X5P1vM /71b/w//94qHNvm/0fWd8/o/N9/ndP83hhlI+L/nqIv7P3+E4v8Whn6e/Z9d9X/2Ue32f3Ze fYD/a6bs/s+s+T87zBpXjf+TD6aI/xuCnPI/drD/k5tTEf8nV6ES/k+H/rbvSB/r/2SmThn/ J/fEIv5PjtA0/zfbhlL4P4X/exO10ir830aUh//L6v/kvtslXAOftvGIwv99vv+bobyz/J8d 3Y3q1ppxb5S2xjUnVOoj/F+Af7X5v06WzajM/7nfzur/bj+J/4uMwv9VWu7+zx6YEef/jPi/ /kfh/44v7izH/8WPe+P/0luF/0voVhTyf213vv8Lr52L+L/eHhB1Jf839b/Vzig9hC8yGX4H o/F/kVFLV4sF/9erzP6vN/i/DK3C/+H//rYK/5cYhf+Ljfq7B/F/GXYg/i8x6lT/54eh8X9b ovB/L1Hf5v8av2H8X1QU/u9L/Z88TuH/tniKRf/XF/R/06Pa7f/+TvCt0P89WnW0/1Pdmv/r 5bUI/g//NysH+L+2L+b/bDn/586r6tb/c1GX8X9tb/sq/V+d6/+5387r/26HBf4vrlUb/d+Q 3f/ZKv2f+6yq838Oka/4Pztr3Lf5P7vm/2S7ZfyfXI5L+L/QZynh/+4TtAr4P9M8qoP9nzx/ FfF/okjK+D/59zT/N9uGUvg/hf97E7XSKvzfRpSH/8vp/6SrNPQJUU/beETV5f9Mh//L0qpn /9d2U6/dQ4HWZm+UHhrX6wqVf4LH/2Vp1SX8X6td1znv+n+PG35N/s/g/yjR5e7/hgMz4vxf 5/1f3/wo/N/xxZ3l+L/4cW/8X3qr8H8J3YpC/u/2lHa6/wtTb/B/Gw6Ls/2ff9cSqp1RepBX rlL5KPxfZNTS1WLB/8kEEvwf/u+pPP0Y/g//t/Bj+L81/6cN/g//t7oD8X+JUZX5PzPg/zJF 4f/wf897EP+XHoX/236w4/8U/u/dBN86/d/6+n+9fDD4P/zfrLD+30b/p6pc/6+p0v/13aL/ m5qmd5f1dkzwf20/PSqvRM73f/Lv+L83/u92WFzI/zX+MvGl/k+bKv1fnev/jWv+L/C17/R/ atX/ycNUCf93XznNVwf7Pznviqz/J0d2Zev/heHGAv5PZHcZ/zfpR7X3GjjfhlL4P4X/exO1 0ir830aUh//L6P9GGXMc/ePBzqinbbhebo3+bzD4vyyt+uP/xr4d3PDFFEbndvm/zh23oZpF nej/jAzaVuf//IN2Zf7P927xf0tRT/7Pjd3i/yiR5e7/xgMz4vxfL/7P/Cj83/HFneX4v/hx b/xfeqvwfwndilL+z3yA/+vCCxr839vD4nT/N/a/1c4oPQzTo/JR+L/IqKWrxYL/8yPP+L8N 7yjwf+lR+D/838thgf97ycL/4f/wf6tRlfk/xfp/yXcR/F/yDsT/5YrC/+H/fodUr+X/wsTU Ev5P/utX+j+jbTH/5xakOt3/zekG/m/V/1n839f4v4Lr/5Xzf85TsP7fS1S6/+t1dv/3Gev/ Zfd/7n51tv8bh9z+z53C+L+oVn2e/zPZ/V+L/8P/+X2xzf/JZKIy6/9JR7o2/xcmaJXwf7K3 8H/4P/wf/u/PYYH/w/+9tuqv/7Oj/6+Df+jZGfW0DfW7Ul5d/s82+L8srfq7/l976wfqdgqm bKf/s8NvFQa/z17/L3zdVdLMUaPnFf7vKP/nfhv/txTF+n+U1HL3f9OBGXH+z4r/634U/u/4 4s5y/F/8uDf+L71V+L+EbkUh/3frVV7L//UHRF3I/w26/612RulBTMbw6K7j/yKjlq4Wr/5P jrmc/s+M+L8MrcL/4f/+tgr/lxi16P9sl93/2Qb/h/9b3YH4v8Qo/F9Cq/B/iVHX8n/+B/B/ UVH4P/zf75DqpfxfeHdbxP/JRMU0/xfGj37nPFa4/l9B/2eaFf8n0Ksy/zfIvTGj/wv6Cv+H /zvJ/71b/6/pUqYW3d+p3C881/F/je1G8X/d/svt1PrfCpXMeTzb/9ns/k+3K/5PxE8J/2ds m9n/uRv+pfyfH1Mt4f/8lL6s/k+pKv2f+6zO9X/GL4mW1f/5g33R/9lh1rhq/F9T0P/JyVDC /4WrUAH/pyZpQgn/Z5pHdaz/6+URpIj/k1YV8X/iVtL833wbSuH/FP7vTdRKq/B/G1Ee/i+f /9OdvHGRal/U8zYeUWf6vzDmmOb/5AbX3R9A8X9ZWvXs/5p+cN9b1I7jYPZG6cF/YVGolAyR 4P8ytOrF//kxqNr835Td//lvzjrZ/43Z/Z+Lwv9RIkvwf9OR1i7O/w3e/3X9j8L/HV/cWY7/ ix/3xv+ltwr/l9CtKOX/Gvwf/m8xatn/df1vtTNKD2P7qHwU/i8yaulqseD//IQi/N+GdxT4 v/Qo/B/+7+WwqM7/uS9iwv/FRuH/Mj8f4P8Sd+Cy//NnEv5vSxT+7yUK/2cG/F9qFP4vMWrF /4WZ0fi/3f5PBmzwf/+e4Fvp+n/4v0T/Z/B/af7PmlL+T5ty/s/W6P8qXf/PXW5f/Z9ujRX/ p/dfbqfW/xmh+oz1/6r0f60bx2P9v8Uo/B/+b0uP6dX/2dupi//D/+H/Ik7hZl6t+j859PB/ C54C/+cr/N/WqJVW4f82ojz8X0b/10++tyMLe+30f0/bUB+x/l9+/3dvFf4vq/9zDMM6/2fl 8WCn/3P/c6jUZ6z/J6/78H8LTyIf5//cOHte/2dO93/TaPF/lA8od/+nD8yI8n+2Ef/X/Cj8 3/HFneX4v/hxb/xfeqvwfwndikL+T3Uf4P+0PFoV8X/dAVFX8n9D/1vtjNKDn/gZKh+F/4uM WrpaLPg/mUCS0f/1Bv+XoVX4P/zf31bh/xKj8H+xUX/3IP4vww7E/yVG4f8SWoX/S4y6kv/r Zf4M6/9FReH/8H+/Q6r4P/f/8H/1+z/vlBb93yBnEf7vjf9j/b9E/9f2+L/IqCf/FwSqeims /7d2BG5a/890g6nT/8mhl9H/Cd041f/17taI/1uM2uT//EJvZfxf35Xzf/4kyur/dF/M/2lz uv/rqlz/b5iy+792zf9JB6qI/7vPRPc/dqz/C32WIv5PrkIl/F+Y+FXA/1nZgbX5v4D2kvzf fBtK4f8U/u9N1Eqr8H8bUR7+L5//u92u/HanISHqaRt+MOFj/F9C1K//C3fIEf+XpVXP/u92 n+8m5//Ci+6d/s911kOl8H/4vyj/N7pTvDr/N3S5/Z8bD8T/USLL3f+ZAzPi/J8W/2d+FP7v +OLOcvxf/Lg3/i+9Vfi/hG5FIf/X2Sr9n13zf2GqI/5vp/8bm/632hmlh3F4VD4K/xcZtXS1 WPB/RmX2f7erBf4vvVX4P/zf31bh/xKjCvk/N7MN/xcbhf/L/HyA/0vcgaX8X9/h/zJF4f/w f897EP+XHoX/236wX9v/9QGslPB/06Pa7f/+TvAt5f+appj/cyDl7PX/8H/b/B/r/33N+n8z lFeR/yu4/l+l/m95/b/b/WnE/yX5v+ebyLH+z713yuv/Rn0t/+d3WQn/Zxv837f4v77F/+H/ 8H8Rp3Azr1b9n1y48H8LNxH8n6/wf1ujVlqF/9uI8vB/Gf2flX7i0CT0A5+28ZBy+D/830Kr /vi/wcr6f21v9kbpwbhnuFDNok71f76bU53/87dc/N/CJNVP838d/o/yCeXu/9oDM+L8nxH/ 1/0o/N/xxZ3l+L/4cW/8X3qr8H8J3YpS/q853/+FJwf834bD4nT/1/a/1c4oPYzTo/JR+L/I qKWrxYL/a1Rm/9c1+L8MrcL/fYP/swb/lxqF/3vNwv/h//B/q1GV+b9R4/8yReH/8vo/K3Pf 8H9RUfg//N/vkCr+z/0//N9Z6/+14wes/ydHNv4P/zcrB/i/Zjzf/7XZ/V9b4/p/LqpC/7e8 /l9ruzr9X/iGxsr8n/vtrP7PfVMc/i+uVWf5P23K+b+hnP9znxX+L64j/ffxAP8XuQM/zf/J gzb+b+mwaJ8q/B/+703UvFHHReH/8H8rUU+Nmj9FVOP/BnmqHPy46s6op224Xm6N/m+O8vB/ 2fxf29tbt9b5vzAQuNP/md9KnoXP9n/3z6oy/2dk2iz+7/P9X9u7cYuc/u+2o/B/lNhy93/d gRlx/q8V/2d/FP7v+OLOcvxf/Lg3/i+9Vfi/hG7FlfxfF+aqZEV5+L/EqGX/Z/vfamdUeKUS Kh+F/4uMWrpavPo/v64m/m/LOwr8X3pUbf6P9f/wf/63nv1f1+H/8H+rOxD/lxiF/0toFf4v MQr/F9ks/N+9wv/h/2r2f1rmREq11/+F97yhGkyF/s9PgSjk/7TG/0XuQPwf/m/ps2rn1Sf4 v9FFtVanvIGZ/bL61/p//pLehJ2WNLVIPva2qdL/raz/13RNbv/nnNKV/J+cuyX8X+eoYV7/ 5y5MF/J/flYb/m9h6Oc0/3f++n9W9/i/NP8n7Sji/wImK+L/5BpZxP/JKV7E/8neKuH/+nL+ T9pRxv+1j2q3/2vnFf5P4f/eRK20Cv+3EeXh//L5Py1dpVDti3rexiOqLv93V434v6z+T0/9 rcek29HIh7TT/7nmhEp9iP+TAQv8H/7vFP/X+7Uas/o/F4X/o0SWu//rD8yI83+d939986Pw f8cXd5bj/+LHvfF/6a3C/yV0Kwr5Pzeb/XT/Z8ILmgL+zx4RdSX/N/W/1c4oPfjx2lD5KPxf ZNTS1WLB/8n8h4z+rzf4vwytwv/h//62Cv+XGFXI/7lvTMD/xUbh/zI/H+D/EndgKf/Xd/i/ TFH4v4/3f2bA/6VG4f8So1b8X2gO/g//N0/66vX/yvk/N3F+2f/Z+dJN+L9V/zfi/9L8X2dr 9H9TMf/3j/X//CU9p/+zV/J/duqqXP8vTFfF/73xf22P/4ts1Wn+b1zxf4O/72b1f+2A/4uK +uP/3Ge17P/CvaYy/yePiEX8n/TZy/g/aUIR/ydRJfyfaR7Vwf5PLnhF/N8gpqaE/ws96CT/ N9+GUvg/hf97E7XSKvzfRpSH/8vn/9QgPbHBd2P2rv8334b6iPX/RvOodvs/PatuD8P4vyyt evZ/xupbX/PW7dSD3RulB+PucqEKg9/4vwytuob/G1zXGf+3FPXk/1yr8H+UyHL3f/bAjDj/ 14v/Mz8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/zPjB/i/8I4V//f5/m8y/W+1M0oPvkcbKh+F /4uMWrpaLPi/XmX2f7bD/2VoFf7vG/yfNfi/1Kj6/B/r/+1pFf4v8/MB/i9xB+L/EqPwfy9R +D/8H/5vOQr/l9qs8/2fPJDi//49wbfO9f/+4f/ksMD/4f9m5QD/p6di/k/h//B/aqv/G/rs /k/j//B/spFP83+NR3tf6v+Uxf99jf8z+L+D/F94n4v/w//NCv5P4f/wf/i/xSj8X2b/Z+XW aIeEqKdtPKQc/g//t9CqP/5vcM8Fzv/Z3VEO/jW/lcL/4f9O9n9u6PFs/9cP2f3fiP+jRJe7 /xsOzIjzf1b8X/ej8H/HF3eW4//ix73xf+mtwv8ldCtK+T/zAf4vzD8s4f/68YCoK/m/vv+t dkbpYRoelY/C/0VGLV0tXvyf8S9Xs/q/Dv+H/1uLwv/h/14Oi+r8H+v/7WkV/i/z8wH+L3EH 4v8So/B/L1H4P/wf/m85Cv+X2qyz/Z+SAZs0/xdgX3jd26/6v+7x01/n/6wp5v/aEf8XuQO3 +b9wIOT0fwb/l+T/1GRqXP+vrdH/uajL+L/bvaPJ7f9Mh//7Gv/XjPi/yFbh/2rzf2bI7f/8 wb7o/8JqN/i/vf5v0rNqr/97eb462//Jn4L/Wzgs2qfqA/xfQHtJ/m++DaXwfwr/9yZqpVX4 v40oD/+X0//J40Ga/5tvA/+n8H/b/V9r+mnw/k+6nDv9n7tyhkrh//B/+L8D/J9rFf6PElnu /m88MCPO/w3i/+yPwv8dX9xZjv+LH/fG/6W3Cv+X0K0o5P+0/QD/Z8ILGvzf28PiZP83NG7u a6h2RunR/3KofBT+LzJq6Wqx4P/c0BD+b8s7CvxfelRt/m+c8H+pUfX5P9b/29Mq/F/m5wP8 X+IOxP8lRuH/XqLwf/g//N9yFP4vtVkV+r+uwf9FRp3l/zyJWvR/MqaK/1s42PF/X7r+H/6P 9f+UevF/LurV/3Xa9P29UjuPwKnz40uh+m3V64dV0P+NYQYS/u856o//89dA/F9Uq/B/Wf2f +6zwf3Ed6b+PB/i/xB2I/3vdgen+r5drJP5v4SbSziv8n8L/vYlaaRX+byPKw//l9H+Dv7YO vke71//Nt1Gr/zPd6f5P4F9d/s8dcs292hmlB+tf5kmlZPD7ZP8X4F9t/s9jMvzf0iTVuf9z X1SI/4uLwv9VWu7+bzowI8r/3f6z93/6R+H/ji/uLMf/xY974//SW4X/S+hWFPJ/3Sf4v/CO Ff/3Bf7PTZMK1c4oPfo3r6HyUfi/yKilq8WC//MTSPB/G95R4P/So2rzf6z/h//zv4X/U/i/ rTsQ/5cYhf9LaBX+LzHqSv4vjCPk9H+6xf+lRuH/EqOW/V+YXoH/2+Iplv2fPJCm+b8wT0Wi 3JcFL/u/6VF9nf8bp0v5PysXV/zfv/1fa/F/3+L/tDnf/01ddv83rvi/Sc6kqQ+N3ze1SM5N 67dxKf/Xjs3g/F83DQn+z/oTJlS/rXr9sAr6Pxs+pAL+b5Tr7Hf6PzNcy/+5Vn2p/9Nmzf/5 i19W/6fHK63/107Z/Z9d83/hGlnC//nrQ1b/p/sV/xemMpXwf1Zu1iX8X7g0FPF//aM62P/d vyrBd6SPXf9PHuWK+D+5n+H/FP5v3qjjovB/+L+VqKdGzZ8i6vF/crkVwrfX/8238ZBy+D/8 30Kr/qz/d+vcDm7cwsqht8v/jc04/FZu14wf4P/kia82/+dvuXX5v85m939ulPNk/9f2bW7/ 51qF/6NEFvF/Q3OktYvzf9r7v1b/KPzf8cWd5fi/+HFv/F96q/B/Cd2KUv6v+QD/F+Yf4v++ wP+59yCh2hl1e1TsH5WPwv9FRi1dLRb8nx95xv9teEeB/0uPqs3/sf4f/s//Fv5P4f+27kD8 X2JUZf7PDPi/TFH4P/zf8x7E/6VH4f+2H+z4P4X/ezfBF/+H/1vwf6z/l+r/Osv6f5FR2/zf 2Ms38tmUO/59/T85N6/k//TU+PX/uhQ8NFmvhkJ1OwEv5f/ud4yv9H/um+Iu5f/83QP/9zr0 c13/1w+9zu3/3P0K/5f4WeH/VFTvFv+H/3M/iv9bahX+D/+H/8vl/+T5avAb2ev/5tt4RNXl /1qL/8vSqmf/p8f+dgXXXRduVDv9XzP9VupD1v/D/32L//OvkfB/S1H4P0pqufs/fWBGnP8z 4v/aH4X/O764sxz/Fz/ujf9LbxX+L6FbcSX/Z8ILGvzf28PibP/nNxGqnVHuq2IelY/C/0VG LV0tXv2ff8mT1f8Z/B/+by2qMv9ntMX/pUbV5/9cjwn/FxuF/8v8fID/S9yB+L/EKPzfSxT+ z93y8X9pUfi/xCj8X2zUNv8XvuHXt363/wskSjZsxgr9n3moxsP9n+1L+T83cX7F/8m/4//+ 7f9Y/y/V/5Vb/2/WqsP9n+4q9H+dWfN/wSl9p/+7Pcwtrf/XtG1u/+cE6pX8Xxim+E7/14xX 8n+y8SL+r3cT6LL6P/8Kqz7/5z6rk/2fGfB/m/yfexjG/8V1Y5p5hf/D/71sQyn8n8L/vYla aRX+byPKw//l9H/SqRj8lvb6v/k2XJepRv83GPxfllb9Wf+vaTo3btEOcpnY5f+GaWh/K/+T +L8srcL/4f8elRtQxf9RIsvd/5kDM+L8Xyv+r/9R+L/jizvL8X/x4974v/RW4f8SuhWF/J9b zeZ0/3cIysP/JUYt+z/XzQzVzig9+m5mqHwU/i8yaulqUcL/ufdJ+L/kVuH/vsD/sf4f/g// h/+L3IH4v8SoyvzfqPF/maLwf/i/5z2I/0uPuor/C4cb/m+Lp8D/RR0Xp63/92jV0f5Pra7/ F5598X//9n+s//dF/q/g+n8F/Z/B/0VeLbb5P51//T894v/wf/IpPFWf4P+sVF/p/8Yq/d/5 6/9NTXb/5w/26/g/JQNlZfyfHKFF/J80oYj/CxO0Svg/ufLj//B/+D/835/DAv+H/3tt1V// N8h1VqqdUU/bcD9Zo/+7q8a6/J8bTDjZ/7W3J9PbTd+Ou6P0MLl+QKiUfPkd/i9Dqy7i/9zL 9Nr8X2f63P7PReH/KJHl7v/aAzPi/F8n/m/4Ufi/44s7y/F/8ePe+L/0VuH/EroVhfyfGT/A /4X5hxlRnsX/HeT/3JNiqHZG6VHeGI76d4QY/xcZtXS1WPB//phj/b8N7yjwf+lRtfk/a/B/ qVH4v9cs/B/+D/+3GoX/S2gV/i8xCv8X2Sz8373C/322/5PRW/zfFk+x6P9CHz3N/4U3ou/8 n/xX/N+bQ9DNITnd/8mJhf/D/81Kfv+nJlOj/3tEHe7/Lrb+n/8ss/q/dtn/9c2Qff0/hf/7 Fv/n1jy4kv8TX1Ob//PsKqv/U9OF1v8r6//MrHGH+r+xLeb/tMwWLeP/wulXwP/J81UR/9fI kV3E/8kFrzb/Jx8S/g//N2/UcVH4P/zfStRTo+ZPEdX4PyvfcmaHhH7g0zb8YEKF/u/eqjP9 n/Q9cvo/3Z7t/26X8s77P3k82On/XE8/VLMo/B/+b6FVBfyfqdL/WfwfJbrc/V93YEac/+u9 /+v0j8L/HV/cWY7/ix/3xv+ltwr/l9CtKOX/zAf4vy7MVcmK8vB/iVGL/s+4LmKodkbp0V9H Q+Wj8H+RUUtXixL+r7X4vwytwv/h//62Cv+XGFXI/7kVk/F/sVH4v8zPB/i/xB1Yyv/1Hf4v UxT+D//3vAfxf+lRV/F/Uxg0w//t9n9h/Duf/3NfFlzd+n/m0aqK/J82a/4vPCXi//B/s3LA +n+dvZL/m7pi/m/yD4lGy1V35x0/mAzrt3G78Kz4v/Birir/N3TZ/V/H+n/f4/9ud2H8X1yr zvJ/t7P0A/zf9Kh2+79pXn2A/9Ntdv9n8X/4P9nIvFr1f2G7JfyfaR4V/u/ffQv8H/5vJQr/ h/9biXpq1Pwpoh7/J5dx6+/Ce/3ffBuq0vX/8H/pbxuX/J/tTe/9X+gq7fR/+rdSrP+H/4vz f+63a/N/bd/m9n9uPBD/R4ksd//XH5gR5/+s+L/2R+H/ji/uLMf/xY974//SW4X/S+hWFPJ/ 2n6A/zsE5eH/EqOW/Z8bIQ7Vzig9+pdRofJR+L/IqKWrxYL/c7+N/9vyjgL/lx5Vm/8bWvxf alR9/o/1//a0Cv+X+fkA/5e4A/F/iVH4v5co/B/+D/+3HIX/S23W+f5PJjj6l5qp/k+qKv2f ++KYUv7v0Sr8H/6vcv+npyv5vwPW/zOr6//l9n/r6/99tf/TzaL/60yb2/+5y+2F/J8apdUF /F/vbo2s/7cYtc3/+T33pf7vM9b/w/9t8X/uJnIl/ydzjfF/G+anXsn/yd0D/7dwE2nnFf5P 4f/eRK20Cv+3EeXh/3L6P0Ev1ndj9vq/+TYU/g//F+H/2ul2D9dd20uXc6f/cw/BoVIf4v+0 VJX5P3+U1+b/alz/D/9H+Yxy93/2wIw4/zeI/+t/FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FIf/n ZrOf7v/CO1b83xf4PzcKHaqdUXrU46PyUfi/yKilq8WC//MTinL6P23wfxlahf/7Av9nmgb/ lxqF/3vNwv/h//B/q1GV+b9R4/8yReH/Mvs/QXv4v6go/N+X+r8wrx7/h/+bJ+X3f+NU4fp/ Sq35P4Fe+L+Fg33u/1qL//t+/2fC6mzf6P/CEaheSn7/t77+X2h1Vf7PNtn9X9vg/w7yf+63 8/q/2zM+/i+uVaf5P1Ol/9OmRv83rvm/MNv9O/2fxf/h//xn1MyrVf8n8yTwfws3kXZe4f8U /u9N1Eqr8H8bUR7+L6f/k0u6HfT+qKdtPKLq8n+DqdH/zVDeSf6v76bJ+z+zO8rBv+a3Uh/i //pZVYv/6/2zcqr/C08iH+P/Or+gSE7/19oG/xcZhf+rtNz933BgRoz/a93/rm9nhv5R+L/j izvL8X/x4974v/RW4f8SuhWn+z8ZAC3i/8JMIvzf5/s//0wVqp1RevTPVKHyUfi/yKilq0UJ /+denuL/kluF//sC/+emceL/EqPq839th//D/63vQPxfYlRl/o/1//B//4g61f/JYzD+LyoK //ed/m8M703xf3v9X5gileb/ZK7eW/8XXpx+pf8b2hr9n13zf/2cbuD/1vwf6/+l+r/OlvJ/ 2tTo/wqu/3ct/9c7NZTX/91b9fphFfR/4RTH/73xf+4aeB3/10wy3FiZ//MXv7z+r8P/RUVt X/9vmDXuWP/XZPd/7Zr/kz+ljP+TU7yE/5OJJGX8n9wHS/i/MPGrhP9rfFQR/yeDFPg/hf+b N+q4KPwf/m8l6qlR86eIevyfvNiRaq//m2/D9wMr9H+tPd//yX+tzP/ZtvP+z7+h2Ov/XG8h VL5xH+D/Wqkq83/+2Qj/tzBJde7/WP8P/0cJ5e7/xgMz4vyfEf/X/Sj83/HFneX4v/hxb/xf eqvwfwndikL+z81mP93/hfeL+L8v8H9d/1vtjNKjP7RC5aPwf5FRS1eLBf/nWoX/2/KOAv+X HoX/w/+9HBb1+T/b4P/wf6s7EP+XGIX/S2gV/i8xCv8X2Sz8373C/322/5O9hf/b4inwf1HH xWn+79a7ON3/yVeP4/8WDnb8X0b/pybD+n+RUaf5v2bV/4XhhDB1uwr/Z6Yh+/p/9lL+737H KOH/HDVk/b/FqI3+z/2h3+r/hET9p/4U/N9qq7b5v1Hr7P5vdf0//F+i/wvDNfg//N+s4P8U /g//h/9bjML/5fZ/0nmzvme61//Nt6Hwf1/k/9x3t53r/0x/647pru3k0Nvr/4bfSsmINP4v Q6vwf/i/R4X/o+wod/83HZgR5/9a8X/2R+H/ji/uLMf/xY974//SW4X/S+hWFPJ/Zjzf/91n 4OD/vsD/Df1vtTNKj/4NUah8FP4vMmrpaoH/S3hHgf9Lj6rN/1mD/0uNwv+9ZuH/8H/4v9Wo yvzfqPF/maLwf5n9n7ypxf9FReH/vtP/BcmD/9viKRb9Xx/mbLuN7PV/YTyxDa0a1/yfTOnz fc/d/s/Mq3L+zzxU4yXW/7PzpZvwf2v+r7X4vyT/d3uKP93/tVN2/9eu+T/zzf5vff2/b/Z/ 7bDo/4Z+yr7+H/7ve/yfg8nX8X8ier7V/9kq/Z/7rM71f7IACP5vKQr/h/9bOoWbeYX/i74G 4v+kwv9tjVppFf5vI8rD/+X0f3J3T/N/820o/B/+L8L/DbafvP+T4ay9/s/+VrNWnej/zChj UHX5P9v7Z6Oh6ROinp9EqvR//puzTvZ/nRvHyuv/ug7/R4ktwf/pI61dnP/rvP8zw4/C/x1f 3FmO/4sf98b/pbfqVP8XOk/4vzf+z6z5v3A8lPB/XaAb+L+3h8XZ/q9zmwjVzig9yovk8TFX 5Xz/N8wq/N+q/9MG/5ehVfi/b/B/rP+H//O/9eT/3CQ6/F9sFP4v8/MB/i9xB+L/EqPwfy9R +D/8H/5vOQr/l9os/N9Lqz7S/7kHx/r8nzZr/i/cnvB///Z/rP/3Rf5PlfN/qpj/a7uulP9z B/uK/5PLRFX+rx11bv/n7MuV/J+e30S+zf/pS63/993+T5Xzf/ZS/m9k/b/v8X8C//B/Cw89 7bxa9X+hVXIp3Ov/9Lxa9X9yQhXxf/KEX8b/DY9qt/8b5hX+T+H/3kSttAr/txHl4f9y+j85 k2ybcA182sYjCv+H/1to1R//194+Hu//BrM3ysG/7reaReH/Mvs/gX/4v6VJqvg//B9lodz9 nz4wI87/9bL+n/5R+L/jizvL8X/x4974v/RW4f8SuhWF/J+25/s/E94v4v++wP+5WR2h2hml R78bQuWjzvd/4bPE/708WuH/7hX+71r+j/X/8H/+t1j/T+H/tu5A/F9iVF3+Tzcj/i9TFP7v 4/2fGfB/qVH4v8SoFf8XBs3wf3v9X5jnkeb/7nNg/0T99X+hJ5jk/6Q5rP+Xx/813Yr/G+SD wf/92/+x/t8X+b+19f/uwqNK/9d0svk0/3e/8OD/olqF/1OqiP+z7taZ1//13bX83/io6vF/ /hkxq/9rDf4vKuoa/k+t+b9GpjKV8H/yRFXG/8mloYT/C1Oji/i/cJ1NeUCV28K9WvV/Y43+ 73ZRf1Q7r4FP21AK/6fwf2+iVlqF/9uI8vB/Of2fdGWt7yrt9X/zbbguU43+7y56zvR/0vfI 6f90e7r/c8dcXv/nB79P9n8B/uH/NjyJ4P9ytAr/R/nIcvd/5sCMOP9nxf+1Pwr/d3xxZzn+ L37cG/+X3qpT/V+Ys43/2+3/5PG6hP8bwgsa/N/bw+J0/zf1v9XOKD36t6Kh8lH4v8iopavF gv/z8w7xfxveUeD/0qNq83+s/4f/87/F+n8K/7d1B+L/EqPq8n9ubiD+L08U/g//97wH8X/p UVfxf6McA/i/LZ7idP83exJj/b/1Q/Aj/J+MU+D/8H+zcoD/a5sP8H9y+8jo/2wx/9c1xfzf P9b/kx2K/8P/zUpJ/+eGBPP6P3cNvJD/C+NK4bza6f/mk9tUnf7PjQji/yKiPtH/Wfwf/g// FxGF/zsiCv+H/1uLWmkV/u/dk8jJ/i90XJL833wb7idr9H931Yj/O8j/yYe01//p30rh//B/ +D/8H+Uzyt3/tQdmxPm/Qfxf/6Pwf8cXd5bj/+LHvfF/6a3C/yV0K0r5v+YD/N8Y6EYB/zcc EXUh/+enc4RqZ5Qe/cv0UPmo8/1fOMXxfy+PVvi/e4X/w/8t/EX4v0v5P9b/29Mq/F/m5wP8 X+IOxP8lRuH/XqLwf/g//N9y1Pn+L+AG/N9e/ye/LV31RP9n+j9Rf/zffGrkbv/398Na9H8m vDXO6P+suZT/k9/G/y2MJ8z9nyNR+L+oz+qP/9Ndjf6v62pc/6+5kP/rGtvn9n+3n/wA/yc7 uDL/l339PzdSfCX/5+/C+L+FoZ8L+7++b/F/+D/8X8QpvM3/yTGA/1t4PMD/+Qr/tzVqpVX4 v40oD/+X0//JEEqa/5tv4xFVl/9j/b/0t40L/q9r2jG3//OD36f7P3niq8v/WX/Y4P+WJqni //B/lIVy93/dgRlR/k834v+aH4X/O764sxz/Fz/ujf9Lb9W5/i+8sMP/vTxazf1ft7r+n8yN KuL/wvtF/N8X+D/35BCqnVF69PNhQuWj8H+RUUtXC/xfwjsK/F96FP4P//dyWOD/XrLwf/g/ /N9qFP4voVX4v8SoS/m/wW84p/9zt3z8X1oU/i8xasX/yegt/m+Lp8D/RR0Xp/m/R6vO838B rOD//u3/WP8P/3cZ/3et9f/GYapy/T/xNSX83/0Z5yv9n3vGv5L/E1+D/3sd+jnN/2lTo/8z q/6vnTWuFv8XToYi/u9+ZS/h/6QJJfyfLuf/wsSvEv5PHh+K+D95CC7h/0KnIsn/PW1DKfyf wv+9iVppFf5vI8rD/+X0f9IrS/N/8224Xm6N/u++qiH+L6v/a29n0lTh+n9GRudq838yUoH/ W5ikiv/D/1EWyt3/9QdmxPk/Lf7P/Cj83/HFneX4v/hxb/xfeqvO9X/hdS7+7+XR6sn/ra7/ J4dFCf/XykAt/m/DYXG2/7Nu7muodkbpUealj91vFP4vMmrparHg/2T+Q0b/Zzr8X4ZW4f/w f39bhf9LjML/xUb93YP4vww7EP+XGFWZ/xs1/i9TFP4P//e8B/F/6VGX8X8yPQ//t8VTLPo/ ecWY6P/C9Mo3/m/e6dzt/8L8VPwf/g//9xT1nf6v0/i/yKgY/6enPtwik/yf38ZHrP/nr5FZ /Z8eF9f/0yb7+n/3Vr1+WPi/j/N/ZriS/2sm1yr838LQz5XX/+uG7P5vff0/PWvcXv8XXi+3 91ad7/9kBnUR/zfMEo/1f9L7rc7/hf52Af83+O0W8X/y1FjG/8mRneb/ZttQCv+n8H9volZa hf/biPLwf1n9n9+utQlRT9vA/6nD/J90SXP6P2VPX/9vMrnX/8P/Heb/fKcP/7c0SXXu/9y3 xuD/4qLwf5WWu/+zB2bE+T8j/q/7Ufi/44s7y/F/8ePe+L/0VuH/EroVhfyfeyV8uv/rjkB5 +L/EqGX/56ZJhWpnlB5lVtc4G/fG/6VdA0v5P9b/w/+tRlXm/9xIFv4vMao+/+e/lBj/FxmF /8v8fID/S9yBrP+XGIX/e4nC/+H/8H/LUfi/1Gad7v/CDOoi/k/+Hf/3Df4vzC3H/72MJzz5 vwb/l+b/Cq7/p/B/Sf7vI9b/y+//XNTC+n/WtlWu/xemq+L/3vg/d7W4kv/zVwv83+vQz6X9 ny7n//pp1rhq/N/oW1XE/4UJEEX8nzShiP+TjkQJ/xd6YiX8n5ziJfyfkqedEv4voL0k//e0 DaXwfwr/9yZqpVX4v40oD/+X0/81YcwxoR/4tA33X2v0f3fViP/L6v/a21OwrtL/+e3i/zY8 ieD/crQK/0f5yHL3f8OBGXH+rxX/Z38U/u/44s5y/F/8uDf+L71V5/q/I6YS1+f/zLjq/0QK FfB/JrxfLOH/7BFRV/J/7rdDtTNKj/4FR6h8FP4vMmrparHg//wEEvzfhncU+L/0qMr8H+v/ 4f8W/B/r/+1pFf4v8/MB/i9xB+L/EqPwfy9R3+b/Rv+X4v+iovB/3+n/ptk39uP/3niK5fX/ Qifaz4jd6//MvFr3f9OjSvV/j/mphfxf2xfzf2Yo5f+8U1r2f3O6gf9b9X+s//c9/o/1//B/ Sm32f6Ou0v+NYQYS/u856ur+z9898H+vQz+n+T9tavR/ZtX/jbPG1eP/5OVsCf8XpqCX8H+d bLey9f/CSWRSHlDD3eNxE1n2f8Lbyvg/+ZDwf/i/p0/rsCj8H/5vJeqpUfOniHr8Xzc+qr3+ b74N99iI/1uIwv8t+j/rbuT1+b8A/2rzf35AFf+38NiN/8P/UZbK3f+NB2bE+b/O+7+u+VH4 v+OLO8vxf/Hj3vi/9Fbh/xK6FaX8nznf/7VteEGD/3t7WJzt//zTR6h2RunRvxEIlY/C/0VG LV0t8H8J7yjwf+lRtfk/a/B/qVH4v9cs/B/+D/+3GoX/S2gV/i8xCv8X2Sz8373C/+H/6vZ/ YdQsyf+F1+pv/F94HZy2/t/fD6vC9f/wf1/j/9y8BPxf1Gf1x/91ukb/94g62v91Df4v8mqx zf8Nesjt/9wwE/4vZgeq8/zf7S58Jf/n1ykr4/8s/u9b/F/bZ/d/6+v/4f/wf/i/iMOifarw f/i/N1FPn9ZhUfg//N9K1FOj5k8R9fg/6cpa31Xa6//m23A/WaP/u6tG/F9m/2dvD6h5/d+t cfi/LK3C/+3zf61t8H+RUfi/Ssvd/00HZsT5v178n/lR+L/jizvL8X/x4974v/RW4f8SuhWF /J+2H+D/tP9Tyvi/I6jhlfyf62aGameUHv0vh8pH4f8io5auFgv+z/17Vv/n3ifh/5Jbhf/7 Bv/H+n/4P/9bT/7Pfykx/i8yCv+X+fkA/5e4A0v5v1Hj/zJF4f/wf897EP+XHoX/236w4/8U /u/da/WS/q/vSvk/3az5P/no8H8L4wlz/8f6f9/j/7Sp0f+9Xf9PrsqJ/s9Xl/J/XWP7Ktf/ kzHVIv5PWl3E/7lLUV7/d7sLX8r/yXDjd/o/W6X/c5/Vyf7PTOX8XzA3UiX6v99r4KL/m0wx /xekXBH/N1Xp/0zzqHb7v/lDj8L/4f/+bOM1at6uw6Lwf/i/taiVVuH/3j2JnOz/5Apq/f+6 1//Nt+F+CP+3EJXD/8ktPqP/a5uz/d803TbB+n+LUZ/n/2QqE/5vYZLq3P+x/h/+jxJK8H/m SGsX5/+s939t+6Pwf8cXd5bj/+LHvfF/6a3C/yV0K0r5v2bN/8kXoJXwf2YKdCMfyrOr/q/J HXUt/ze6LmKodkbp0Z9zofJRl/J/wwFRy/5vlPkP+D/831N5+jH8H/5v4cfwf/g/Kfg//B/+ b7f/Y/0//N8/ovB/KR8W/i896ir+Tw52/N+WTif+7zXqI/3fo1WH+79uXPZ/d7OB//u3/2P9 v1T/p7tl/9fKh5Rz/T/TVej/3q7/V8L/Baf0nf7PLbe6sP5f2+H/vsb/DY5M5fV/7hp4Hf8X 0EsR/9dm939tlf7vA9b/q9L/mabL7f/0uOr/ZAZ1kfX/5GpSwv+15fxf2G4R/yd3DPwf/g// h//7c1jg//B/r6366/8GubYOvl+wM+ppG4r1/77I/6n2bP9nrMX/4f/q8n/uW87q83+3Ozn+ jxJb7v5PH5gR5/8G8X/9j8L/HV/cWY7/ix/3xv+ltwr/l9CtKOT/jPkA/9eFuSpZUR7+LzFq 2f+5J4dQ7YzSo389Fiofhf9LjML/RUbh/+4V/g//t/Bj+L8V/+eWccD/xUbh/zI/H+D/Endg Kf9nBvxfpij8H/7veQ/i/9Kj8H/bD/aL+78QVcL/hcsf/u/frXIgpYz/UyP+D//nf/7T/F/X Z/d/qsb1/wr6v9ZW6f/U4vp/7dDp3P5Pmw/wf2G6Kv7v3/7P3fAv5f9kuBH/9zn+T33A+n9t dv9nruX/5BGxiP8LzSnh/0w5/2eaR3Ww/9M51v8LuuF3B57t/+4fUhH/1z6q3f5vtg2l8H8K //cmaqVV+L+NKA//l9H/WXnasf5D2rv+33wb7ofwfwtR+L9F/zc0tsf/rQx+f5r/Gxr83xb/ 50Y58X9xUfi/Ssvd/5kDM6L8n2nE/zU/Cv93fHFnOf4vftwb/5feKvxfQrfidP93yHm17P/G 8IKmgP+TmQL4vy0zzBf939j/Vjuj9Og/hFD5qEv5P3tA1LL/G9wOxv9teUeB/0uPwv/h/14O C/zfSxb+D/+H/1uNqsz/sf4f/u8fUWf6PyvP+Pi/qCj835f6v/DeFP+31//dM5L8n5lXdfq/ 24Njfev/rfu/sBQG/u/f/q+1+D/8n5L/ZV4V83/um7FL+b9mzf+FF3NV+b9+yu7/7q16/bDw fx/n/9r+Wv7Pf3/nl/q/Cf/3/f7PhkGHyvyfHHpF/F84GUr4P7k0VLb+393/+eM10f/9Xm4X /V8vQ2tF/J8c2SX8n5rkwpTi/562oRT+T+H/3kSttAr/txHl4f9y+j8/MHx7Yk7oBz5t4xGF /8P/LbTqj//rbRvW/9sd5eBf81vJs/D5/k8Gberyf3byfU3838Ik1fr9321H4f8oseXu/9oD M+L8nxb/Z34U/u/44s5y/F/8uDf+L71V+L+EbkUh/6ftB/i/KdAN/N/bw+Js/+dedN+rnVF6 9Hs8VD7qUv6vPSBqZf0/P6EI/7fhHQX+Lz0K/4f/ezks8H8vWfg//B/+bzUK/5fQKvxfYhT+ L7JZ+L97hf/7ZP+nm9Ac/N9e/xe+sKmI/wsTP77R/5mmudT6f/i/Tf6vG/F/af6v0/i/yKjT /N/q+n81+r9hyO//LP7vW/yfP4Uv5P/81eRb/Z/C/x3j/9o+t//TF/N/MlRbxP+Fx8US/i9M kSri/8Ijvu/dHuz/5I6B/8P/4f/wf38OC/wf/u+1VS/+b5we1V7/N9/GQ8rV5f9Mh//L0qq/ 6/9105DZ//kRafxfhlbh//B/j0rj/yjx5e7/ugMz4vyfEf/X/Sj83/HFneX4v/hxb/xfeqvw fwndilL+r1n1f9KfKOH/wvxD/N8X+D/3KtNVSf6vfVQ+Cv+XGLWy/p9rVV7/Z/F/GVqF//sG /2cN/i81qj7/57+UGP8XGYX/y/x8gP9L3IGl/J8Z8H+ZovB/+L/nPYj/S4+6iP9TQfLg/7Z4 imX/FyamJvm/8Fr9jf+bdzq/zf/poa3R/5k1/6fndAP/t+b/WP/vi/yfLef/bI3+z42SLPu/ 0Oqq/F9rp9z+z2nh0/3fGGYg4f+eo/6u/9eM+L/IVm30fxP+b5P/06ZC/+dujfi/xM8K/6fi HlA/zf/ZFv+H/8P/ZYlaaRX+byPKw/9l9H+j9BOl2hn1tA3fD6zQ/w0G/5elVX/8nxn71vu/ 1uyN0sPknidC5cb3Lf4vS6te/J/M48T/LUxSnfs/N8pZn/9zBhr/R4ksd//XH5gR5/9a8X/2 R+H/ji/uLMf/xY974//SW4X/S+hWXMn/jeEFDf7v7WFxuv9z70FCtTNKj35mSKh81KX83xFI ZNH/yRww1v/b8o4C/5ceVZn/U6PG/6VG1ef/3Ot7/F9sFP4v8/MB/i9xB7L+X2IU/u8l6tv8 n0ycwf9FReH/8H/X9H829GCS/J+ZV/i/7/d/agxzy/F/L+MJc/+nWf8P/ydbOcn/abvs/7Tx D4m5pxZdxf+pqddDlf5PxlTxf3+j/vo/ay7l/3x/Fv+3MPSD/yvk/ySjNv8nnfUS/i8coUX8 n1xbS/i/e//F926P9X+mfVQH+z9T0P/Jh1TE/8neSvN/s20ohf9T+L83USutwv9tRHn4v3z+ T9tGP6p9Uc/beETV5f9G1v87wP/dbp/97aqnu/uY4z7/N7prTKjUZ/g/GcsP1d7B75cXFWf7 P/9AgP9bmqQ693/GnO///ChCXv/n3tbi/yhx5e7/7IEZcf6v8/6va34U/u/44s5y/F/8uDf+ L71V+L+EbkUh/6e6Nf8nh0UJ/9dqH4X/23BYnO7/3MhzqHZG6dHv/VD5KPxfYtSy/5NjDv+3 4R0F/i89qjL/x/p/+L8F/8f6f3tahf/L/HyA/0vcgcv+z1/2OiNd073+r5tV+D/836f6v17e o+P/oqLwf9/p/0Y5BvB/WzzF6f5PWpXm/8L81AfdON3/BcckzanG/8kHg//7t/9j/b8a/F+Y +PWV/m91/b8pu/9zfG3F/4XhBNnPh/o/Py+8gP8bmlH832CT/J9+VPi/HZdb/F8h/9f6Cv+3 2/+1j2q3/2vnlbL4v4UdmOz/9OTnVeb0f242O/4vrlX4P/zf0k1ktg2l8H8K//cmaqVV+L+N KA//l8//GeM76KHaF/W8jUfUmf5vyO7/Jnu6/5PnxLz+T5/s/+w43D6k203fSnP2+b/ePWKE SuH/8H9R/s+4l+lZ/Z8fOTvX/3Ud/o/yCeXu/4YDM+L8Xy/+z/wo/N/xxZ3l+L/4cW/8X3qr 8H8J3YoL+T8zhrkq+L+3h8XJ/m9s3CZCtTNKj8IVRvs7EHMp/9dkiGr+RC37vxb/h/+7iv/r w1t+GfrB/+H/XLEyOwX/t2UP4v8y7ED8X2LUqf7Pz/PE/22Jwv+9RH2b/5P7O/4vKgr/h/+7 pv8Lb40r83/h6lfC/4WLawH/Z/rwnWopl4uN/i88+9bl/4KNx/8tHOzb/J/IhCL+T+5OJfxf O8kgQAH/N/gHiCL+b/SjL9rKI8veqUXdrPoE/6d9v7mA/+uHofX+L2XG2WT9PTFUn+H/bPiQ Cvg/M7+J7PV/4UN64//cdvF/i1Eb/Z+/7xbxf4NWhfyf9V9jUMb/BV+T5P/m21Af4f/cVaiQ /+vl30v4P39hKuP/pNVl/J+0uoj/kyYU8H/halLE/+nQ3/bH66H+r598VBH/J59lGf8XxkZS roHzbSiF/1P4vzdRK63C/21Eefi/jP5v8BeuUO30f0/beESd6f9CDzrJ/7Vh2O1z/J88Cyf6 P8n4FP/X93q07qGgkceDff6vcY+DoVKf4f+kz1Kb/5Pxl7r8X2tdb6I6/+e/UA3/Rzm73P3f eGBGnP+z4v+6H4X/O764sxz/Fz/ujf9LbxX+L6FbUcj/dc2q/xMpVML/3V/Q4P/eHhan+z/X zQzVzigtI9n6PqB9Uf+X9Rq47P/cF93i/xaj8H/3qhb/JwMI+L8tUdfxf9JVwv9t2oP4vww7 EP+XGHWm/7OD6zJl9X+6wf9lisL/4f+e9yD+Lz3qMv4vvDfF/+31f10G/xcGz9/6P5nO4vue u/3f3wm+y/5P/j2n/zPTsv+7r5SX0f/pdsX/BR6S0f/pbs3/yXbxf/i/WelMeAyWPsaR/q8V DpDT/7Vr/k8mpuX0f+2a//N3qjL+z+9+bYPi2Tm1aH5Y/MP/Bdkt+/lQ/2fl++8O93/dNA36 dni2Q7P/cjv1/i4Xquv5P9lbzezl5G7/93jhveT/rLvA5vV/esT/RbYK/1ed/3OPOfi/pSj8 H/5vIQr/F5bwS/N/YRlAhf9T+L83USutwv9tRHn4v3z+r/VrX92rfVHP23C93A/wf3ITqcz/ he8XT/J/0hn/GP/XDc3tvuRuVN3uKHeNaX4rhf/D/8X4PzMNFfq/vp3wf5QPKHf/Nx2YEef/ BvF/9kfh/44v7izH/8WPe+P/0luF/0voVlzJ/03yjjUjyrP4v4P8n+uNhmpnlB6H9lH5KPxf ZNTS1WLB/8n8B/wf/u+pPP1YLf5P3krk9H9tj/9LjTrf//nbRkb/56Zx4v9io/B/mZ8P8H+J O3DZ//l+bVb/p/B/yXcR/F/yDlz0f/IaCP8XFYX/w//h/472f7Mnsa/zf3pt/b9mNo09j/97 tOqP/xvmj8NZ/J9t1vyfNKEy/yfzAXP6P9FX+L+9/k+NZmX9P/n3nP5Prfk/mSGd0/+pNf/n W5XV/7klPMv4Pxd1tv8zpdb/G/qp9/6vb/cfgVNvp0f126rXD6ug/xvkT0nzf+HB4J3/k8Ot iP9rMvs/Nelr+T8/97+E/7N2UIX83+B7pl/r/5qz/Z/pu9z+z3/V3rL/kyO0hP/zl4mc/k93 q/5POusl/F8XruwF/F/osxTxf9KRKOH/TPuojvV/Vi7jRfyfjJOV8X/to9rt/9p5hf9T+L83 USutwv9tRHn4v4z+r/H9xFaGBXf6v6dtKPfdAqf7v7DxNP8XngPDHXI83//J9SHR/4UPST9F neb/hvZ20N0+gSmcUPv8n3Z9yVApP2vqfP8XBm2SBr8/zv/5+Ue1+b9B+rMZ/Z+boHW2/+t6 /B/lA0rwf+2R1i7K/93+Euf/bpXC/x1f3FmO/4sf98b/pbcK/5fQrSjk/9ykhNP9X5h/iP/7 fP/nX8GFameUHuWV6zj87kD8X2TU0tXi1f/12df/0wb/l6FV+L9v8H+s/4f/87+F/1P4v607 EP+XGHWm/xu67Ov/mQH/lykK/5fZ/41y2cP/4f9Wo2rxf2F2Jf5vk6dY9H9h1m0R/zc9qt3+ 72V+ahn/p0Z7Kf9nq1z/L7v/MyP+7/v9n3xp3Xf6P2PL+b9xzf8Fp1TA/7WNfP/d4f5vGobJ +7922H+5nfp+fFS/rXr9sPB/+L9z/Z9MRPxS/2c/wP+FwybJ/823IZ/Vyf7Pj5YV8n82DDoc 7/9G32fPuv6fexhe9H/hLl3C/9lw+hXwf4fMT130f/o+Ndr3bg/2f/ZR7fZ/Zl6t+r+pnP+z Bf3f8Kh2+79hXuH/FP7vTdRKq/B/G1Ee/i+f/zPWD2/ensrH3VHP23hIuQ/wf/7BKtH/hRuR 6c73f/Kk4he5TvV/j4mP5/q/qbdt43ovcj/f6f8a15sLlfKzpvB/OVp1Df/Xt7n9n3tqrM// uVbh/yiR5e7/9IEZcf5Pi/8zPwr/d3xxZzn+L37cG/+X3ir8X0K3opD/c5MSTvd/MuCdGeXh /xKjlv2fG4UO1c4oPfp3UqHyUfi/yKilq8WC/5P5Dxn9n+nwfxlahf/D//1tFf4vMaqU/2vw f/i/9R2I/0uMwv8ltAr/lxiF/4tsFv7vXuH/8H/4P/XvQWn8X33+T16L4P/+7f9Y/w//dx3/ t7r+Xzn/Z/y88Kz+7/Yw9+r/dNOOsv6fnvZfbqe+s4/KwZMr+b87/Cvg/wZ3bcvr/9wpjP+L atW1/d/wqHb7v2Fe1en/Rvwf/s//aDOv8H/4v5dtKIX/U/i/N1ErrcL/bUR5+L+M/q/1nQrT NfujnrfxiDrT/0k7pNrr/54mqX7E+n/1+T9nMsb29gkMfcL6f/3k1/+TSskQCf4vQ6vwf9/r /8yQ3f+N+D9KdLn7P3NgRpz/M+L/uh+F/zu+uLMc/xc/7o3/S28V/i+hW1HI/2n7Af6vD3NV 8qE81v87yP8Zt91Q7YzSo++nh8pH4f8io5auFq/+r5X5Dzn934j/y9Aq/B/+72+r8H+JUfi/ 2Ki/exD/l2EH4v8So/B/Ca3C/yVGXcn/2cYf2vi/qCj831f6P3UfNMP/7fV/VmYPJvk/Wefn rf8LT/d+pu1u/xc+rMe77jL+T+t2xf8JB/hO/3c7ilf834T/w/+d6v8s/g//V8L/9d2S/2sb q73/axLw0NT7y0So3JX7fP8XRv2lSvR/szn6J/s/9zUGef3f7bDA/8W16vP834D/S/J/fmp0 If8XzE1t/k+mMpXwfzImV8T/yRFaxv9JR6KI/wvXWfzf+77Fsv+bHtVu/zfNK/yfwv+9iVpp Ff5vI8rD/2X0f40fOTM6YR3o5224Xm6N/u8D1v9rwzCxPO3s9X/jvDrd/5mxs/ZWTTqMzu1a /0+7LywKlTsSLf4vS6uu4f+6Ibf/89+cdbL/8wOB+D/K2eXu/9oDM+L8Xyv+z/4o/N/xxZ3l +L/4cW/8X3qr8H8J3YpL+T/pruP/vsD/uWeqUO2M0qNfdiJUPgr/Fxm1dLVY8H9+QhH+b8M7 CvxfehT+D//3cljg/16y8H/4P/zfalRl/m+O8vB/+L8/Ufi/lA8L/5cehf/bfrBf3P/ZR7Xb /728Vsf/pR2CpfyfWVv/D/+H/7uK/+vaIBPwf/88LLpuzf+FF3M1+T9j+za3/+s+Yv0/+ZDw f2/8n7rW+n+eROH/FoZ+Luz/uiG//zPX8n+yPHgR/3df2bWA/zNydy/h/8J9sIj/C1H4v/d9 iyX/d7eajdxId10Dn7ahFP5P4f/eRK20Cv+3EeXh//L5Pz36/6on35/YF/W8jQ/xf+Oj2u3/ plmF/8vwtnHJ/3X9rR361ptoUvyfsb+Vf4LH/2Vp1Yv/G/B/W/yf6c73f+OU2/+51y/4P0pk ufu/7sCMOP/Xef/XNT8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/1PdB/i/JsxVyYry8H+JUcv+ b+h/q51RevQTP0Plo/B/kVFLV4sF/9eqzP6vN/i/DK3C/32D/2tG/F9qFP7vNQv/h//D/61G Veb/WP8P//ePKPxfyoeF/0uPwv9tP9iv7f/ms253+7+/0ytX/F//qHb7v35elfN/ahqK+T8z lPJ/Sq35v3Adx//92/8Zg/87yP+Fr0jO6P/smv+Tu0gB/6cnm9v/hSj1t9jez74J1c47vpEH zVCpIA8q83+jXvJ/XWOyr//n7Mvp/i+Qqcr8n5t+yfp/i1Gb/F/jr7P4v4Whnwv7v9v+xf8l +T81ST+xiP8Lt98C/i9MkSqy/p9cxkv4vzs1TPJ/cp39IP83yuN8Ef/XP6rd/m+2DaXwfwr/ 9yZqpVX4v40oD/+X0f814b293t8PfN6G+pVydfm/bqzR/7mx21P9Xzs1t77HrZp6szdKD537 /rdQKdb/w//F+L9e69z+b3bDP83/9S3r/1E+oNz9X39gRpz/68X/mR+F/zu+uLMc/xc/7o3/ S28V/i+hW1HI/3XNB/i/+wsa/N/bw+Js/+d7tKHaGaXHcXhUPgr/Fxm1dLVY8H9+Agn+b8M7 CvxfelRt/o/1//B//ree/Z/F/+H/1ncg/i8xCv+X0Cr8X2IU/i+yWfi/e4X/w//V7f/k3zP6 P23W/F+Y3SzkYKf/+2tflv2f3Otzrv/X9jX6P7vm/4Ywtxz/9zKeMPd/V1v/z38GOf2f+0Km 6/i/2/0qt/9znmJx/b+pcdFGDyl3fCt7Trbhpqss+7/Q6u/0f8vr/93O2anK9f/wf5v8n78w 4f+iWnWa/1Mr/m9s8X8p/k8P7maI/1uKep51a/F/R63/J8cA/u8b/N/wqHb7v9k2lML/Kfzf m6iVVuH/NqI8/F9G/2dkAEuqnf7vaRuPqLr832Txf1la9Wf9v6m3vfN/ptsdpYfOzQUNlcL/ 4f9i/F87ZV//z39z1rn+r2uy+z837Qz/R4ksd/9nD8yI839W/F/3o/B/xxd3luP/4se98X/p rcL/JXQrruT/Qncd//cF/s91M0O1M0qPfvQ6VD4K/xcZtXS1WPB/jcrs/7oG/5ehVfi/b/B/ bY//S42q0P+x/h/+D//3Jwr/h/9b+DH8H/5vqVn4P/zfwo8d6//C5ED8317/F97d5lz/z9bo /6wp5v8cSDnb/4WZc/i/f/u/q63/h/+7sv8zVfo/N2Xv1f+ZSQ91rv8nOxj/h/978n/+mMP/ vQ79XNj/NY27TOT1f+PF/J90zor4P2l1Ef8nR2AR/xemRvveLf4P/xfCfkdS8H/4v6VW4f82 ojz8X0b/10pHWqqd/u9pG6rS9f9sU6P/m6G8k/zfMHXe/zWt2Rulh9YtnB4qhf/D/8X5v+zr /7W2qdD/mQ7/R4kud/83HJgR5/8G8X/2R+H/ji/uLMf/xY974//SW4X/S+hWXMn/DeEFTT6U Z/F/B/m/qf+tdkbpcWoflY/C/0VGLV0tXv2ff9GX1f+ZEf+XoVX4P/zf31bh/xKjWP8vNurv HsT/ZdiB+L/EqMr83xzl4f/wf3+i8H8pHxb+Lz0K/7f9YMf/qULr/4VO51f6v6Et5v8erTrR /8lrEfzfv/2fG2rH/0V9Vvi/Cv1fuLLLTx/q//wdv4D/a03f5vZ/Gv/3Nf7PHRb4v7hWXcH/ 2XL+79aRPt3/ub8W/7cUhf/D/y2dwvg//N/WKPwf/m8taqVV+L9/P3af7f9kyTQtIyU7/d/T NtyjWo3+r61y/b/T/V97O2yc/xtHOfR2+j/3YBUq5WdN4f9ytOoa/m/s8X9b/J8bD8T/USLL 3f+NB2ZE+b+uEf+nfxT+7/jiznL8X/y4N/4vvVX4v4RuRSH/Z8YP8H/yMMX6fxsOi7P9X2f6 32pnlB59jzZUPgr/Fxm1dLVY8H/+mGP9vw3vKPB/6VH4P/zfy2GB/3vJwv/h//B/q1Gn+j9/ 483q/0aN/8sUhf/L6/96eVOL/4uKwv/h/36HVK/l/4LwKOH/Zpe/3f5P9kx5/9fZYv7PgZSz /d9wn/ghP43/W/Z/bqgd/xf1WeH/yvi/scvt/9woyXX8X2d09vX/xk/wf004PML+VPdrAv6v fVR+wd9L+T9/3030f/IhFfd/2qz5vya7/2svtP5fNzXuZljI/wXIUcD/yYhgVv/Xrvm/UfqJ JfxfeFws4v+kCUX8X+i/+N7twf4vKH1/vO71f+Eh9/dyu+z/rOz+Ev4vrOFTxP+FPn2S/5tt Qyn8n8L/vYlaaRX+byPKw/9l9H9yE7n1zezuqOdt+HGLCv3fYPB/WVr1x/+Z6fYY5vxftztK D63r1oZKfcb6f8KuavN/ve9r4v8WJqk++b+mRv/nnoXxf5TIcvd/04EZcf5Pi/9rfxT+7/ji znL8X/y4N/4vvVX4v4RuRSn/Zz7A/4WZRPi/L/B/ff9b7YzS4zQ8Kh+F/4uMWrpalPB/rP+H /1uNwv/h/14Oi/r8X4P/w/+t70D8X2IU/i+hVfi/xCj8X2Sz8H/3Cv+H/8P/qZjplev+b3xU X7f+38X8n5WzCP+H/5uVSv2fDeOh+fyfvZj/k8tEVf5vbHv833X93+0n8X+RrcL/Vef/3GMO /m8pCv+H/1s6hcMYH/4P/4f/e4nC/22NWmkV/u8fj93n+7/w2K3GKSHqaRsPKVeX/7uvanim /wuLVMgfvTNKXuTdq/P93zDeere6la/u2O3/3KLBoZpF4f/wfwutusT6f60fRcD/Uc4uwf91 R1q7OP9nvP9rux+F/zu+uLMc/xc/7o3/S28V/i+hW1HI/2n7Af5vCC9o8H9vD4vT/d/Y/1Y7 o/To59SEykfh/yKjlq4WC/5P5j+w/h/+76k8/Rj+b83/WYP/S43C/71m4f/wf/i/1Sj8X0Kr 8H+JUZfyfzLhDP8XFYX/+1L/F96b4v92+z/pnhXxf2F281f6v6G9lv+T7eL//u3/2g7/l+b/ 9FTK/2mz5v/aMB6az/+1+L+FK/tX+b9JT/i/6/o/D5Ov4//kQ9LhzpLo/34/q0X/1w9a5fV/ Sn2C/5t9u8Vu/zfOq6v5PzkZ8H9f4P/CZbwy/2faR7Xb/+l5te7/ZJ8U8X9yBBbwfyp8+/OU YqDn21AK/6fwf2+iVlqF/9uI8vB/Gf2fFd5mp4R+4NM2XJcJ/7cQhf9b9H9jf3sounWUwlj+ Pv/Xu45JqNSHrP8n3TH83xX9nx7P939W4/8oH1Du/k8fmBHn/1rxf/ZH4f+OL+4sx//Fj3vj /9Jbhf9L6FZcyf/Jn4L/23BYnO3/evdMFaqdUXryb15D5aPwf5FRS1eLBf/nR57xfxveUeD/ 0qPwf/i/l8MC//eShf/D/+H/VqPwfwmtwv8lRuH/IpuF/7tX+D/8H/5PRU6vrND/1bn+n1r1 f9Iq/N+//R/r/32P/5u16s91Cf+X6v/CSLL89Jf5Pxf16v+6ZjL9rbodHAn+z3pLECr8347L 7Wnr/93uwpfyf/6Yw/+9Dv1s9X/To9rt/6Z5db7/Gyfn1vB/S1Fb/Z+IhhL+L8yYLuL/5Npa wv/dp0b73i3+D/8Xsn5HUvB/+L+lVuH/NqI8/F9O/yfHnFR7/d98G+4na/R/91UN6/J/buz2 VP/XNfr2IemuM6bbG6XHxo/4SqXwf/i/GP/X6ez+b3bDP83/9az/R/mEcvd/5sCMOP/Xef/X NT8K/3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/1PdB/i/MJMoI8qz+L+D/J/77VDtjNKTvD+Uykfh /yKjlq4W+L+EdxT4v/Qo/B/+7+WwqM//Wfwf/m99B+L/EqPwfwmtwv8lRl3J/1kZ0ML/RUXh /77U/8noLf5vi6c43f9JFP7vzSHYd+ev/xemmOP//u3/WP8P//fZ/q+RTlya/7O/oyQV+j93 uV3yf2NTpf+Tm0gR/9fOF5Hd6//+Dv2U8n+3Z3z8X1yrPs7/Df5Pyer/dH8h/3fA+n+uy7ns /4bZk8jB/s/f3bP6v9thsez/xDEV8X9hB5bwf/LplFn/L/RfGsk91P/ZR7Xb/5l5teb/Bjl3 S/i/8BK1jP8LR2CS/5ttQyn8n8L/vYlaaRX+byPKw//l9H/STxwauz/qaRvqI9b/G+UmUtn6 f9L3qGr9v65xPSbddfJEt9f/uQ5gqNRH+L8gUNukmaNGz6tP8H/+ua02/2d0bv/3Cev/5fd/ Gv9HiS93/9cemBHn/3rxf+ZH4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n9d8wH+j/X/vsf/uZHn UO2M0pMfqwiVj8L/RUYtXS1e/Z+W+Q/4P/zfU3n6Mfzfmv9re/xfahT+7zUL/4f/w/+tRlXm //oO/5cpCv+H/3veg/i/9Cj83/aDHf+n8H/vXqs7p1Th+n/r/k8urvi/f/s/1v/7Iv9nq/R/ YzH/56hhhf7PXW4X/F873v5a3XWd2X+5nazf7aHyOxD/F7MD1Xn+72rr//n7bgn/Z1v834X9 n8L/4f/8jzbzCv+H/3vZhlL4P4X/exO10ir830aUh//L6P8GeS0x+AHJnVFP26jV/91bhf/L 6/9aY7T3f9rsjXLwr/utFP4P/3ey/3Njt/i/uCj8X6Xl7v+6AzPi/J8V/9f9KPzf8cWd5fi/ +HFv/F96q/B/Cd2KQv6vrXP9P/zfQf7Puh5tqHZG6ckfxaHyUfi/yKilq8WL/zP+ySGr/zP4 P/zfWhT+D//3cljg/16y8H/4P/zfalRl/s8M+L9MUfi/zP5Pptnh/6Ki8H9f6f90E5qD/9vr /8K0Zuv22m7/186rVf8373Tu9n9/P6wK1//T+nz/F2bO4f/+7f9Y/68G/ycv/HL6P91XuP5f pf5vef2/W8+5ye3/3DDT6f7PBvTShf2p7tcE/F/7qPxdGP8X16qN/m/C/13Y/7H+H/5PNtLM q2v5PyvapVb/l2BfnrahFP5P4f/eRK20Cv+3EeXh/zL6Pzv47Q7+RrV3/b/5Nh5Rdfm/u+jB /2X1f+04TG3m9f90M57v/+TVe3X+z0+bxf8tTFKd+z9tavR/psP/UaLL3f/1B2ZE+b++Ef/X /Cj83/HFneX4v/hxb/xfeqvwfwndikL+z30p8en+bwpzVfB/bw+L0/1f2/9WO6P01EyPykfh /yKjlq4WC/7PPZHj/7a8o8D/pUfV5v+swf+lRlXo/xr8H/5vfQfi/xKjKvN/o8b/ZYrC/+H/ nvcg/i89Cv+3/WDH/6ky/m8+NfLr/N/QVuj/3Gv1Zf8X5pjh//7t/1j/D//3of5vavxs3jHI kLSpRdM96jr+zw4d/u9b/F8/Tpn9n1vzAP8X16qz/J825fzfcC3/526GrP+3FPUy6xb/F9cq /B/+b+kmgv/zFf5va9RKq/B/G1Ee/i+j/5vG6VHtjHrahqp0/b/J4v+ytOqP/+tt27lxi6bb HaXHxiGnULn/MOH/srTqGv7Pv3XO6v/cBK2z/V/X4v8oH1Du/s8emBHn/7T4P/Oj8H/HF3eW 4//ix73xf+mtwv8ldCuu5P/CUoT4vy/wf26kO1Q7o/Qkbwynx5sX/F9k1NLV4sX/tTLvMKf/ U/g//N9aVG3+j/X/8H/+t/B/Cv+3dQfi/xKj8H8JrcL/JUbh/yKbhf+7V/i/T/Z/6j5ohv/b 6//Cu9s0/yddPPxfHv/XjsXW/1Nr/i/McsT/4f9m5QD/1zY1+r9hzf+Z3P6vtf/2f0MY+Eqb WiT317FK/2eGRf93eyLI7f/cDjzd//XhEbYL+1Pdrwn5/V8Ypijh/1zXL+/6f7fD4lL+z09E rM3/+ZM2q/9rh+v4v9sJ5f7aUv5PDvbv9H92zf9JH6mM/5OrSQn/Fy7jJfxfU87/6XL+T46H Iv5PPiv8n8L/zRt1XBT+D/+3EvXUqPkjcy3+79Yb632V4P+et+F+8nz/Jx3tRP8nd/LQu23x f4f4v9beruXO/5lub5SDf+1vpfx34Zzt/wL8q87/+TMd/7cwSXXu/5yUO9n/DW12/+ei8H+U yHL3f8OBGXH+z4j/634U/u/44s5y/F/8uDf+L71V+L+EbkUp/2c+wP+F94v4v8/3f4Ppf6ud UXryvxAqH4X/i4xaulos+L9WZfZ/2uD/MrQK/4f/+9sq/F9iFP4vNurvHsT/ZdiB+L/EqMr8 X9/h/zJF4f/wf897EP+XHoX/236wX9z/TY+K9f9WX6vrzla4/p/C/6X5v67B/6X5v6Yt5v/U B6z/99X+r871/1zUgv8bJ5vb/91b9fph4f/S/J91jzv4v8Uo/N+X+j9t8H8LO/Aj/Z/C/32/ /yu3/t/ghw/wf0s3Efyfr/B/W6NWWoX/24jy8H8Z/V/jcdHtMrE/6nkbrkeE/1uIwv8t+r/R DSjl9X/u+27xfzlahf/b5/8+YP2/A/zf7QTD/1Fiy93/jQdmxPm/Vvyf/VH4v+OLO8vxf/Hj 3vi/9Fbh/xK6FYX8n24+wP9N4e00/u/tYXG6/+v732pnlJ48pAiVj8L/RUYtXS0W/J+fQJLT /5kO/5ehVfg//N/fVuH/EqNK+T+L/8P/re9A/F9iFP4voVX4v8SoS/k/Gb3C/0VF4f++1P/N Zuzh/954Cvxf1HFxmv8zppj/s2v+b8T/bfF/bYf/+xr/V3D9v9ln9RSF//se/zeY3P7Pz2I6 3f/J5bYu/9e7pTLy+r/bM/6l/J/fZSX8X+8u6Vn93+1gxv/FteoD/V+AHAX832gK+j8RDSX8 nw1zS0v4P7k5FfF/5pFYjf+zsvEi/i+s4VPE/9lHtdv/2XmF/1P4vzdRK63C/21Eefi/fP7v 1uf0l9vBJBjop224gYka/d99VUP8X2b/1w9Dbv83Q3n4v6z+zz/D4f+WJqnO/V+d6/91+D9K fLn7v+nAjDj/13n/1zc/Cv93fHFnOf4vftwb/5feKvxfQrfiSv5vCC9o8qE8i/87yP+N/W+1 M0pP/qIZKh+F/4uMWrpaLPg/P/Kc0/+1Fv+XoVX4v2/wf53F/6VG4f9es/B/+D/832oU/i+h Vfi/xCj8X2Sz8H/3Cv+H/8P/qTfTK9t5ter/Qn/9O/3f0Bbzf930Aev/Savwf/i/WTnA/7UN /i8yapv/G7vc/s9FXcb/dcYMvfd/CUfgZP2hFyqZxYT/izsszvJ/o8b/RbYK/5fV/7nP6lz/ dzujusz+z815xP8lflb4PxX3gPr3oeds/zfIuVud/xsf1W7/N84r/J/C/72JWmkV/m8jysP/ 5fR/8gbEplwDn7ahflfKq8v/3VUj/i+r/+t0f/tTtPvaot1Remxchz9Ut5/RFv+XpVWv/k8G 6fB///Z/bqW8s/2fGw/E/1FOL8H/9Udauzj/18v6f/pH4f+OL+4sx//Fj3vj/9Jbhf9L6FYU 8n/dJ/g/eZhi/b8Nh8XZ/m/U/W+1M0pP/pkqVD4K/xcZtXS1KOH/WP8P/7caVZv/0xP+LzWq Qv/X4P/wf+s7EP+XGFWZ/2tH/F+mKPxfZv8nM6Twf1FR+D/83++Q6pX8332Ovq/2+r8nEuWY Dev/xUWd5v9W1/8Lsxzxf/i/Wcnv/24buZT/8xltO6XcG2U3hMotyrfs/0a3+29bl+vTvjt+ +PhFA1e6/p8ZFtf/a8bs/s/N9znd/915Wxf2p7pfE/B/7aNSV1v/TyYi1ub//F06q//T44r/ k7l6Uu2dYj7fhvuhs/3f7ZbYlfN/YdChLv/XyzSfIv5PTvES/k9em5Txf3JkF/F/4Tp7vP+z 0nUu4f+0KJIy/i90AJP832wbSuH/FP7vTdRKq/B/G1Ee/i+j/5vkTJJqZ9TTNj7L/3X7o379 32OYGP+XoVXP/s9Mo20r9H9GurW1+T/pa1bm//zUm6z+zw09nuz/Wpvf/xn8HyW63P2fPjAj zv9Z8X/tj8L/HV/cWY7/ix/3xv+ltwr/l9CtKOT/3KSE0/1fmEmE//sC/+emSYVqZ5Se/Bcb h8pH4f8io5auFvi/hHcU+L/0qNr8H+v/4f/8b+H/FP5v6w7E/yVG4f8SWoX/S4zC/0U2C/93 r/B/+L+q/V+YXpnR/7kvdr6Q/5MRr5z+79Gqo/2fNmv+L8ycw//h/2al5Pp/g0z8yOj/1Af4 P5Pb/62v/4f/S/J/7dDj/77F//kFNbP6v9tfjf+LbNVp/s9U6f/U6ev/daP7a/F/i58V/g// 9xq10f/J8YD/W7iJzLahFP5P4f/eRK20Cv+3EeXh/zL6v0G6MYM8BO+LetrGI6ou/3frs5/u /8IiFTX5v/b2Gfn1/7SMFu/1f+a3Uh/h/ypd/08OPfzfwiTVJ/93/vp/rdWs/0f5gHL3f+bA jDj/N4j/638U/u/44s5y/F/8uDf+L71V+L+EbsWV/J8OL2jwf28Pi9P9n/vtUO2M0pNctKbH EDv+LzJq6Wrx4v+Mn7uE/9vyjgL/lx6F/8P/vRwW1fk/N7MN/xcbhf/L/HyA/0vcgaX8n+3x f5mi8H/4v+c9iP9Lj7qM/wvvTfF/u/1fmEucz/+1ds3/hYnzvd/STv83ty+zVh3u//S04v9k 4zn9nwMpZ6//h//D/xVZ/28czvd/Q3b/Z/F/C1f2r/J/Q9/m9n/3Vr1+WAX9X3AA+D/8H/4P //foMRXyf+Zi/k8OvSL+Tw6bIv5Prq1F/J80Af+H/8P/4f8WolZahf/biPLwfxn9n5Xb79Al RD1tQ1W6/h/+L/1t45L/G4bbDnb+z+6OcvCv+a1mUaf6v1Yq/N/bJ5HT/Z/O7v8+YP2/vsf/ UT6g3P1fe2BGlP+zjfi/5kfh/44v7izH/8WPe+P/0luF/0voVhTyf2b8AP8XHq3wf1/g/9zI c6h2RulJBs0n87sD8X+RUUtXC/xfwjsK/F96VG3+b2jxf6lR9fk/N4kO/xcbhf/L/HyA/0vc gfi/xCj830vUl/m/fpLvjsX/4f9Wo/B/+L/wr/i/xPX/vtn/6dX1/2RMFf/35mB3Q+34v6jP Cv+H/1vcgR/m/6zOvv6f6fB/X+P/mvFa/s/fPfB/r0M/p/k/bc72f+3obgCs/7f4WeH/8H+v URv9n1zZ8X8LN5HZNpTC/yn835uolVbh/zaiPPxfTv8nz8qDXzltr/+bb8MPJlTo/+6q8VT/ Nz6q3f7PzCs3mHCu/+vd+27n/3qzN0qPjeshhEp9xPp/ZpRZvpX5P98E/N/SJNW5/2ttg/+L jML/VVru/q87MCPO/2nxf+ZH4f+OL+4sx//Fj3vj/9Jbhf9L6FaU8n/mA/xfmEmE//t8/ze5 Hm2odkbpyZ9uofJR+L/IqKWrxYL/kwkkGf1fa/F/GVqF//sG/9cP+L/UKPzfaxb+D/+H/1uN qsz/TQb/lykK/5fZ//mbI/4vLgr/h//7HVK9lv+Ts6iE/wv/nub/wvxU/N+x/k86Ovi/Nwc7 /i/R/2ndFfN/Fv/3/f7Pn0lZ/Z9DeQv+b+qy+797q14/LPwf/u9c/+f7gdX5P7/drP5PTRda /6817jEH/7f4WW30f/IwVcL/yTyIMv5PrpFF/J8cA/i/b/B/46Pa7f/GeYX/U/i/N1ErrcL/ bUR5+L+c/q/z11abcg182obrMuH/FqIy+D89fwjO4v9mKO8k/zeZ230pr/+7nZ2n+7/ArvB/ G55E8H85WoX/o3xkufu//sCMOP9nxP91Pwr/d3xxZzn+L37cG/+X3ir8X0K3opD/0/YD/J8O L2jwf28Pi9P9n9tEqHZG6UmeoafHXBX8X2TU0tViwf+532b9vy3vKPB/6VG1+b+2wf+lRlXo /xr8H/5vfQfi/xKj8H8JrcL/JUbh/yKbhf+7V/g//F/N/k9NOfxfeCP6xv+FObDfuf7f0Bbz f333Af5PmoD/w//NygHr/00j/i8y6uka6FDesv8z4v/kyrjX/8meG8LLnAv5v64ZdG7/5z4r /F/MDlT4P1XE/8lE5W/1fyP+D/+nfvcr/g//t/7Qoz7B/8nG8X8LNxH8n6/wf1ujVlqF/9uI 8vB/Wf2fvzlZ/35nt/+bbeMh5fB/+L+FVj37v67Rpq1w/b9K/d+A/9vi/9w4+9n+zw8E4v8o Z5e7/7MHZsT5v1b8n/1R+L/jizvL8X/x4974v/RW4f8SuhWl/F/zAf4vvKDF/32B/3PdzFDt jNKTn2oVKh+F/4uMWrpa4P8S3lHg/9Kj8H/4v5fDoj7/x/p/+D/8358o/B/+b+HH8H/4v6Vm 4f/wfws/hv/7aP83ylnkX2qm+r9Qrfo/+VPwf28OwXLr/3mntOj/ZDI2/m/hYMf/fan/U2v+ r8vu/1r838KV/Zv8Xzva7P7PXW7P93+yg0v4PzO/iRzq//w0MfzfYtRG/+d7ZUX8nyNRef1f Z/B/ca3a5v8mfynK6v/8wb7o/4K5qc3/yRWpNv8nlwb8317/J332Iv5Pxqzxfwr/N2/UcVH4 P/zfStRTo+aPzLX4P61lcoIxZnfU8zZqXf/vvqIX/i+r/2uH4baDnf/rur1RDv6Nv5X6DP+n 6/R//paL/1uYpDr3f213uv+z/rVBVv/novB/lMhy93/DgRlx/q/z/q9vfhT+7/jiznL8X/y4 N/4vvVX4v4RuRSH/132C/7vPVcH/vT0sTvd/bqQ7VDuj9OR7y6HyUfi/yKilq8WC//MTinL6 v9bi/zK0Cv+H//vbKvxfYhT+Lzbq7x7E/2XYgfi/xKjK/N9g8X+ZovB/+L/nPYj/S4/C/20/ 2PF/Cv/37rX65fyfbBf/92//5+Yl4P+iPqtn/6dvV4vT1//7Zv/X2mL+z1HD6/g/9w36mf2f HvF/x/i/3nX9svo/fw3E/0W1Cv+X1f9pcy3/N86qvf6vnVf4P/yfUvd/U/g/dbT/mx7Vbv83 zSv8n8L/vYlaaRX+byPKw//l839qkKHH0d8Od0Y9baNW//cJ6/+Fp52q/F873HrQzv9J4/b6 P/tb+Sd4/F+WVuH/9vk/N6W9Pv+nWf+PEl/u/m88MCPO//Xi/8yPwv8dX9xZjv+LH/fG/6W3 Cv+X0K24kv8Lj1b4v4/3f1Pjuoih2hmlJ/8yPVQ+Cv8XGbV0tVjwf65VrP+35R0F/i89qjb/ 1w/4v9Qo/N9rFv4P/4f/W42qzP91E/4vUxT+D//3vAfxf+lR+L/tB/vF/Z98Mhn9n+nW/F+4 /CX5v/BhFfd/nS3m/7Qu5v/Umv/r7xM/5Kfxf/g/dcj6f6Nh/b/IqKj1/3QrB3uS/7PyhqX5 AP/XZ/d/ZsX/jW1u/9ey/t9R/s/NT2X9v8Wojf7Ptepb/Z+QqP/Un2IH41qV1/91V/J/nXNr Wf3f7Sfxf6mf1en+L5yv+D/83zwqnOKN3Eh3XQOftqEU/k/h/95ErbQK/7cR5eH/cvo/uV8N vp++1//NtyEDqvi/uOer5fPqCv6vM7dOpvN/2uyNcvCv+63cf5jwf1lahf/D/z0qN6CK/6NE lrv/mw7MiPN/Vvxf96Pwf8cXd5bj/+LHvfF/6a3C/yV0Kwr5Pzcp4XT/18j7RfzfF/g/93Yn VDuj9ORPylD5KPxfZNTS1QL/l/COAv+XHlWb/2P9P/yf/61n/9fg//B/6zsQ/5cYVZn/Y/0/ /N8/ovB/KR8W/i896jL+T0Zv8X9bPMWy/5M9WML/hRmI3+n/Cq7/147nr/8n0Av/t3Cw4/9y rv/XTOev/9eG8dB8/k/3Nfo/u+b/glOqyv/1Tfb1/7pPWP8vzKvD//3b//lr4JX8n7/v1ub/ RvdZ5fV/TTH/d+tI1+f/3F34Sv5P+khF/F9oTgn/J80p4v906AT73u3B/s8+qoP9nzyvVub/ 1CSHW4r/e9qG+4Pwf0rh//4VtdIq/N9GlIf/y+j/rFzSB5nVuS/qaRus/6e+yP+Z4Xz/d+tR 3Tpo4dDb6//Mb+UGkez5/k9Ohtr8n39Rgf9bmqSK/8P/URZK8H/2SGsX5/8G7/+6/kfh/44v 7izH/8WPe+P/0luF/0voVlzJ/+kwVwX/9/awON3/9f1vtTNKT34+TKh8FP4vMmrpaoH/S3hH gf9Lj6rN/7H+H/7P/9aT/3OT6PB/sVH4v8zPB/i/xB1YyP/dLj34v0xR+D/83/MexP+lR+H/ th/sl/Z/solQ7fV/94X9QmeoWVv/7z6dxW9pp/+z86qg/yu4/h/+D//n/yj837f6P7u2/t+Y 3f+NK/5v8g7A9DoFD8mHoO5zcar0f92w6P+Mzr7+H/7vKP/Xuce3rP7PzXm8kP/TfqW8b/V/ tkr/d/76f+PkHnOy+j93DazQ/9lV/ydXpCL+Tw6bNP9n/uzAFf8nTSji/6QjUcT/hetsAf83 4f/wf/i/LFErrcL/bUR5+L+M/m/sx0e1M+ppG7X6P9vg/7K06o//a4ZRe/8nw1l7/Z/+rRT+ D/8X5f/8t1vk9X9jU6H/Mx3+jxJd7v5PH5gR5f9u/9n7v+ZH4f+OL+4sx//Fj3vj/9Jbhf9L 6FYU8n9m/AD/14cXNAX8nwzj4/+2zDBf9H9j/1vtjNKT/5rhUPko/F9k1NLV4sX/yWNwVv/n 3ifh/5Jbhf/7Bv/X9vi/1Kiz/d/Q4P/wf/g//N/fKPxfYhT+7yUK/4f/w/8tR+H/UptVof/r xhr9Xz8U839m+AD/J+MUdfk/O+b2f0Ff4f92+7/WFvN/qkr/t7r+n9+BerrfInfd8e++prtH Vej/ltf/053pq/R/o3xIJfxfaEIB/+d1Q971/2534Uv5v0Yq/N/foZ/r+j97u8x2udf/U6v+ r5s1rhr/J19OXMT/SVQR/ye93yL+b/6AerD/CydUmv+T6+w7/ydd5yL+L3xIRfxf6NrLjXSn /5ttQ6lnlIf/w/+9Rq20Cv+3EeXh//L5P639SxMtT/X7op63Uav/G0yN/k/rk/3f7RbVu/X/ 2snsjtLD5DojoVIf4v98hwD/9+5J5AP8n596k9f/mdP93zj2uf3f7Sfxf5TYcvd/5sCMOP+n xf+ZH4X/O764sxz/Fz/ujf9LbxX+L6FbUcr/mQ/wf428X8T/fb7/026aVKh2RunJD3iHykfh /yKjlq4Wr/5PywSSjP5PG/xfhlbh//B/f1uF/0uMwv/FRv3dg/i/DDsQ/5cYVZf/U92E/8sU hf/D/z3vQfxfetRV/F+QPPi/LZ7i9PX/pFX4v/eHYCn/p67l/0xu/9c2+D/W/1Pyv8yqD1j/ r6T/Cy/mSvi/YVK5/d/i+n966nRu/3dv1euHhf9L839+mlhe/+eugfi/qFad5v/Uiv8b/WeJ /9vUY1ryf737a6vzf4NvTlb/Z7qP8X9j6KMl+b/f8wr/97oD8X/4vyxR+D/831rUSqvwf/94 7P4A/2cafxIZ//Sx0/89bUMGVOvzf63F/2Vp1R//N9p+dP7Pjruj9DC5fkColPpd1RD/h/9b aNWL/9P4P/wf5aBy93/tgRlx/s+I/+t+FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FIf+n7Qf4Pzmv ivg/OxwQdSX/1/W/1c4oPfk3baHyUfi/yKilq0UJ/9da/F+GVuH/8H9/W4X/S4zC/8VG/d2D +L8MOxD/lxiF/0toFf4vMepS/k9uuvi/qCj8H/7vd0j1Uv5P399EKrXb/7VzwbXu/+4/luT/ gn0p7v/syPp/kVEvR2CF/s/i/75m/T/8X5r/a22V/q/vlvyfGafs6/85LXy6/wtT2+vyf/04 5fZ/F1v/zw+E4v8Whn4u7f/cZaKU/2tmjfs2/6dW1/+TznoJ/xem7Jfwf+FwK+H/5g+oR/u/ cJ1N8n9hjO+N/5PjoYj/C9M6ivg/ac4kN9Kd/m+2DaXwfwr/9yZqpVX4v40oD/+Xz/+pQXpl g+33Rz1t4xF1pv+Tb5XM6f9Mh//L0qpn/2fG7vZZ6U667rv9n/uEQzWLOtH/mUkGXGvzf/58 qcz/dX1u/9fa5nT/N0y5/Z8bu8X/USLL3f91B2bE+b9W/J/9Ufi/44s7y/F/8ePe+L/0VuH/ EroVpfxf8wH+z4S5Kvi/t4fF6f7PDbmGameUnjr7qHwU/i8yaulqseD//ISinP7PfXUl/i+5 Vfg//N/fVuH/EqNK+b8R/4f/W9+B+L/EKPxfQqvwf4lR+L/IZuH/7hX+77P9Xxg0w//t9n8y wbGE/wuTCb5z/b9OX8r/dXIW4f/e+D/W//ue9f/UB/g/k9v/BYGqXsoB/q9Z83+h1VX5v8kd epn9n/0A/xdG/evyf/7ClNX/uZHiK/k/GVPF/70O/VzY/02du/Lj/xY/K/wf/u816vP8nxxu Zfxf+6h2+792XuH/FP7vTdRKq/B/G1Ee/i+f/9NNJw9vCdfA5234fmCF/o/1/9LfNi76v94O 3v+FgcCd/s/8Vref0Rb/l6VV+L99/u/89f+09jNHQrU7Ktwspt+BH/wfJbLc/V9/YEac/+u8 /+ubH4X/O764sxz/Fz/ujf9LbxX+L6FbUcj/dZ+w/t/9BU0J/9ceEHUh/2fa/rfaGaUnP2Eo VD4K/xcZtXS1WPB/vcL/LUfh/+4V/m/N/1mD/0uNOtv/2S63/3MTs/B/sVH4v8zPB/i/xB2I /0uMwv+9RH2b/5OXMfi/qCj833f6v1GOAfzfFk+x6P+aMOzoNrLb/wX+ETpDq/5PeoLf6f/q XP9P4f+S/J+bl4D/i/qszvN/n7D+31f7v9X1/1R9/q/TOrv/U5/g/wb5Uyrzf+5xKu/6f7fD Av8X1yr8X1b/5z6rk/1f7/7aQv4vQI4C/m/ssvs/u+b/wuprRfyf/HsR/yfX1iL+L4xY+N7t wf4vRKX4v/t34bzxf3JlL+L/eploVsT/yU0mzf/NtqEU/k/h/95ErbQK/7cR5eH/8vk/Ncrd fdIJUU/bcAMT5/s/6dPn9H931Yj/y+r/usba1vm/MJy10//5N2xSqQ/xfzJgUZv/889G+L+F Sapz/3f++n9H+L/bT+L/KLHl7v/sgRlx/q8X/2d+FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FKf/3 Cev/6fDKGP/39rA43f+5bmaodkbpyf9yqHwU/i8yaulqseD//LzDnP6vtfi/DK3C/32D/2P9 P/yf/y38n8L/bd2B+L/EKPxfQqvwf4lR+L/IZuH/7hX+D/9Xt/8Le9Bt5GD/13eParf/G+dV Qf+nuxr93/r6f3JY4P/+7f9ai//D/yn5X2bVqv/zYKWbwvzifffG+ywmI3/1mv/z10DTdGGq yT7/Z2fVP/xfGE6Q/VyF/9ND/vX/3GeF/4vZgeo8/3e7C1/I/zXyoIj/ex36wf/h/97OusX/ 1eP//DuhRP/XPr4HGf8XtQPxf1Lh/7ZGrbQK/7cR5eH/8vk/rXv9qHau//e0jUdUXf5vwP8d 4f+07W79QN21rU3xf26MKVSzKPwf/m+hVS/+z/oFRfr7S4Y9Uc+TVM9f/8+9SneTAnP6vw7/ R4kvd/83HJgR5/+s+L/uR+H/ji/uLMf/xY974//SW4X/S+hWFPJ/bXe+/9MymlnG/+kDoq7k /9xId6h2RunJvxoKlY/C/0VGLV0t8H8J7yjwf+lRtfm/ZsT/pUbh/16z8H/4P/zfahT+L6FV +L/EqCv5PyugB/8XFYX/+1L/J6O3+L8tnuJf/s+3PtH/tb/2pUL/1+li/q/vSvk/9wW0y/5P vlMN/7dwsOP/cvq/1hbzf2rN/zVhPDSf/2uL+b/19f+y+z83XaVC/+eiXv2fsfn9371Vrx9W Qf9n5XKL/3vj/2yP/4ts1ef5P995+1b/p83J/m9odEn/N8wa92X+z3WkV/yfPEwV8X9hJnro ox3q/+TSUML/zReoP9j/NXISFfB/vVwfyvg/eTwo4v+kOWn+b7YNpfB/Cv/3JmqlVfi/jSgP /5fR/zWTv3to/9i90/89beMh5eryf/cVvfB/Wf2fsc3thq+7Njxf7fN/ozsbQ6VkRPp0/ydP fPi/L/B/TW7/d/76f0f4P43/o8SXu/8bD8yI83+D+D/7o/B/xxd3luP/4se98X/prTrV/4XO E/7v3/7PjOf7P9OEFzT4v7eHxdn+z79MD9XOKD3Jb0397w483//NX1LX4/+Myuz/3FdX4v+S W4X/w//9bRX+LzEK/xcb9XcP4v8y7ED8X2JUZf5vsPi/TFH4P/zf8x7E/6VH4f+2H+wX93/y yZTwf52MsX+n/7vY+n+DnEX4P/zfrFS6/l9+/6fKrf9nPmH9P7lMfKf/c5fbBf83NYP4v4Sv RZysvy+FSmYx4f/iDouz/J/W1/J//u7xpf7Prvk//xQcqt3+b5xVLgr/FxP11//ZNf8nrarN //X+gyni/8IRWsL/hQffyvyfHh7Vwev/SYeghP8zuqD/ax/Vbv/Xziv8n8L/vYlaaRX+byPK w//l83+3c8lfuAb/JLIz6mkbvh9Yof8bO/xfllb98X9jL/4vfEg7/Z97ng6V70Kc7v8C/KvN //mhaPzfu0mqn7D+3+iGifOu/zfi/yjR5e7/pgMzYvxf5/537c6MH4X/O764sxz/Fz/ujf9L bxX+L6FbUcr/mfP9n5Zh/BL+rzX4vzT/50ahQ7UzSk/+5UOofBT+LzJq6WqB/0t4R4H/S4+q zf9Zg/9LjcL/vWbh//B/+L/VKPxfQqvwf4lR+L/IZuH/7hX+77P9n0zPw/9t8RSn+z/5d/wf /g//h/8r7v9Ujf6v4Pp/lfq/US/7v6HN7f/urXr9sAr6vzDqX5f/611GXv/nTuEL+b/RT0T8 Uv+nqvR/7rM62/+5y0Sh9f++2f/5IxD/F9Uq/B/+b+km0s4r/J/C/72JWmkV/m8jysP/5fR/ cpOxQ8I18GkbbmCiRv93X9UQ/5fV/7VN0+nbTjbTUz8w1v+5Qy9Uvg+G/8vSKvzfPv/3Cev/ HeD/WP+PEl+C/xuOtHZx/k97/9e2Pwr/d3xxZzn+L37cG/+X3ir8X0K3opD/0/Z8/2ekR5sT 5Vn83zH+r9P9b7UzSk9+j4fKR+H/IqOWrhb4v4R3FPi/9Cj8H/7v5bCozv+5gRj8X2wU/i/z 8wH+L3EHlvJ/3YT/yxSF/8vs/2RWM/4vKgr/953+L0ge/N8WT3G6/5PLyXf6PztW6P/csiX4 v7hW4f+y+r/Wnr/+nw3jocX839ClvIF5msX0Gev/hceiMHX7u/xf3y36v7HH/yX6v3DH+Er/ 5+Y8Xsj/af+H1ub/Bj9ek9X/me5C6//d7h4d/m95Bz7PurX4v+/3f6aZRe18QA2vsLvfVl3K /81mN+/2f/MZ0gr/p/B/b6JWWoX/24jy8H8Z/d8o14fJP53vjHraRq3+7yPW/5OniIz+T/Wn r/9nbl1O3ZlRhrN2+j/XRw2VkiGS0/2ffFb4vyv6vw9Y/6/zw8RZ/Z+Lwv9RIsvd/+kDM+L8 nxH/1/8o/N/xxZ3l+L/4cW/8X3qrTvV/Yc42/u+N/2vO9396PALlLfo/Mw0HRF3J/7lpUqHa GaUn/yYuVD7qfP8XPsvK/J8fecb/bXhHgf9Lj6rN/zUj/i81Cv/3moX/w//h/1ajKvN/rP+H //tH1Kn+z/jpQDn9nxnwf6lR+L/EqBX/J8cA/m+Lp1jyf/frkH8Bvdv/9fNK2xX/1+tHtdv/ zbvts1Yd7v86XaH/U+vr/8lhgf/D/83Kd6//9zn+rzcp90bTzKp1/+fnmJjf+fP7phbJuSkf dNtcyP+1t1tibv932xT+L2oHqq3+zx3ledf/ux0W+L+4VuH/avN//jEnq/9zXzmB/0v8rPB/ Kqp3i//D/7kfxf8ttQr/h//D/2Xyf1YWLh3ahKinbbhebo3+7yPW/6vP/7VNa3vv/5rdUXoY Xc8uVL4Lgf/L0qpr+L/eZPd/4+n+r+2z+z/XKvwfJbLc/Z85MCPO/7Xi/4Yfhf87vrizHP8X P+6N/0tvFf4voVtRyP91H7D+n5ZHWPzfhsPidP/nfjtUO6P05Hd7qHwU/i8yaulqgf9LeEeB /0uPqs3/tT3+LzUK//eahf/D/+H/VqPq8n+3Sw/+L1MU/i+z/wtX2Iz+rx3xf6lR+L/EKPxf bBT+j/X/3k2FXfV/o5xY+D/836x89/p/6lr+r83t/7qmu47/uz021un/BvmQ6vJ/rWtVVv/n 5jzi/+JadZr/s1X6v1vUyf6vse5mmNX/uWvgsv+zw6xx3+b/1Kr/k2k+tfk/uTkV8X/hEd/3 bg/2f+2j2u3/9Lxa9X8SVcL/BVhTxv9Jq9P832wbSuH/FP7vTdRKq/B/G1Ee/i+j/xvH6VHt Xf9vvo1HVF3+b7L4vyyt+rP+n7WtX/9vMLuj9DC67neoFP7vOP/nH0Fq839Vrv93gP9zbw/w f5TIcvd/7YEZcf6v8/6v0z8K/3d8cWc5/i9+3Bv/l96qc/1fuPPi/14erT7N/xl5IYH/23BY nO7/3MhzqHZG6cnv/VD5qPP9XzjFK/N/jcrs/1qL/8vQKvzfN/g/a/B/qVH4v9cs/B/+D/+3 GlWX/2P9P/wf/u/vn4T/w/8t/Nix/k+2i//b4inwf1HHxbX9n3ww+L9/+7+gr/B/+L/6/V87 jjX6P3e5XfB/0zTk9n9uAUX8X8wOVBv9n7F9Zv/nT+Er+b/xUX2d/1NV+r/z1/+bRvfbt2pI 8X+2f1Q+atn/hQm/tfk/6b8U8X+yA0v4v3C+FvF/4RHf926P9X86dJVatf8B9fP8n3Teivi/ cTa7ee81cL4NpfB/Cv/3JmqlVfi/jSgP/5fP/2l5qrw984y7o5634QYmzvd/wtty+r97q/B/ ef3fON6er3R3eyK2e6P0MPpuglTqI/yfGcOTKf7v7ZNIhf7v/PX/Rj9zJKv/c1H4P0pkufu/ 7sCMOP/Xi/9rfxT+7/jiznL8X/y4N/4vvVX4v4RuRSn/13yA/5MBUPzfhsPibP/nZyOEameU noQrTPZ3IAb/Fxm1dLUo4f+6Ef+XoVX4v2/wf6z/h//zv4X/U/i/rTsQ/5cYhf9LaBX+LzEK /xfZLPzfvcL/fbT/C4cb/m+Lp1j0f2LKivi/TnqK+L9v8H9BZ+H/Xg52/F9O/9dM+L/IqLP8 X9dV6f+W1/9rm3Zi/b9v8X+de3zD/y1GbfN/vkdVnf/z/57V/2lzofX/ivo/aRX+b8Nnhf9T Ub1b/F+h9f8y+L+XGdL4P4X/+1fUSqvwfxtRHv4vo/9r/P1MN/3+9f+et1Gr/7PN+f5P7oNZ /Z852/9N3W0H6870T/3AWP/n+iehUvg//F+U/2s7/N8W/6dH/B8lutz9X39gRpz/s+L/+h+F /zu+uLMc/xc/7o3/S2/Vuf4vvM7F/708Ws39X9t9gP9rs/s/u+b/5I0m/m/LDPNF/+e6maHa GaUnP5IdKh+F/4uMWrpavPq/RuY/ZPR/t/MK/5feKvwf/u9vq/B/iVH4v9iov3sQ/5dhB+L/ EqMq83/dhP/LFIX/w/8970H8X3rURfyfbsLMaPzfbv8n/+5J1G7/186rdf8XHg2S/F8whvi/ LP5Prfm/Af+H/8P/RRzs9fu/1lzI/xk9Zfd/t5883/8FMlWX/+vb3Ov/3c6bS/k/vxRGEf9n 3Wv8vP7PVun/Tl//b2ysuwrdKpPi/2SOazO883921rh6/J9MZSri/0Jz5vO+j/J/st0S/k8e 9Yr4P5ntXsL/9fIIUsT/yaFXxv+FG0CS/5ttQyn8n8L/vYlaaRX+byPKw//l839q8APDt05S uz/qaRvuJ2v0f/dWVeb/mrP9nx8BdErJdnuj9DC6flaoFP7vOP8nL0Pwf28mqba2qdH/Gfwf Jbrc/Z89MCPO/w3i/4Yfhf87vrizHP8XP+6N/0tvFf4voVtRyP+Z8Xz/p6cwVyUrysP/JUYt +7+p/612RunJfwih8lH4v8iopatFCf/H+n/4v9Wo2vxfM+L/UqPq83+mw//h/9Z3IP4vMaoy /8f6f/i/f0Th/1I+LPxfetRF/J+awqAZ/m+v/5OJiDn93yPqj//r9aP6uvX/On0p/2flg8H/ /dv/tQ3+72v8n13zf/LqpYD/u11fO1/dhcc+/9fPK7Xo/4zWbig+VHvv+HZsZ5UK8uAa/q+z bZXr//UShf974/+GFv8X2aqz/J+bR1eh/3Of1dn+zz3Pj83QhD9sn/+zj8rfhfF/iZ8V/k9F 9W4/z//JoYf/W7+J4P/wf/i/o6Pwf5n9n5UXO1LtjHraRq3r/91bhf/L6//a6fbfdWfCMPE+ /ze4YbdQKfzfcf7Pd84q839TY3L7v9kNH/+H/7t2ufu/4cCMKP+nG/F/5kfh/44v7izH/8WP e+P/0lt1rv87Yipxhf7PrPm/sJx3ifX/THhBU8D/hW+nxf/t9H9WuuvhSx73+r/+Ufko/F9k 1NLVYsH/+WMup/+7XS3wf+mtwv/l938yCzGj/3MjWfi/xKj6/J/7ein8X2wU/i/z8wH+L3EH sv5fYhT+7yXqy/xfP2b3f3rC/6VG4f8So/B/sVGb/J+W26Hswb3+T7qR98qe7//aAClyrv9n VvxfmHmd0f9pXcz/2TX/J9OW8X8L4wlz/8f6f6n+r7UX8n9qMnLbCJfKfffGp2ugM2XL6//5 dhhzX3pu1x0/rK8lh29nqvR/jlu/+L9bz0LrOv2fnGb4vzf+7/bUcyX/54eUvtT/qdX1//zB ntX/KXsp/9dn93/tqv/rZ42rx//Jw1QR/yf/jv/b7f9CV6lV+x9QN/o/eRYu4v/Cm88i/i90 AJP832wbSuH/FP7vTdRKq/B/G1Ee/i+j/5sGwWT+6WNn1NM23KWwRv93X9EL/5fT/92OHdNM 7uvqxm53lB4GN3IeKoX/w//F+L/OjLn9nx85O9f/tYP7rLL6PzftDP9HiSx3/zcemBHn/7T4 v+5H4f+OL+4sx//Fj3vj/9Jbhf9L6FYU8n+3XuX5/k+mKOP/NhwWp/u/vv+tdkbpyc8VDZWP upT/m78PzxVVyv9pg//L0Cr83xf4P/etzvi/xKj6/J+b2Yb/i43C/2V+PsD/Je5A/F9iFP7v JQr/5275+L+0KPxfYtSy/xvD5ED83+f4v8FU6P/8FIhF/6fnQxe1+D8dXovg//7t/1qL//ua 9f/U+f5PUF5rdcobmNkv/wpU9VJK+r/glCryf7ppprD+X8IknMn6O1Co/Gqh+L+YHahO83+3 o/ha/s/vsi/1f6qg/2uK+T9tTvZ/Qz+4TWT1f36ofdH/hdeRUu31f3+f5Rb939Tk9n9uJYdl /2f9B1PE/wVMVsL/hbt7Cf9nmkdVz/p/lfq/8VHt9n/jvML/Kfzfm6iVVuH/NqI8/F9G/zfK KMLkx4d2Rj1tQwZU8X9xz1fL59Vf/xeediryf7ppzDi4jtLw1A+M9H+9u/2GSn2E/2sbGbDA /32+/9M2u/8zNfq/jvX/KPHl7v+mAzPi/J8R/2d/FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FqfX/ xjX/18pgdAn/14UXNCX8nz0g6jL+T1nr3u6YbhwT/J/tp0flp8Xg/xKjVvzfoPB/y1H4v3uF /1vzfx3r/0WfVy+HRXX+j/X/9rQK/5f5+QD/l7gDC/m/26UH/5cpCv+H/3veg/i/9KjL+D/Z Lv5vi6dY9H+Br5Xwf10O/xeGLv/t/4wsIlBk/b/8/s+YD/B/Mk6B/8P/zUp+/6dGc/76f312 /9fi/xau7Dn8n5Xvvzvc/2k9Dbn9n5/FdLb/G+VDwv/92/+ZprmU/5MD4Uv9X8n1/8r5P9PV 6P/GGv2ffxhe8n9hefAi/u9pB+L/Ptn/WV2j/3vq2u+8Bv55PMD/Kfzfm6iVVuH/NqI8/F9G /zfIHMthTDDQT9vA/yn833b/p2+P28PtRjWNcujt83+d+2LFUCn8H/4vyv81XY3r/1k/KTCr /xvxf5ToEvzfeKS1i/N/rfd/7fCj8H/HF3eW4//ix73xf+mtwv8ldCuu5P9kWgz+b8Nhcbb/ 8yvFZ/V/Lgr/lxhVyv+ZDv+XoVX4v2/wf6z/h//zv8X6fwr/t3UH4v8So+ryf7dbOf4vUxT+ L6//s428O8b/4f9Wo/B/+L/wr/n9n23wf5FRZ/k/t2wJ/i+uVfi/b13/r07/Nxbzf629lP/T k/i/dv8ROFl/cQuVmxl1vv97moG01/+9zrqtzf/dPn78X2Sr8H9Z/V+d6//V6f8s/g//5z8j /B/+b2sU/g//txa10ir837snkXP9n5Vbo50SroFP23C93Br9371V+L+8/q8Zbtdy3U6m2x2l h871kEOl8H/4vxj/dzv2avR/vWsH/o9ydrn7P31gRpz/62T9P/2j8H/HF3eW4//ix73xf+mt wv8ldCtK+T+z6v/k8bqE/5OpN2X8X39A1IX83+R+O6v/cy+6L+X/7AFRK/7PTyjC/214R4H/ S4+qzf9Zg/9LjarP/7UN/g//t74D8X+JUXX5P9b/w//h//7+Sfg//N/Cj+H/Ptv/tY89uNv/ hTmPb/xf8BZp/i+MH9Xs/7qp2Pp/asX/3U8s/B/+b1a+2v9pU6X/e7P+n5bvfEzzf3a6Ry37 v3BVrsr/TWMr/s/sv9xOcsUJlcxiwv/FHRbb/J/r+uX1f814Kf/n3yt9qf/Tpkr/d7X1/+QI rcz/6XL+b2hnO/BY/ye3ziL+7/4FNb53e7D/C9fZVu1/QN3m/3p5s1nG/8mknwL+T01yuKX4 v6dtKIX/U/i/N1ErrcL/bUR5+L+c/k/uida/Kdzr/+bbcF2mGv3frXd7uv8Li1S0JiFqbOfV +f5vckMkuh0neaba5//8ZNpQqc/wf7Ld2vyff1LB/y08dn+e/3Ov/PB/lLPL3f+ZAzPi/F8v /q/9Ufi/44s7y/F/8ePe+L/0VuH/EroVhfyftmv+T77grIj/O2RRPvxfYtSy/+sHldf/uRdy l/J/7QFRK/7Pjzzj/za8o8D/pUfV5v/GCf+XGlWh/7P4P/zf+g7E/yVG4f8SWoX/S4zC/0U2 C/93r/B/n+3/5HqM/9viKc72f530FL9z/b9xqnD9P/dZ4f/iWoX/+1L/p+pc/w//d4z/G212 /+euFvi/mB2oTvN/twe0a/m/1lf4P/zfzP9Z99t5/Z/B/+H//I828wr/h/972YZS+D+F/3sT tdIq/N9GlIf/y+j/BrncDuFhYlfU0zZUpev/DQb/l6VVf/zf2IzuRjUO2uyN0kPrRo1CpfB/ +L8o/zfa7P7P4P/wfxRf7v6vPTAjzv9Z8X/9j8L/HV/cWY7/ix/3xv+ltwr/l9CtKOX/mjX/ FwajS/i/8GiF//sC/+dmS5luNEn+r39UPgr/lxi16P+MHybL6v/c+yT8X3Kr8H9f4P/cSBb+ LzGqPv/nJyXg/yKj8H+Znw/wf4k7EP+XGIX/e4n6Ov/nD1H8X1QU/u9L/Z9Mz8P/bfEUi/6v CXvQbWS3/2vmFf7va/yfmzi/7P/kt/F/C+MJ+L+c/q+15/s/mWeX0//pvpj/G8v5v3HN/4VW 1+T/mmEYxP81+4/Ayfq/IFSs/7fjcnua/7sdFhfyf80kw434v8/xf9rU6P9W1/8Low11+T8V +i8l/F+4WRfxf9KEIv5v9oB6tP9rH9XB/k8eUIv4PxknK+H/nrr2O6+Bz48HCv+n8H9volZa hf/biPLwf/n83+8XaTTt7qjnbTyi6vJ/I+v/HeH/mtvFXDv/15rdUXrwnZFQqc/wf014Mq3M //lDD//3ZpJqnev/uXEL/B8lstz9X3dgRpz/G8T/DT8K/3d8cWc5/i9+3Bv/l94q/F9Ct+J8 /yfHQwn/JzMF8H8bDovz/Z9W+L9tUSv+7wgksrz+n7/44f+2vKPA/6VH4f/wfy+HBf7vJQv/ h//D/61Gner//PMB/m9LFP7vJQr/h//D/y1Hne//wvxf/B/+b1aK+r8wq0Wag//D/z0+Hfzf uwm+H+H/dOBt+L+/UZf1f7eDu528/2u7JP/XPir8347LLf4P/7dwCuP/8H9bnuUK+T9/BOL/ 4roxzbzC/+H/XrahFP5P4f/eRK20Cv+3EeXh/zL6v8HfXUO10/89beMRdab/Cz3oNP8XngOl nzdZ/F+WVj35PzV09tbJ1G03Jfg/6wVXqBT+D/8X5f+6rkL/1zXuGS6r/3NR+D9KZLn7v/7A jCj/Zxrxf+ZH4f+OL+4sx//Fj3vj/9Jbhf9L6Fac7/9kZk8J/9eEuSr4v7eHxcn+b2jcqYL/ 2xR1uv/zoyf4vy3vKPB/6VHn+r/e98Twf1uiLuT/jIzX4v827EH8X4YdiP9LjDrV//ldhv/b EoX/e4n6Mv8XZhbh/6Ki8H/4v9+n4Sv5vzA/Nc3/hamFb/1feDRI8n+yZ975Pzkuivi/8Oq+ iP/zn2UR/9fLB1OZ/xMbj/9bONg3+j/pLJXwf1aezAv4v1a6TGX8n/vtQv7P7WDTiLpO9H+/ USv+LwwnyH4+1P/5uVtZ/Z9ul/xfP/Xe/7VDwuV26v0fGKoP8X+yg0v4vzBMUcD/ddOA/9t4 Xq34v8F/Yvg//N/c/7k/tDr/NzaT/yAyrv9nOvxfZKsu7f/kGxXwf28eDxT+T+H/3kSttAr/ txHl4f/y+T/T+ntiqPZFPW/jEXWm/wsbH+3+KC33RH0fJTjf/5nwEFyT/+uHth9c72V46gdG +j//dTChUvi/4/yffxKpzP8ZW+P6f53F/1E+odz9nz0wI87/afF/3Y/C/x1f3FmO/4sf98b/ pbcK/5fQrTjf/8njdRH/J+9Y8X9f4P/cUz3+b1PUiv9rMkQ1f6KW/V+P/8P/4f+2n1f4v9+q Fv+n8X/4P/wf/u9v1LL/83Oj8H9bovB/L1Hf5v+EvuD/oqLwf/i/36dh/J/7f1/t/+TKVZv/ uw90plwuruz/ejnm8H8LB/s2/9eFpzi/aw72f367RfyfdFqK+D8/o6OM/2vDe8a6/J8/9Er4 v6a97S3dmWncf7mden9fCtVn+D9pTgn/p0a5tpbwf+4VFv5vMWqj//O7rIT/68dJlfJ//rwr 4//ChOkk/zffhvoE/+dnJRTyf+H9fQH/N4y51//zD8PL/k8epor4v2a2A4/1f6HPUsL/NaET 7Hu3e/1fuKT/7sBl/6dDVKv2P6Bu839hQeAS/i/IhBL+T01yuKX4v6dtKIX/U/i/N1ErrcL/ bUR5+L+M/m/014dQ7fR/T9t4RJ3q/2SOWZr/kxvcB/k/GfhJ9H/hWxfap6jT/N+tU9vr2ydg 7GD2Runej42ESn2E/zNy1avO//lps3X5Pz267dbm/3rtfhv/Rzm73P3fcGBGnP8z4v/sj8L/ HV/cWY7/ix/3xv+ltwr/l9CtWPR/8i2ZOf1fa8c1/yf9iRL+rz0C5S37v04fEHUh/+ePwNsT fpvi/7rpUfmoK/q/rNdA/F9kFP7vXtXi/xo/qJbR/2kz4f9So872f53QuIz+T48j/g//t7oD 8X+JUWf6P+snieX0f7ebHv4vUxT+L7P/k1/H/0VF4f/wf79Pw5fyf2E6m38Bvdv/hbNS/upu zf/d/13mlu/0f38/rGX/JzM5c/o/s+L/wsSPnP7v0ao//q/P7f88iVr0fzKOV5v/k1lMOf1f cyn/J8OOt86S3/xe/6dnlZrMsv+7o7yM/k+t+b8+6Kx8/m/2WT1FjX5ac9tOKffGu4GWq0Gz 5v/8SZTV/zXdmv8LV/Yws+9Q/+dnXuf0fy7q1f91oxH/15j9l9tJhqpCJTT+Qv5vCECpgP9z Q415/Z/W1/J//pgr4f86R6Ky+j+/+hr+L+6weOkxLfq/Af+X5v9G6ZyV8H/h3XsJ/xemSBXx f9KR8JtP9X+//cCz1//D/63uQPyfVPi/rVErrcL/bUR5+L98/q81vo/UyiPIvqjnbbgb+gf4 P3mwyuj/uvF8/ycDP4n+TzI+xv/1vbHuqwwaeTzY5f9uPWPzW7l/1vi/LK26hv/zrtZMXejD 7fR/Zl6Z8/2f//ZA/B/l7HL3f+OBGXH+r/X+r29+FP7v+OLOcvxf/Lg3/i+9Vfi/hG7F6f5P 5kaV8X/SXcf/fYH/G/B/3+P//IQi/N+GdxT4v/So2vyfbvF/qVH1+T/T4f/wf+s7EP+XGFWZ /5ujPPwf/u9PFP4v5cPC/6VHXcX/TWHQDP/3Of7PjBX6v9uzzIr/u2MyaU4O/6c1/i9yB+L/ vtX/uWW2ltf/kwmOJfyfvDb5Uv9nL+X/Wn+PL+D/xqbXzv/p0ew/AqfOX7JD5a8Wp/u/pxlI h/q/+x2jgP/r3XnF+n+LURv9n2tVmfX/3NrCef2fWln/b+y/2f+5z6o6/+fuVxX6P4v/w//5 D2Gb/xMugP9buIng/3yF/9satdIq/N9GlIf/y+f/zNBMvvLdxZ3r/z1tw/1kjf6v/YD1/yr0 f8PYtN3tDj+E56t9/s925rdSrP+H/4vyf9pm938fsP5ffv/nWoX/o0SWu/+bDsyI83+d+D/z o/B/xxd3luP/4se98X/prcL/JXQrSvm/ZtX/yTFXwv91YbS/gP/ruwOiLuT/jOun4/82RZ3v //y8Q/zfhncU+L/0KPwf/u/lsKjO/92uP/g//N/qDsT/JUad6v9G1yfN6v/6Dv+XKQr/l9n/ jf4vxf9FReH/8H+/T8P4P/f/dvs/N1lg2f/NJs7v9n/mz4dVav2/xiz7v3Ds1bb+34D/2+L/ TIf/S/N/t650Kf9nV/xfWJ3tO/2f+2bsf/g/PfVhUnuS//PbWPd/wSmV8H/+KpTV/5lh0f/Z 1q//p9shxf+Z/lHh/3Zcbjeu/+em9GX1f3qcruT/tD9Cv9X/2c/xf93+ed/P23A/VKH/c/er C/k/3ZXzf8N8B+L/Ptr/9X4HVub/ZFAkVDuvgU/bUAr/p/B/b6JWWoX/24jy8H85/Z9/LgjV Xv8334bvB57u/6TLKffEVP8nUfdVDc/0fzLK2ZqUqLv/e446zf+Nrb31ym7dpcHujtJd5zom oVIf4f8C/KvN/8mhV5n/a7oa1//r3G9n9X/uu3Dwf5TIEvzfdKS1i/N/vfd/Xfuj8H/HF3eW 4//ix73xf+mtwv8ldCsK+T+3ms2K/5NJCwX8X9vg/77F/7UG/4f/w/+ltQr/h//72yr8X2IU 6//FRv3dg/i/DDsQ/5cYVZn/U6z/l3wXwf8l70D8X64o/N9X+j8dRm/xf1s8xdn+r+sf1W7/ N7cvs1adtv7fAf7PgRT8X9x9+GU2O+v/RZ3CF1j/T5sa/d+b9f9y+j8zfoD/MzL+fbj/m+wg 6/+Fq+5O/+fHl0Il32KO/4s7LE7yf/4Uxv9FtWqb/7O6VfWu/5fR/5nuZP83mtH99q0KUm6X /5Nni1D5qAr9n8L/4f/8Z4T/w/9tjcL/4f/WolZahf979yRysv+TvsXY7r8GPm9D/a6UV5f/ u6tG/F9W/ze1bozp1l1qu25vlO46N4AeKoX/w//F+L9mMrn9nxvlPNn/jZO7cGX1fy4K/0eJ LHf/pw/MiPN/Vvxf/6Pwf8cXd5bj/+LHvfF/6a3C/yV0Kwr5Pz1+gP8LM3CK+D9zQNSV/J97 cjCdTfiiW21lVpftfs8r/F9k1NLV4tX/WZn/kNH/tRb/l6FV+D/8399W4f8So/B/sVF/9yD+ L8MOxP8lRp3p/wY/Twr/tyUK//cS9WX+z0qfCf8XFYX/+07/FyYH4v+2eIp/+D/lr+ep/u/+ ga/5vzBx/hv9X8n1//ruA/yfHNn4vzf+z+L/0vwf6/99jf9ruyr9n7vcvvg/3dhW/F/KJJyp 839bqGQWE/4v7rDY5P96hxzy+j93YbqS/9NS1eX//FNwVv9ny/k/91md7P8md+7eKrkG7vV/ 9lH5qEv5PxENRfyfnu3Ag/2f7K0i/s88Eg/2fzr0t1u1/wEV/4f/2xyF/8P/rUWttAr/9+5J 5Fz/1/lujul8v2Cn/3vahhuixf8tROH/Fvyfbtqp8ev/afk6iH3+r52G30rh//B/J/u/D1j/ 7wD/x/p/lB3l7v/MgRlR/q9txP/pH4X/O764sxz/Fz/ujf9LbxX+L6FbUcr/mQ/wf4csyof/ S4xa9H+dxv99j/9rFf5vOQr/d69q8X8yfzOn/7MG/5cahf97zcL/4f/wf6tRlfk/M+D/MkXh //L6v17eo+P/oqLwf9/p/8JQLf5vi6dY8n9a9plUu/3f/BHrdnmrcP2/T/B/7a/4UWr/FIhu Xq37Pznc8H9v/B/r/x22/p/f/Tn9X9et+L8ujIcW8H/+AcJMYTL2Tv/Xziq3ptyi/5v8JdGY JgUPBV8jVwM3CWfZ/4UXcxX5PzV2Y+v8XzPp/ZfbqfUWKlRuYif+L2oHqo3+z7q9ldX/uZHi K/k/0cJf6v9slf5Pm7P9X9u4w+JWmdAX3uf/hkflo1b8n/wpBfzf2JXzf/cXDN2jjUf5P/nt Mv5Prq0F/J+SKei1rf8n98Qi/i88e+D/8H9Pn9ZhUfg//N9K1FOj5k8R1fi/xl9GTWOn3VHP 21CVrv83dvi/LK16Xv9vNNPt03GLMTXd3ijdtf4ZTSqF/zvO//l+IP5v4bH72f+Np/u/bvIv uHUb1rHf6f/6WeVahf+jRJa7/2sPzIjzf1r8X/uj8H/HF3eW4//ix73xf+mtwv8ldCsK+T9l P8D/WTurDvZ/+oCoK/k/1800txv5/iht/evQUPko/F9k1NLVYsH/GYX/W47C/90r/N+a/2t7 /F9qVH3+z62YjP+LjcL/ZX4+wP8l7kD8X2IU/u8lCv+H/8P/LUed7/9ku/i/LZ5i2f/JBMci /k/+K/7v/SFYyP/dfnLN/0kT8H/4v1kpuv6f3/1l/J/MpcT/XdL/jXrJ/01t23v/N6as/ycL PYbq1jvG/32L//Mw+UL+r5Hhxu/0f2rN//mNZ/V/7ZXW/2tb8X9tkv/zo5Wh8lEV+j+L/6vA /81GE3b7PzOv8H+x10D8X6jwf1ujVlqF/9uI8vB/+fyflmNOj/6+vy/qeRu1+j83TIz/y9Cq Z/836XHsXQctNGef/zN9+1upD/F/rVR1+T9To/8bmwrX/+sGWf8P/0c5t9z9X3dgRpz/M+L/ +h+F/zu+uLMc/xc/7o3/S28V/i+hW1HI/7Wf4P+68IIG//f2sDjb//Wui4j/2xR1vv/zI8/4 vw3vKPB/6VH4P/zfy2FRnf9j/b89rcL/ZX4+wP8l7kD8X2IU/u8lCv+H/8P/LUed7v/u703x f9/g/8LUyG/0f7dnmWL+79a7OH/9P2kC/u+N/7P4v+/3f9KqnP7Prvk/f4rn9H/hCFQvZfTH nNFDyh0/3IFkG+v+L7S6Iv93u7/3g/d/w7D/CLx9zv2jkm8xx//FHRab/F8/tpn9n5vzeCn/ 53dZEf83tAr/t7gDP8//ufmp4+1qKwfiTv9nHpW/BuL/Ej8r/J+K6t3i//B/7kfxf0utwv/h //B/mfzf5MlUqHb6v6dtPKLq8n+Txf9ladWT/7u1wvZu/b92CAOB+/yf67aGSuH/8H9R/m/o alz/z7pTPKv/c2O3+D9KZLn7v/7AjDj/14r/G34U/u/44s5y/F/8uDf+L71V+L+EbgX+LzIK /5f50WrR/1l3qpjONvujtLyvCZWPwv9FRi1dLUr4P23wfxlahf/7Bv9nDf4vNao+/8f6f3ta hf/L/HyA/0vcgcv+zw9DZ/V/c5SH/8P//Yk61f+N/i/F/0VF4f++0v+pSabn4f+2eIol/6fC tJuM/s99XfWy/+sf1bf5v5Lr/32C/wuHG/7v3/7PdPi/NP/nltkq5P8erfp7Xcru/1r838KV /TP9n7vcLvg/28v6f0PC5XaSP3C6T9n9BP83hhlIdfk/dxPJu/6fu1pcyf/5Xhn+73Xo59n/ 2XL+T5uT/d/U9G5+aqjUTv9n/IN6qHzUsv+TVlXn/6T/UsL/9fMdeKz/C+drbf4vXGcL+D8Z wS/i/+wkbcf/vR9kwv/h/9YOC/wf/u+1VX/8n2l8r8zcHh93Rz1vQ33E+n/y8jSn/zMd/i9L q/74v9uzcOOYkh13Rzn41/xWrsM8fYD/62dVPf7PH3r4v4VJqk/+7/z1/8Y2+/p/Cv9HiS93 /2cPzIjzf533f73+Ufi/44s7y/F/8ePe+L/0VuH/EroVpfxf8wH+Tx4Y8X8bDovT/d+I/8P/ 4f/SWoX/+wb/11n8X2pUff6P9f/2tAr/l/n5AP+XuAOX/Z+fG4X/2xKF/3uJwv/h//B/y1Hn +7/QHPzfN/g/+a/f6f90eyn/J3OJ8X8LB/vT+n8N/i/N/xVc/8/W6P/czJjz/V8YTpA/7Mv8 n4t69X+3E2nI7f8+Yv2/Kv2fnTT+b+N5teL//DFXwv8Nbgd+rf9Tl/J/1v32rRqS/N/0qPxd GP+X+FldyP9pOWzwfwuHRftU4f/wf2+inj6tw6Lwf/i/lainRs2fIqrxf7I0bqh2+r+nbahf KVeX/2tZ/+8I/6dvrfHr/40yLLjT//luglTqQ9b/w/99i/+zY27/58bZ8X9xUfi/Ssvd/w0H ZsT5v178X/uj8H/HF3eW4//ix73xf+mtwv8ldCsK+T83m/1s/9eFKVkmZY5+eCt6r9b8Xxem xeD/3kYt+r/BDQ3j/zZF4f9eWoX/w//h/xZbhf9LjGL9v9iov3sQ/5dhB+L/EqNO9X+jn9eX 0//1Hf4vUxT+L7P/891M/F9cFP7vO/2fYFf835ZO57L/C3swzf/dv6faV266yrL/m81u3u3/ 7Lwq6P8erTrc/z1adbT/02bV/8kHg//7t/9j/b8v8n/qA/yff4Bo2ynl3vhkoJ0pW/R/k+8f GTOFM32f/5M9JY89bqnB0/2fV49Z/d/tCFxa/6+3Yf2/bv8ROLX+2TNUn+H/wiNsXf6vM7n9 n5vziP+La9VZ/s+tq3m6/wv35DbF/823IZ8V/i+tI43/i9yB2/yfNAf/9xq1zf+Fb+nC/y08 Hsy2oRT+T+H/3kSttAr/txHl4f8y+r/WdwhCtdP/PW1DVer/BoP/y9KqP+v/tca49f9s2yb4 v74zv5X6CP9nJn8S1eb//EyOyvzf7eDL7f/8yNm5/q/XbopAVv/nWoX/o0SWu/8bD8yI839W /F//o/B/xxd3luP/4se98X/prcL/JXQrCvk/N5v9bP/Xymg+/m/DYXG6/3Mv7PB/m6JO93+D zH/I6P/c+yT8X3Kr8H/f4P/0hP9LjTrb/w1Nbv/nBmLwf7FR+L/Mzwf4v8QdiP9LjML/vUTh //B/+L/lqPP9X3hviv9L9X9+xkmi/3tMV8H/pR2Cp6//Z+WwqMv/DSa3/wv66ir+r5PDrYj/ C1MkSvg/ET85/Z/ui/m/tfX/gv9LXP9P/s7QmVz3f/IXlfB/fk7R8f5PjaOV9f/smOL//AzD UHlufSX/F47sr/R/epwu5f9kDmwJ/2fdrTPv+n9jh/+La9V5/k/V6P+8QMX/xXVjmnmF/8P/ vWxDKfyfwv+9iVppFf5vI8rD/2X0f4O/n4Vqp/972ob6XSkP/4f/W2jVk/9To3VDqLfu0r2r tMv/+eU7QqU+wv9Vuv5fjf6vmbKv/1en/3Pjgfg/SmS5+7/pwIw4/zeI/xt+FP7v+OLOcvxf /Lg3/i+9Vfi/hG5FKf9nPsD/ydQb/N+Gw+Js/ze68wX/tynqfP/nR55z+j/T4f8ytAr/h//7 2yr8X2LUov+zXXb/Z/B/+L/1HYj/S4zC/yW0Cv+XGIX/i2wW/u9e4f8+2//J9Dz83xZPcbb/ 6/Wj2u3/5t32WauO9n9qGq7l/+Z0oxb/Z212/2fwf2n+b9TF/J+9lP8bu9z+z0Wt+D/Zod/p /1zUq/+bhlHW/wt3j73+zz4qr0Su5P/kLvyd/u/2Q5fyf37SQ3X+z1+4yvi/u69J8X/zbbgf Ot//uSF8/N9SFP4P/7cQhf/D/22Owv/h/9aiVlqF/3v3JHKu/xOwYnrfT9/p/5624QYmavR/ 91ad6f/k+pDm/8QQfoz/m/ph6m93+G603d4o3bWuLxmqWRT+D/+30KoX/2ey+z9To/8zHf6P El3E/43NkdYuyv91jfd/bfOj8H/HF3eW4//ix73xf+mtwv8ldCsK+T9l1/yfDIAW8X/32bb5 /J9d9X9mloj/i/Z/kx9+xv9tiTrf/zUqs/9rLf4vQ6vwf9/g/zqL/0uNqtD/sf4f/g//9ycK /4f/W/gx/N9n+z+57OH/8H+rUfX4P3mcwv9t8RTL/k/2YJH1/8LNM8n/haHLmv2fGUr5P/cF tMv+r8f/bfJ/rP/H+n+yFfxfTf5PazNM3v/1CUfg1A7to/ILKJ7u/2z4kKryf96U5fV/7mqB /4tq1Wn+z1Tp/9T56/8NbgZiqNRe/+evZKHyUSv+T06G2vyfTGUq4v+G2Q481v+Fc7eI/wsT tEr4v9BVKuD/5BGkjP+Tx4MC/k+FB6sU//e0DaXwfwr/9yZqpVX4v40oD/+X0f81/qkyVDv9 39M2HlF1+T/b4P+ytOrJ/+nbDapvXbdzMLujdOfHV0KlWP/vOP/nR1Jr83+jze3/Wtuc7f+6 0f12Vv/n3h7g/yiR5e7/9IEZcf5Pi/8zPwr/d3xxZzn+L37cG/+X3ir8X0K3opD/az/B/8m7 vzLr/+H/0vzfgP/7Gv/nhyzwf1veUeD/0qNq83+s/4f/87/F+n8K/7d1B+L/EqMq839mwP9l isL/ZfZ/chnC/0VF4f++0/9NYdAM/7fb/wWNU8L/yUTFyvzf06yWL1v/D//H+n/X8X+s/5fm /9wknAr9n+PWC/5v6LT4v3H/5XaSy1mo/Hwf/F/MDlRb/d+k8X8bz6tl/ycHAv7vdehno/+b w5+9U8xf8NC5/m+c/NeNZvV/fqj9ZP83dJP/IPL5P78CJf4vrhvTzCv8H/7vZRtK4f8U/u9N 1Eqr8H8bUR7+L5//06OInlHv/x6I5234vkWF/q+15/u/KZgymxAV/N8wPUWd5/96e+u/aD1Y 0+2N0t3QtL+Vu+YY/F+WVuH/9vk/9QH+z7qLH/6Pcna5+z9zYEac/zPi/7ofhf87vrizHP8X P+6N/0tvFf4voVtRyv81a/4vHA8l/F8vD1NF/J/fLv5vywzzBf83Nq4J5nYE7r9aaNtOj8pH 4f8io5auFq/+z8/qyOr/zIj/y9Aq/B/+72+r8H+JUfi/2Ki/exD/l2EH4v8Soyrzf6PG/2WK wv9l9n8yjoD/i4rC/+H/fodUL+X/wmt2fz3f6//CFtv7B77i/0J/Pc3/BftS2v/ph2o83P+V W/9Pdd2K/xMph/9bGE/A/9Xm/9owGyOf/7NDKf/XWtb/i7xabPJ/tx035fZ/pruW/wt3jK/0 f7e/+lL+z/eo8H8LQz/P/s+u+r/2Ue32f+28qtP/jdfyf/LBFPF/sshsGf8nl4YS/i+MdRfx f/ZR4f/+3bf4h/+TKs3/3Sv8n8L/vYlaaRX+byPKw/9l9H+dvyfqLuEa+LyNh5Sry/+ZDv+X pVXP/s80/e2+pE1n7H7/1/e+m3Cr5FUA6//h//7Rqj/+T5pTnf9r3TNcXv/Xdfg/Smy5+7/2 wIw4/9eK/7M/Cv93fHFnOf4vftwb/5feKvxfQrfiSv6vCbNt8X9vDwv8X2SrLu3//ISinP5P dfi/DK3C/+X3f6O/mrRhLvtO/zefr+dGsvB/iVH1+T83iQ7/FxuF/8v8fID/S9yB+L/EKPzf SxT+D/+H/1uOwv+lNqtC/6fW1v8Lnc4C/q+VAyKj/zMP1Xi4/+u7Yuv/Wfwf/s///Cb/14s8 sEn+L6wKJpNw3HmF/4uLilr/r5FO3N6pRWGI5XeU5DL+r7FdK/7P7j8Cp3bQj+oz/F84xfF/ //Z//hp4If/n39fi/xaGfq7s/xr837ZZt2bN/0lXqYj/CydDCf8XHh+K+L/+UR3t/8Is7OP9 n5V7Iv5v4SaC//MV/m9r1Eqr8H8bUR7+L6P/k6cdrf2HtNP/PW3DdZlq9H+s/5f+tnHB/zV9 3+nbJ9B24+4o3fshsVDd/sM44f+ytOrF//lvY6rN/40mt//zI2cn+78mv/9j/T9KfLn7v+7A jDj/13n/1zU/Cv93fHFnOf4vftwb/5feKvxfQreikP/T46r/k8frEv5PBkBz+j+76v9koBb/ t9f/uZFn/N+mqAr93+3RCv+X3ir8X37/F97y5/N/biQL/5cYVZ//Y/2/Pa3C/2V+PsD/Je5A /F9iFP7vJerb/J/M98b/RUXh/77T/40BN+D/dvs/+fc0/yddwLf+r30k7vZ/Yfzo3/7PyOzB nOv/uSkQ1a3/dzuKV/yfvHbH/70ZT7ia/5PDJqP/09bg/yKjotb/y+n/mgv5P2N0n9v/3Vv1 +mEV9H9duOEn+b9w+/0Y/ze4iwrr/y1GXcD/jfi/Q/zf2LmrEP5vKep51q2j8fi/uG5MM68u 5v9kBB//t3ATwf/5Cv+3NWqlVfi/jSgP/5fP/6lRBiwmf8PfGfW0jVr9331FL/xfVv/n9JVb /68Nw4I7/Z97uRYqJd9Id7r/kye+2vyfP8rxfwuTVD/M/7Wje+WH/6OcXe7+rz8wI87/9eL/ zI/C/x1f3FmO/4sf98b/pbcK/5fQrSjl/8z5/s/IS6Ai6//JkwL+b8sM8yX/57uZ+L9NUef7 v15l9n+9wf9laBX+D//3t1X4v8Qo/F9s1N89iP/LsAPxf4lRlfm/vsP/ZYrC/+H/nvcg/i89 Cv+3/WC/tv/rpPuW5v9kBmLV/m9o8X+RUS9HYH3+r7X4v6/xf6pG//dm/T89hdmiaf7Pb+MT 1v8z/kPK6v90u+j/rB5y+z833wf/F7MD1Xn+rxmv5f98r6w2/+c3ntX/tfg//J/fF/g//N/C KYz/w/9tjcL/4f/WolZahf/7x2P3B/g/Kx2CwY8P74x62ob6XSkP/4f/W2jVH//X953zf7YP o3O7/N/oRudCdfsZbfF/WVp1Cf9nmia3//u9Wpzo/6yfFIj/o5xc7v7PHpgR5/+s+L/uR+H/ ji/uLMf/xY974//SW4X/S+hWFPJ/yq75P5kbVWT9P5l6g//bcFic7f/8mxn836Yo/N9Lq/B/ +L+v8X/W4P9So/B/r1n4P/wf/m81Cv+X0Cr8X2LUpfyfHOb4v6go/N+X+r/ZjD383xtPsez/ pNm+q77b/4XX6qF7tur/Qk8wZXql9Hzm81NZ/y/qsHj2f3bN/8l0Fvzfm/EE1v9L9H9ualGF 6/+pcv5vxP9FXi22+b/BZF//z10tPsX/yWGR6P8eCr86/+evgdfxf80kw43f6f+ERP2n/hT8 32qrNvq/1s1AxP8tRW3zf2Gcp4j/C0doCf8X+nC1+b8wOIL/e9+3wP/h/1ai8H/4v5Wop0bN H5mr8X+DPCuPfiM7o5624X4S/7cQhf9b9H/WdZ31rWm92RulrXbPcKFSMiKN/8vQqhf/JyMV lfm/1mb3f48bfk3+z+D/KNHl7v+GAzPi/N8g/s/+KPzf8cWd5fi/+HFv/F96q/B/Cd2KUv5P ne//TOi+4f++wP+N7kDA/22JOt//yQSSjP6va/B/GVqF/8P//W0V/i8xCv8XG/V3D+L/MuxA /F9iFP4voVX4v8Qo/F9ks/B/9wr/h/+r2v+FAZsk/xf60lX7v9uDY33+T3Vr/s/KB4P/e+P/ Rvxfkv9z62ri/+Kizlr/z0Vdx/9NY5vb/2n831H+z11g8/q/2zP+pfyf9zX4v9ehH/xfGf9n g8aTLsaX+T+15v8ko4z/mwPKg/2f3N2L+D+5D5bwf2HiVwH/14+y+4v4P/mQ8H/4v3mjjovC /+H/VqKeGjV/ZK7G/1m5C4vo2b3+32wbqtL1/7oR/5elVX/839Q23e1GZcKht8//+d8KlWL9 v+P8n/XTZivzf4PJ7v8+YP2/3rWD9f8oZ5e7/xsPzIjyf30j/k//KPzf8cWd5fi/+HFv/F96 q/B/Cd2KZf/nhwLz+r9mzf/JMVdi/T95y4//23BYnO3/WjcHzHR9wlsyNyr1qHzU6f7v6V3Q 3qvF33Hv8/1fqzL7P9b/w/+tRuH/8H8vhwX+7yUL/4f/w/+tRuH/ElqF/0uMwv9FNgv/d6/w f5/t/wJuwP/h/2aF9f+S/Z+MU+D/3vg/1v/7Hv+n8H/4P/Xi/7pmyf+1ptPZ1/8b8X/f4v90 M17J/8m30OL/FoZ+Luz/ukH8X5fk/xr7qD7C/402t/9zsvt0/ze2sx14rP87ZH4q/i9uB36c /9NN86h2XgOftqEU/k/h/95ErbQK/7cR5eH/cvo/eQSxvd4f9bQN90P4v4Uo/N+S/2v1MOhb NTT9fv83aN9NkErJl9/h/zK06hL+r23xf/g/ylHl7v+mAzPi/J8W/9f+KPzf8cWd5fi/+HFv /F96q/B/Cd2KQv6vbT7A/8nUG/zfhsPidP834f++x/8Zhf9bjsL/3Sv8H/5v4cfwfyv+r7X4 P/zf+g7E/yVGVeb/Ro3/yxSF/8vs/yY/HQj/FxWF//tK/3efLIb/2+Iplv2f/Lc0/yddQNP/ ifrr/6ZHtdv/tfMK/5fm/25HMf4vslWs//et/u+S6/+NUwoeuvs/fY863f/Z7P7PLPu/rs2+ /t/V/J/MX9XhXrLT//0dZSq1/t/tGR//F9eqz/N/vkua1f/p/kr+z7obVV7/Z/B/+D//o828 wv/h/162oRT+T+H/3kSttAr/txHl4f9y+j95nLdtwhqoT9tQrP+H/4vwf11/66XfHgombfZG 6UG7HnSolP8uHPxfjlbh//b5P/d8dbr/c6/88H+Us0vwf/pIaxfn/4z3f233o/B/xxd3luP/ 4se98X/prcL/JXQrzvd/IoVK+L/7aH8B/9fJZB/8307/17mNV+j/wlSxlNch+D+V+WDH/yVH 4f9izqtn/zdO+L/UKPzfaxb+D/+H/1uNqsz/sf4f/u8fUfi/lA8L/5cedRH/p6bZjD383xtP 8S//5zeS6v+aP1H4vw/3f/9Y/08ON/zfG/93yfX/eun9pfm/UH2C/2uCzsrn/9q2Qv/nRkkq 9H9q2f81dsjt//wsJvxf3GGB/yvj//zd40v9n63S/2lztv/T/p0w6/8tRT3PurVr/i9MnC/i /+ZX9mP9XyfbLeH/wtToIv5P7hj4P/wf/g//9+ewwP/h/15bVcD/1bn+31014v/y+r+mvz0L 3B4KxnF3lIN/zW+lZEQa/5ehVfi/ff5PfcL6f/g/yieUu//TB2bE+b9W/J/9Ufi/44s7y/F/ 8ePe+L/0VuH/EroVhfyf6c73fya8NcH/fb7/692gen3+T4XRk5TXIR/o/xqF/1uOwv/dK/wf /m/hx/B/+D8p+D/8H/4P//c3Cv/3EoX/w//h/5aj8H+pzTrd/4WZvWn+b64XZlEV+T/TNMX8 3613cbr/E/iD/3sznoD/S/R/7rwq5P+0wf/h/9RW/6ebKbf/cy/m8H8xO1Cd5v/cmgdX8n+N DDfi/974PzcieJn1/7SHf/i/pSj8X3X+L/TECvg/K39Kdf7PPKrd/m+2DaXwfwr/9yZqpVX4 v40oD/+X0f8NcoeSamfU0zYeUXX5v8Hg/7K06q//s27cor099Ji9UXrQzfRbzaLwf9n9n28H /m9hkurc/+k61/8z+D9KdLn7P3NgRpz/67z/65ofhf87vrizHP8XP+6N/0tvFf4voVtxJf8n L4HK+L8wLQb/9zZq2f+5PVeh/wvXwJTXIVfwf9ri/zK0Cv/3Df7PGvxfahT+7zUL/4f/w/+t RlXm/0aN/8sUhf/D/z3vQfxfehT+b/vBjv+7b+Ro/xdenH6j/3PrlNW3/t/tKF7xf2HBKvzf v8cTWov/Y/0/Jf/LrML/HeT/WmNUGf/X9dnX/3P25XT/F97QlPB/gl5K+D/r9hbr/y1GbfJ/ MlG5jP+byvk//xSM/9vUY1rwf7d7SJPZ//mDvTr/5+anLvu/3n8wZfxfN6uO9X/yVS5l/J/c B4v4P7lj4P/wf/g//N+fwwL/h/97bdUf/3e7M+pHtS/qeRuPqLr839id7v8E/lXm/1rXHXP+ T4YF9/q/4be6/Yy2+L8srcL/fa3/Gxt38cvq/1wU/o8SWe7+rz0wI87/9eL/zI/C/x1f3FmO /4sf98b/pbcK/5fQrSjk//T4Af6vC7Nt8X9vD4uz/Z9179Qr9H/hKE95HfJ5/s+2KrP/c++T 8H/JrcL/5fd/o0zjZP0//N+s4P/+EfV3D+L/MuxA/F9iVGX+j/X/8H//iDrV/8lUY/xfVBT+ 7zv9333QDP+30//p+/i330E7/d99amHwM+f7v1bmp4YhwZ1zie97X6YkuSkQ1a3/516rL/s/ G+aW4//+OZ7A+n/f4//0J6z/51+LZPV/44r/m/w1Uo9BhqRNLfLbcAd7hf7PcetX/9dMpsf/ Xdj/3Q6LS/k/72vwf69DP6f5P21O93+9+waNQv6vn/O1evyfvJwt4f+GdrYDD/Z/st0C/k9N 4WAv4P/07NuE6vF/4QjE/+H/nj6tw6Lwf/i/lainRs0fmavxf/J9O6Ha6f+etuF+skb/Zxv8 X5ZWPfu/ZmibyT0UDF23N0oPjfsW0VCpz/B/TZX+zz9V1ub/bHb/153v/7ouu/9rG/wfJbrc /V93YEac/7Pi/7ofhf87vrizHP8XP+6N/0tvFf4voVtRyv+ZD/B/935bCf/nH1Lwf1tmmC/7 P63wf8tRn+f/ZP5DzvX/DP4vQ6vwf/i/v63C/yVG4f9io/7uQfxfhh2I/0uMwv8ltAr/lxiF /4tsFv7vXuH/Ptv/yTGA/9viKQr5v25c83/yX/F/bw5BrT/A/8l28X//Hk9g/b9U/zdOp/u/ 9j4ems//3a4WhfxfOALVSxn71u/ffP6v0vX/lv2ftrbN7f/8t5if7v8kqi7/N7qTKK//c9fA K/k/f7XA/70O/Tz7P3sp/2fdDMRS/k8+y9r8nzxMFfF/erYDD/Z/0oQi/k+OgSL+b/ZtQhX5 P9lbBfyfmuRwS/F/T9tQCv+n8H9volZahf/biPLwfzn9X+9PoqnZH/W8DdfLrdH/3VuF/8vq /3TvFme+PRRY0+2N0kPjHjFCpfB/+L8o/+eHzPB/S1FP/s90+D9KdLn7v/7AjDj/N4j/sz8K /3d8cWc5/i9+3Bv/l94q/F9Ct6KQ/3PvKE73f/ISCP+34bA43f+5Z9cK/V+YJpHyOuSe8UH+ z4885/R/3Yj/y9Aq/N8X+D83koX/S4yqz/+54SX8X2wU/i/z8wH+L3EHlvJ/ZsD/ZYrC/2X2 f/Lr+L+oKPzfl/q/wJjwf/i/eZIO08O/0v+1YzH/13Rr/k/GKfB//x5PYP2/RP9nmqaU/1N2 1f+FqSbf6P9W1//L7/8utf6facbs/u8z1v8r5//CTaSA/5vcwwDr/y1GbfR/fsox/u916Oe0 9f/cZ3Wy//PDCPi/pSj8H/5v6RTG/+H/tkbh//B/a1ErrcL//eOx+3z/pyaxe02C/3vehgyo nu3/AgTL6P+0wf9ladUf/zeNtyf820NBN5i9Uc6jTb+Vwv/h/072f61tzvZ/7ehfcOf0f248 EP9HiSx3/2cPzIjyf7YR/6d/FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FIf/nlhU+3f/JyCb+b8Nh cbb/G1r834X9n3t5iv9LbhX+L7//C2/5Wf8P/zcr+L9/RP3dg/i/DDsQ/5cYVZn/GzX+L1MU /g//97wH8X/pUfi/7Qf7tf1fI7uriP8LT2Lf6P/cg+OV/F8v/47/w//Nynf7v64r5v9mn9VT 1AH+z7D+X+TV4o//67tF/9fZoU7/J6dZXf4v//p/fmHSK/k/f/fA/70O/Zzm/85f/28Y3VUo q/9z18AV/zfna9/m/8ZV/yeioYj/a2Y78Fj/F87XIv5PtluX/+vlEaSM/5PJdEX8n9wx0vzf bBtK4f8U/u9N1Eqr8H8bUR7+L6P/s9KpGPyWdkY9bUN9xPp/+f3fXfTg/7L6v9t9/vaA6vxf 0vp/bvAoVOoj/F84AhP9n2R8kP/zY1D4v6VJqp/m/3r8H+UTyt3/DQdmxPk/Lf6v/VH4v+OL O8vxf/Hj3vi/9Fbh/xK6FVfyf/d1m/F/bw+L8/3fqPB//4z6IP/XKPzfchT+717h/9b8nzX4 v9So+vyfG17C/8VG4f8yPx/g/xJ3YCn/13f4v0xR+L/M/s93M/F/cVH4vy/1fzI9D/+3xVPg /6KOi2v7P/lg8H/4v1nJ7//00OL/IqNO83/Npfxfl339Pz+LCf8Xd1ic5P/cYXEl/zf6XtmX +j9Vpf9Tp6//1xv3ceP/lqLwf/i/pVMY/4f/2xqF/8P/rUWttAr/9+/H7rP939D47Q6m3x/1 tA33kzX6v/uqhvi/3P5v9Ov/tWF0bp//c+NUoXKPGP3H+L8mafC7mVf4v6/xf26UE/8XF4X/ q7Tc/d94YEac/zPi//ofhf87vrizHP8XP+6N/0tvFf4voVtRyP+Z7gP8n7wEwv9tOCzO9n+j uwZW6/9yy43q/F9r8X8ZWoX/y+//Rpl3xPp/+L9ZOcD/Nfg//N/6DsT/JUZV5v9Y/w//94+o U/2fvEfH/0VF4f++1P/J4xT+b4unuJD/a8OCVfi/v1Eb/Z+gF/zfm/EEJ3rwf1Gf1Wnr//mD fcn/3YXHV/q/cASqlzL5a2SZ9f/ChKrv9H9mWPJ/Tv7l9n/3Vr1+WAX9XzjF6/J/g7vA5l3/ z5or+T/t10T4Vv/3Eev/dY9qt//r5tXp/m+wRf2fZHyn/zOr/k8Ovdr8n3wwBfzffZinhP8L rSrg/2wvu7+I/5PH+SL+T5ozJfm/2TaUwv8p/N+bqJVW4f82ojz8X0b/NwbZ7audUU/beETV 5f8Gg//L0qpn/6fbvrPe/zXd3ig9NK63ECrl33ef7f8C/KvN//lnZfzfwmP3x/k/P3Mkq/8z tsP/UWLL3f9NB2bE+b9W/N/wo/B/xxd3luP/4se98X/prcL/JXQrCvk/92V0p/s/GdnE/204 LE73f25WM/5vUxT+76VV+D/830H+L/v6f0Zb/F9qVH3+zw0v4f9io/B/mZ8P8H+JO7CU/zMD /i9TFP4P//e8B/F/6VH4v+0H+8X9Xxj/9jvoYP83PapvW//PPTji/+KiXo7A+vyfm82O/4v6 rP6s/zd2Nfo/+zHr/w1TwnulsHaMCjvIXMn/NaPO7f/c1QL/F7MD1Wn+zx0W+L+4VuH/svo/ bWr0fwb/h//zP9rMK/wf/u9lG0rh/xT+703USqvwfxtRHv4vo/8bZBRh9ONDe9f/m29D/a6U V5f/u69qiP/L6v+aabp1SW8PBeFD2un/XGc9VGHwG/+XoVX4P/zfo8L/UXaU4P/MkdYuzv91 4v+aH4X/O764sxz/Fz/ujf9LbxX+L6FbUcr/mQ/wf/d+G/7v7WFxtv+b3Itw/N+mqNP9n/8q 5qz+z708xf8ltwr/9wX+j/X/8H/4P/xf5A7E/yVG4f8SWoX/S4zC/0U2C/93r/B/H+3/JjkG 8H9bPMWS/7vvwTT/Fx6xKvZ/l1v/T1qN/3vj/wz+71v83wzlPV+Xvtr/ra7/d/d/aVOLZE/1 v9TwMv7P2GHA/6X5Pzl6Svi/0Z1Eef1f3+H/IluF/6vL/90+KTfghf9bitro/+QRpIj/C+9z S/g/ufjh/xZO4W3+T24i+L+Fm8hsG0rh/xT+703USqvwfxtRHv4vo/+z4f2LTvB/T9vw/cAK /V9r8X9ZWvXs/4xtbn123fZTb/ZGaTu5Z7hQqY/wf0bOpOr8n3/Qxv8tTFKt3//d7uT4P0ps ufs/fWBGnP/rxf+ZH4X/O764sxz/Fz/ujf9LbxX+L6FbUcj/udchZ/u/VoevjMX/vT0sTvd/ ozsQ8H9boir0f92I/8vQKvzfN/i/ocX/pUbh/16z8H/4P/zfalRl/q/v8H+ZovB/ef2flRlS +L+oKPwf/u93SPVa/k8eSNP8n3QB8X95/J/Wpfyf6tb8X6Ab+L9/jye0Fv+X5v/6Af8XGRW3 /l8+/9faNf8XXsxV5f8mnX39P3dYnO7/OomqzP+53kRW/3f7q/F/ka06y/9pg//D//kf/fss h/+L3IH4vyL+r/HnK/5v4SYy24ZS+D+F/3sTtdIq/N9GlIf/y+n/5KnSykvHnf5vvg1Vqf+7 t6ou/+cGE871f7fObev9n9kd5eBf81vNWnWq/5MBi8r8n8zywf8tTFLF/+H/KAvl7v/MgRlx /s+K/+t+FP7v+OLOcvxf/Lg3/i+9Vfi/hG5FKf+nPsD/tf638X8bDouT/d/UuCdy/N+mqAr9 X2vxfxlahf/D//1tFf4vMaqQ/3Mz2/B/sVH4v8zPB/i/xB2I/0uMwv+9ROH/8H/4v+Uo/F9q s073fyITtH9Vu9v/dfPK1Oj//FcgF/J/brbF2ev/hXEK/N+/xxNY/y/V/33C+n8mu/9ra/R/ 6+v/Ven/xrbK9f/C0E+a/7Pzv7pK/+cOC/xfXKtY/y+r/3OfFf4v7VkO/xe5A/F/RfyfHG61 +j9Xpfq/2WGB/8P//SNqpVX4v40oD/+X0f8NcrkdG70/6mkb8oVq9fk/0+H/srTqr/9zaM/5 P232Rmk7jdNvpT5i/b8A/6rzfzkG6T7O/zW5/Z+boFWh/zP4P0p0ufu/9sCMOP83iP+zPwr/ d3xxZzn+L37cG/+X3ir8X0K3YtH/mS63/3ND7Kf7v/toP/7v7WFxuv9zgxT4v01R+L+XVuH/ 8H9f4//GDv+XGlWf/zO3wwL/FxuF/8v8fID/S9yB+L/EKPzfS9S3+T+50OL/oqLwf/i/3yFV /J/7f7v930PK/fF/86mRu/3f3w+rQv93612U8n92zf+FOWb4v3+PJ7D+X6r/m0m5g/2fNjX6 v3AEqpeS3//pcc3/hVZ/p/9zl9sl/2em7Ov/Kfwf/m+xVfi/qFbh/1QJ/zdO7rPM6/9G/B/+ z/9oM6/wf/i/l20ohf9T+L83USutwv9tRHn4v5z+Tzoug5dTe/3ffBu3usr1/1pbo/+bobzT /N/tWq7bfpRDb6//G34r94jR4/+ytOqv/5PROfzf0iTVJ//XVOn/WP+PEl/u/q87MCPK/93+ s/d/+kfh/44v7izH/8WPe+P/0luF/0voVhTyf+6V8On+TweKiP97e1ic7f+0GyE2Xd/vv1po 6+fDhMpH4f8io5auFiX8Xzfi/zK0Cv/3Df6vH/B/qVH1+b/O4v/wf+s7EP+XGIX/S2gV/i8x Cv8X2Sz8373C/320/xtnM/bwf288xaL/k7tiov+TGYg1+z89ThX6P9Wt+j/5YPB//x5PYP2/ VP/H+n/Hrv9n5ZEl0f/5qrVV+r+V9f/GXuf2f/5bzM/2f/KHVub/JvcwkNX/uTmPV/J/jQw3 Vub//Maz+r/2Uv5vdCdRIf83zGHyof5vGFqV1/+51WyW/V94qV7C/4WToYT/awv6PzmyK/N/ MvxXwv9p+UPxfwr/N2/UcVH4P/zfStRTo+aPzNX4PyujMSJ6dkY9beMh5fB/+L+FVv31f33T ef837o5y8K//rZSMSOP/MrQK/7fP/7lRTvxfXBT+r9Jy93/9gRlx/k+L/2t/FP7v+OLOcvxf /Lg3/i+9Vfi/hG5FKf/XfID/k3d/+L8Nh8XZ/s+46eT4v01RFfo/9/IU/5fcKvzfN/g/1v/D //nfevZ/Df4P/7e+A/F/iVH4v4RW4f8So/B/kc3C/90r/B/+D/+n/j0ofQX/Z00x/+dAytnr /8l0Fvzfm/EE/F+q/+uHD1j/Tz5L/N9u/xeGE2R3V+H/bhfb7P7Pz2I62/89rRK11//9fTG3 7P8C/PtK/+evgfi/qFad5v9UOf+nyvk/bc72f8PgrpH4v6Wojf5Prvz4vw3zU6/k/3rZ/fg/ /B/+D/+3ELXSKvzfPx67P8H/+emcyvr/da//m2/D9y0q9H/dWKP/c4MJp/q/2x3KDu6hYBzM 3ig9+MdBVz236kT/Z+RkqMz/yfdA4P+WJqnO/Z/p8H/4P4ovd/9nD8yI83+t+D/7o/B/xxd3 luP/4se98X/prcL/JXQrCvk/11k63f/dZ9vi/94eFqf7PzcKjf/bFHW+//PHHP5vwzsK/F96 VG3+j/X/8H/+t/B/Cv+3dQfi/xKj8H8JrcL/JUbh/yKbhf+7V/i/z/Z/ATfg/3b7P/n30e2b vf4vCK5QqW7N/4XLn5/Judf/ze3LrFVH+z/zUI2H+79Hqw73f82a/7PyweD//j2e0Fr837f4 P1Vw/T9VzP+FI1C9FPzf2hH4x/+5L7df8H9mnHL7v3urXj8s/F+i/3Pna17/N+pr+T/fK/tS /1dw/T/8X5r/czcR/F/iZ4X/U3EPqO28Wvd/06Pa7f/aeYX/i74G4v+kwv9tjVppFf5vI8rD /+X0f3KTsf4ysdf/zbfxkHJ1+b+7asT/5fV/ZtBu/b+hkeGsnf7Pv2EbwjPaJ6z/h//D/9Xm /7oO/0eJLnf/NxyYEef/Ou//+uZH4f+OL+4sx//Fj3vj/9Jbdar/C50n/N+//Z8eP8D/yesx /N+Gw+Js/9e6Ae8K/d/86MH/rfq/weD/MrQK/4f/+9sq/F9iVCH/13b4P/zf+g7E/yVG4f8S WoX/S4zC/0U2C/93r/B/+D/8n3ozvfLT/J8Zg43J5v/0OOH/IqNejsD6/J9bzQb/F/VZ/fF/ Y1ej/7MXW/9P/qKq/J+e2uzr/434v6/xf7fD4kL+r/Fo70v93+0n8X9xrdro/3r3cRda/+/p woT/w//JP4ft4v/wf/g//N9C1Eqr8H8bUR7+L6f/k3ez1iZEPW3D9wMr9H+DqdH/zVDeaev/ dU1m/+cHv/F/GVqF/8P/PSr8H2VHufu/8cCMOP/Xi/8zPwr/d3xxZzn+L37cG/+X3ir8X0K3 opT/M+f7PyMvgfB/Gw6L8/3f6PZi3+2P0tY/KYbKR+H/IqOWrhYl/N/Y4f8ytAr/9w3+73aw 4/8So/B/r1n4P/wf/m81qjL/N2r8X6Yo/B/+73kP4v/Soy7j/2R6Hv5vi6dY9H99Dv8X5sC+ 8X/BW6T5v/n40axVh/s/a4r5P/cd0mX8n+pW/Z+MU+D//j2ewPp/qf6vzvX/yvm/z1j/r5j/ k4mIWf2fbpb9n+5z+z8/i+ls/zfIh1SX/7NTbv93u93h/yJbhf+rzf+17u6R1/+ZKv2fexjG /8V1Y5p5dTH/JzcR/N/CTaSZV/g/hf97E7XSKvzfRpSH/8vp/wSsDH54Y6//m2/DDybg/16j 8H+L/q9xy0bqdhie+oGR/s+4rlKo3K4ZT/d/Af7h/zY8idTn/9wTfoX+b2zwf5TYcvd/04EZ cf7Piv/rfhT+7/jiznL8X/y4N/4vvVWn+r8wZxv/92//5x4Yz/Z/bet/G/+34bA43f+N+D/8 H/4vrVX4P/zf31bh/xKj8H+xUX/3IP4vww7E/yVGVeb/WP8P//ePKPxfyoeF/0uPwv9tP9jx f+7XM/q/pkb/1/YV+r9/rP93b3XYnwr/tzSeEFZfw/99gf/Tpkb/V3L9v2bV/4Uru+zuOvyf nTT+71v83+A6FXnX/3PXQPxfVKvwf1n9n/usqvN/7iaC/0v8rPB/Ku4BtZ1X+D/8359tvEbN m3VYFP4P/7cWtdIq/N8/Hrs/wf/ZYPf0/qinbbhebo3+rxvxf1la9cf/WddZd/5vsHujHPwz v9XtZ7TF/2VpFf5vp/8bq/R/Bv9HiS7B/7VHWrs4/zd4/9f1Pwr/d3xxZzn+L37cG/+X3ir8 X0K3opT/U+f7PxO6b/i/z/d/XVen/wt/Sl3+z887yur/LP4P/7cWVZv/6wf8X2oU/u81C/+H /8P/rUZV5v/aEf+XKQr/l9v/+adh/F9UFP7vS/1fmP+L/9vt/8Kp7nbkbv8XLgDdn6i//i/0 BGU68E7/J82ZzU8t5P/G6VL+r5cPBv+H/5uVgv6vl2MgVHv9XzevVtf/G7P7P1Wl/1tf/y+4 FZmJ/mX+z3ZL/q/T9vaH6s4MCa9Fpt4f1KHy3/d9uv97UiK1+L/RzbPN6//6Dv8X2aqz/J9z tef7v/5R7fZ//byqcv0/91kt+78nmHyo/xv9KVzG/0kfqYz/07MdeLD/k5tTEf8XJmiV8H+y t+ryf3J4l/F/oQctJ9TOa+B8G0rh/xT+703USqvwfxtRHv4vo/8LYyO2nfZHPW3Dj1tU6P/u rcL/ZfV/nVuHyY1b9E23N0oPo25/K/fPGv+XpVXX8H+Tye3/Zjf8mvwf6/9R4svd/+kDM2L8 X+/+d307M/SPwv8dX9xZjv+LH/fG/6W36lz/F17n4v9eHq3m/q/9hPX/5PU+/m/DYYH/i2zV pf2fTCDJ6P8Gi//L0Cr8H/7vb6vwf4lRhfxf1+D/8H/rOxD/lxhVmf+zPf4vUxT+L7P/k6/s xP9FReH/8H+/Q6rX8n/SfcP/vfF/1hTzf31Xyv+pbtX/yYmF/8P/zcoB/m/sivk/VaX/G4v5 v85U6f/aYdn/ub9Wd61N8n+DfVSX83/jNK92+r+/Ufi/yB1Yv/9zqwNU6P9Ujev/4f/wf/g/ /N/qDsT/SYX/2xq10ir830aUh//L6P+sPO1ItXf9v/k23E/W6P9Y/y/9beOS/2s67cctwovu ff5v8iO+UinW/8P/xfi/2wGYff0/g//D/1F8ufs/c2BGnP/T4v/aH4X/O764sxz/Fz/ujf9L bxX+L6FbUcr/NR/g/2SEGP+34bA42//1TZ3+L5zi+L+XR6tuVrH+H/7vOv5v7PB/qVH4v9cs /B/+D/+3GlWZ/+sm/F+mKPxfZv8nLC6n/9Mt/i81Cv+XGIX/i43a6P/k3/F/b/xfwfX/tD5/ /b9OziL8H/5vVr7b/xVc/8/i/xau7J/p/3Sz5P/aYazT/3VymhVZ/0/2Fv7vG/yfv1p8qf8z a/7PPwVn9X+W9f+S/J+zmsv+7wkmH+v//MFeyP8F9Xh/16qq8H/hcCvi/6QjUcT/2Ue12/+Z ebXm/3p5QC3i/6QLX8b/yV06zf/NtqEU/k/h/95ErbQK/7cR5eH/Mvq/Qe6JUu2MetqGqtT/ DQb/l6VVz/6vHZpbR1p3bStjDnv9n/mtlHz53cn+z4z3uc0JUZ/n/2S4G/+3MEn1Av7P4P8o 0eXu/9oDM+L8Xyv+z/4o/N/xxZ3l+L/4cW/8X3qrzvV/MtKF//u3/3NfsXe2/wvd9SL+r/fn K/5vywzzJf9nDf7vwv6vN/i/DK3C/32D/2sb/F9qVH3+z62Dgf+LjcL/ZX4+wP8l7sBS/m+w +L9MUfi/vP6vl1cLrP8XFYX/w//9Dqleyv+FucZ+I3v9n1Ce+Wv1f/o/P9M80f/9bdV56/+F qbAZ/d+jVUf7P/WQcs/+735xxf/9ezzBL6CI/4v5rP74v3443//JKf6d/k+bZf+nZYmZnP4v LLNVm/9bXv/vdgVsxP8lHIFT7/d+qD7D/8nbMvzf36g//k8347X8n7/vfqn/W13/L7v/c5fb 66z/Zyf3cWf1f92q/wvzV7/T/9k1/ydX/iL+LwxOFln/L3TeUjpnW/1f/6iq8X+2l91fwv+F x4MS/i90a3219xo434ZS+D+F/3sTtdIq/N9GlIf/y+f/tAAl3Zr9/cDnbTyi6vJ/Y3e+/wvP 2yYlamzm1en+r5lu/+fGLRqd4P9G9+ovVOoj1v8LR2Bt/k+mMlXm/9quRv9n3Su/rP7PReH/ KJHl7v+6AzPi/F/n/V/X/Cj83/HFneX4v/hxb/xfeqvO9X9HTCWuz/+51yGn+z/pE+L/NhwW p/u/Ef/3Pf6vV5n9nxnxfxlahf/7Bv/XD/i/1Kiz/Z+81sm6/p+blID/i4zC/2V+PsD/Je7A Qv5P6w7/lykK/5fZ/0mvHv8XFYX/+1L/F2ZG4//wf7NScv2/r/Z/9lL+bzC5/V9YfQ3/t9v/ fcL6f/n9nyrm/1q74v9k4Rw92pQ7vvzPoeo+wf95wnu8/1OTHUb837f4v951Y7L6PzfnEf8X 16qz/J/7wlv8X1SrNvq/RvyfCTPRd/q/9lHh//B/+L9q/Z95VLv9n5lX+D+F/3sTtdIq/N9G lIf/y+j/JqMf1U7/97SNR1Rd/m+y+L8srXryf7eHr+nWVdKdMaGrtMv/De4JOlQK/3eg//MP 2vi/hUmqc//Xne//Ou2e4fB/lLPL3f/1B2bE+b9e/J/5Ufi/44s7y/F/8ePe+L/0VuH/EroV V/J/Osy2xf+9PSzwf5Gtwv/h/za8o8D/pUfh//B/L4dFdev/ueEl/F9sFP4v8/MB/i9xBy77 P9+OrOv/jQP+L1MU/i+z/xv8dCD8X1QU/g//9zukein/1+bwf2EgofkTVZP/K7j+nxlK+T83 m33F/4W55VX5v/zr/3UG/5fk/4zWpfyfNjX6v25l/b/bM4q/zub0f+YD/J//Mpes/s9FLa3/ 1xv839f4P3eBzer//CmM/4tq1QXW/3PQq5T/0+Zk/zd0xp1EWf2fP9iX/Z8c7AX83+COwLz+ z3Rr/k9EQwn/Z9vZDjzY/8kHU8T/yX2wiP+bjSYc7P+8QC3k/+QILOH/RrlLJ/m/+TaUwv8p /N+bqJVW4f82ojz8X07/5+/uptH7o5634fuBFfo/2+D/srTqz/p/Y3/r5minlRL8n3UvVkKl PsT/yRNfZf7Pj0HV5v/842Je/zee7v/GCf9H+YRy93/2wIw4/2fF/3U/Cv93fHFnOf4vftwb /5feKvxfQreikP9zj1an+78+fG8D/u/tYXG2/xs6/N+F/Z/t8H8ZWoX/+wb/N3b4v9Qo/N9r Fv4P/4f/W42qzP/ZBv+XKQr/l9n/SZ8J/xcVhf/D//0OqV7K/3WhE+02stv/SRewav9XcP2/ cv5Pra//h//D/7H+X8TBfpL/W1v/D/+n1o7AP/6v75b8n9HuhMrr/+6tev2w8H9p/m/s8H9p /s9/SN/q/wz+D//nf/Tvs9zp/k8eQYr4v6cr+8H+T25OJfxfU279v3BC1eX/tC7n/1j/D/+H /8P/rUY9NWr+yFyN/+v9jALd+/v+Tv/3tA03MFGj/2s/Yf2/8VHt9n9mXp3u/5watc7/mdbs jdKDdf8WKtfd6/F/WVp1Df/nB36y+r/WNhX6P9cq/B8lstz933BgRpz/G8T/2R+F/zu+uLMc /xc/7o3/S28V/i+hW1HI/5nuA/yfjJ6W8X+hi4j/exu16P/GBv/3Pf7PzzvM6f96g//L0Cr8 3xf4P7dyE/4vMao+/+d6TPi/2Cj8X+bnA/xf4g7E/yVG4f9eor7O//kfwP9FReH/vtP/DXId x/9t8RRL/k82Eaq9/i88tnfNn6i//m96VLv9XzuvCvo/NwXiOv5PTWNoddifCv+3NJ5gHnwN /4f/e1TL/q+XAdteT+H93K5749Nsdr28/p+etNv9odp7x7cyPBKqbryS/+vsmNv/uc/qdP8X JnZW5v/slNv/3Q6LC/k/WfvqW/0f6/99jf9zn9Wy/3u6MH2b/xvX/F8fpmSELsi+vsXfz2rZ /z3twGP9n5Hzroj/k/tgEf8X7tIF/J/152sR/yfjZGX8nzQnzf/NtqEU/k/h/95ErbQK/7cR 5eH/8vk/NclDz5Tg/5634eoa/d9dNZ7p/2TUWKrd/q+dV27s9lz/1+lbV1Z3Ohx6O/2fG94M 1SzqTP8nPaba/J/vklbm/8Yu+/p/fuTsZP/nB7+z+j83oIr/o0SWu/8bD8yI8n+6Ef+nfxT+ 7/jiznL8X/y4N/4vvVX4v4RuRSH/54bYz/Z/rQ6zbfF/bw+L0/2fxf9d2P+ZEf+XoVX4vy/w f24aJ/4vMao+/+e+iAn/FxuF/8v8fID/S9yBhfyf1h3+L1MU/i+z/5PXQPi/qCj833f6vym8 N8X/fY7/s2v+bz41crf/+/th4f9eorb7P4+H8H9RrXpe/6/B/32//wufZYn1/8LUaJvi//Q4 q9wckuX1/0aPHFqTMrXIho6gTFepc/0/F/Xq/5rJPRLoru2n/e8qpt4vwhgq/1nh/2J24EJU If+nmxH/F9kq/B/+7/XV8LP/81+1V5//W13/r6D/uzdH+mj4P/yf36At6P/Mo2L9v40oD/+H /1uIWmkV/u/fj91nr/9nOv2odq7/97SNR1Rd/m8w+L8srXr2f81obn2P207uhwT/5ydPhOr2 M9qe7v8C/MP/vXsSOd//dX7N7qz+rzvf/3VNfv9n8H+U6HL3f9OBGXH+T4v/a38U/u/44s5y /F/8uDf+L71V+L+EbkUp/2fO939Ghl6K+L9OvhkE/7fX//X4v+/xfzL/IaP/6xr8X4ZW4f++ wf91Fv+XGlWf/3MDMfi/2Cj8X+bnA/xf4g4stf7fOOD/MkXh/zL7P/l1/F9UFP4P//c7pIr/ c/8P/3dl/zfeWx32p8L/4f+O8H9tg/+LjDrL/7XNhfyfnnpZ/6+3Sf5PPypvX/B/MTtwIWrR /w3us8zr/243fPxfXKvO8n/uvML/RbXqNP/nbiJn+7+xz+7/3MMw/i+uG9PMK/wf/u9lG0rh /xT+703USqvwfxtRHv4vo/9r/ZU9VDv939M2fD+wQv9X5/p/M5R3jv/T4//t3WGaoyrXqOEa CkMQVNRZ7fn/2oFFKibRLhHEBB/OdTZfv13l6mVQAbmD6Sd3kpvQVdrn/xr9W6mP8H9mkm/q xv/h/2rxf24sjP+jRJbg/7ojrV2c/zPe/7Xdj8L/HV/cVY7/i5/3xv+lZ4X/S+hWFPJ/7h3F 6f5PZk/xfxuaxdn+b9KtO4u92X+30NZflKHyofB/kaGW7hbv/k/aHPv/bXhHgf9LD1WZ/zNN g/9LDYX/e4+F/8P/4f9WQ+H/ErLC/yWGupT/k9Ew/i8qFP4P//c7pYr/c/85wP/JP+U7/d84 rfm/2TL2PP7vkdXR/s+TKPxfVFbP/s/i/9L8Xz8s+79uDF9fntLYn/yfx66F/J9d83/+PnW7 S4Rp8H3+bz510dpy+/+NH+D//JWU1f85bv3u/27DRZvb/7n1Pqf7vyclgv9b83/+Hngl/zc+ KvzffOrnyf+5hwj+LyaU/rz9/4r6P1nKVMT/tbMTeKz/u3feUjpn2/zffSfyIv5P+iwl/J80 N/zfwkME/+cr/N/WUCtZ4f82ojz8X0b/10tHWqqd/u/pGI9Qdfk/2+D/smT17P9M3zb29qCa xjHB//nZt1D5nzzd/7H/39f4v1vby+3//MxZdf5Ps/8fJb7c/Z8+MEac/2vF/9kfhf87vrir HP8XP++N/0vPCv+X0K24kv/rw2pb/N+fzeJ0/+deHOD/NoWq0P+pDv+XISv8H/7vNSv8X2Io /F9sqNcziP/LcALxf4mh8H8JWeH/EkPh/yLTwv/dK/zfR/u/sBQG/7fFUyz5PxVu5En+Lywt /GWAK/5v3unc7f/alw8L//cWKof/k1s//u+P+QT8Xw3+r8nu/1r838Kd/Yv83y2JMez/l7AI Z+p9NzxU/gSe7v/CFY3/+7f/0814Kf/n7yb4v4WpH/xf1v3/7Kr/k4uhNv8noqGI/9OzE3iw /5OzVWL/v/AcLOH/7puiF/B/RlBSEf8ni+nwf/i/eVLHhcL/4f9WQj0lNR8y1+L/TOPfv4Rq X6jnYzxC1eX/Jov/y5LVk/+7ddbHxj2oxt4m+L/W9U9CpT5i/79K/Z/vieH/lhapmqfqfP/n n7tZ/Z8Lhf+jRJa7/zMHxojzf533f13zo/B/xxd3leP/4ue98X/pWeH/EroVV/J/932bj/d/ bYP/S/R/WuH/toWq0f81+L8MWeH/8vs/eXmK/9sS6kr+z69Vwf9tOYP4vwwnEP+XGOpU/+c/ GPzfllD4v7dQX+f/fHvD/0WFwv/h/35Hw/g/95/v9n+iG0r4v3DBFvB/ZpLhcAn/Jwvrq/N/ /qPD/y2sIdnm/+TyK+L/hkkipjT2bf6vncr5P/+IKuP/rPusqvN//oMp4P/sNDXe/5k2Zf8/ v4QzVPi/Hbdb/F8h/+dPGf7vfeoH/4f/27LqFv8XlxX+D/+39BDB//kK/7c11EpW+L+NKA// l9H/df4OGqqd/u/pGI9QZ/o/mTlL839tGAdKqE/wf/IUrsr/2eF2M7+d6862Zm8obUc3ngiV wv/h/6L8X9/U6P9G98oP/0c5u9z9X3tgjDj/14v/Mz8K/3d8cVc5/i9+3hv/l54V/i+hW3El /xfemuD/Pt3/3R70Lf4P/4f/S8sK/5ff/93XBEqF/8P/uWL9e9yc/s8vSsD/RYbC/2UeH+D/ Ek/gsv+TJVn4vw2h8H9vob7N/8mqZvxfVCj835f6PxlO4f+2eIpF/3cXlO4gR/u/oESS/J95 +bCW/d8Q1hoX8H+N/H0J/2fvgxWl9i+B6ObVuv+TFGrzf75Z5PR/zbX8n6zoKOL/+jBgTGns G/2fDTrreP83+PtDa3XKG5jZL//T//lbumnDIzLJ/4Uvc/wA/+dfUmT1f7pd8n+9HY3zfyZ8 ocZO/+fRS6g+xP+F9YpyDg71f53cW4v4vxb/t/G6WvF/vs1V5v8GP1+T0//dYq34v3Z6VHuX mM+P4f5Bp/s/7Z70ef1f1634v2F+Y8L/4f9CqOYR8Wj/Zx/Vwf6vl9OP/8P/4f/wfwuhVrLC //1j2P0B/m/0w4dQ7fR/T8d4hDrT//XyEBkS1i7rMFseercf4P+MTARW5f/6zr0Yu/VeRtPt DaWtdp31UCn834H+z53+yvyfGUyF/q/3HWn8H+Xscvd/3YEx4vyfFf/X/Sj83/HFXeX4v/h5 b/xfelb4v4RuRSH/597Tnu7/5IUE/m9Dszjf/zXuppOy1EJb/zI9VD7Uiv+TZoP/2+v//Hsx /N+WdxT4v/RQ5/o/mSrE/20JdR3/1/tpW/zfpjOI/8twAvF/iaFO9X9+2Qf+b0so/N9bqG/z f/Kdpvi/qFD4P/zf72gY/+f+89X+7748/Hj/d+sLyD9I0jnU/8l6oCL+r5cPpjL/J/MJ+L+F NSSb/F8nlKeM/5N+WQn/J02viP/zv13G/4kLMU0KHgrvVEQWfIT/8yvSCvi/bnK3dN3pYUrw f52/j4bqM/xfuMRL+D/xFkX8nzH4v43X1Yr/80+PIv7PQa9C/s8/RAr5v3DnT/J/s2Ooj/B/ 7gFQyP8FyFHC//lLuIz/EwNdxP89ncCD/Z/cGkr4vyY09rr2/5OHSBn/Jx9SCf8nY+E0/zc/ hlL4P4X/+yPUSlb4v40oD/+Xz/+12ndJQ7Uv1PMxHqFO9X9hYJXk/6QzEnq3Y3e+/5MXXIn+ T2J8iv/rrHs1cRt6yxuKff6v9+sLQ6U+wv+ZSUamtfk/f73U5f/05F5uV+f/Ojckxf9Rzi53 /9cfGCPO/w3i/+yPwv8dX9xVjv+Ln/fG/6Vnhf9L6FYs+j/tvyEup/9rTXe+/9OBIh7v/4ys OcT/bVlhjv+Lu1vg/zI3dvxfcqgL+T95nuXzf265Gf4vMdTp/s8fN6f/M2OH/8P/rZ5A/F9i qDP9n/UP3qz+z+D/kp8i+L/kE7i8/5//l+L/okLh/77U/4WV0fi/vf6vl9PlX2ru9X9BcN2x 2Kr/kyUSbcryyvf1qcv+T0ukfP6vsyv7/4WlsN/p/7puzf9JVrX5P7lB4P/2+j+Z3u2lc7HX /3WzSo122f+1rfTL8vm/WVbP96XwNfA5/Z/uV/yfv91m9X9dt+b//C09o/9rm/P9n/ZP/AL+ z7ZuqZnutOlT/J+fXwrVb1bvH1ZB/xdm/Yv4P0mhhP9z3bGs/s/fLa7j/xr5TrUS/q93GDar /3NriZf9n7+3FvJ/oXeb5P9mx5DP6mz/51p5Vv9nzKr/G8Jn6f9wqP/z3xhcyP9J56yE/+vn J/Bg/ycpFPF/0pEo4f/Cwq8S/k++s7qI/5P7bBn/F1Y3J/m/2TGUwv8p/N8foVaywv9tRHn4 v4z+z/hbetvq/f3A52O4iYka/Z9tzvd/YZo4yf8NgTO2T6FO839Wd1PrnvAp+/91k/ugQzUL xf5/2f2fHxtV5v96m93/mfP9n3UDgrz+z+L/KNHl7v/sgTGi/J9pxP/pH4X/O764qxz/Fz/v jf9Lzwr/l9CtuJL/68NXxhbwf0+LffB/8f7PvaDF/20Kdbr/87Mn+L8t7yjwf+mh8H/4v7dm UZ3/819KjP+LDIX/yzw+wP8lnsDl/f/8SuKs/m+O8vB/+L+XUPi/lA8L/5ceCv+3vbFf3P/J /Hea/5Mu4J/+L/QEk/xfmD/6HP/3NHXxbf5Pre3/18lVhP/793xC0Ff4v73+T+t2Zf+/RvIo 4P9aWTmT0/+ptf3/8vs/M5byf+v7/4UFVSX2//Mr0rL6Pxfq3f+Nnfi/Zkrxf+00PCq/VyP+ L+YELoRa9n9u3JHX/5nhSv5PvsYA/7cw9bPV/02Parf/m+YV/u97/J/F/+H//GeE/8P/bQ2F /8P/rYVayQr/9+9h9+n+z2/1Hqq9/m9+jEeouvxfa/F/WbJ69n+j1t10e8KPJsX/DeL/Bhlp fML+f/i/7/F/bZX7/+X3f7efxP9RYsvd/w0Hxojzf1r8X/uj8H/HF3eV4//i573xf+lZ4f8S uhWF/J+xa/7PhCn4Av5PTj/+b0OzONv/adurUv5Pjlud/5s31Fyhlv1fL+sfMvo/bfB/GbLC /32D/+s0/i81VH3+j/3/9mSF/8s8PsD/JZ7AUv6v7/B/mULh/zL7v8kfGP8XFQr/96X+L6SD //sc/6dG/F9kqOcmaIZl/9fKUtic/s+u+T8rx8X//Xs+gf3/DvN/Fv+3xf8Z+2//p5uE90p3 /ycftONrV/F/utGD+D+b5P+G4VH5DRTxfzEncCFUKf83avxfZFan+T+z5v98G8jq/7Qp5v9u oU72f30/5vZ/rsu57P/CCurv9H8K/4f/85/RNv8nF1Rt/i8AnyT/Nz+GUvg/hf/7I9RKVvi/ jSgP/5fR/7X+bWOodvq/p2M8pNwn+L9uf6hf/xdWXpjz/d8YRjs2IVTwf8P0FOo0/zeN3ej2 /xv6ptsbSnd2HH8rhf87zv/5cVtt/s/k3//vfP9n/Zxj3v3/FP6PEl3u/m88MEac/zPi//of hf87vrirHP8XP++N/0vPCv+X0K0o5f+a8/1fa6TfVsL/yUgB/7dlhfmS//Nvd/B/m0Kd7/8G ldn/Kfb/w/+thcL/4f/emgX+7y0W/g//h/9bDVWZ/zMD/i9TKPwf/u/5DOL/0kPh/7Y39mv7 vzBr5u/nqf6veQn16v9mq5t3+792XtXp/x5ZHe3/3BfQrvg/+Xv837/nE9j/L9H/3forV/J/ 45Db/7lN+Zb9nycHerQpT/xACsJj4RP8n8dFWf2f49bv+/9NfW+8/2vHFP/nvWeofrN6/7AK +r+hDc1Dzmcd/m90KeT1f+4Sxv9FZXWa/5Mb03/qpRzh/9yM4KL/m8OfvUvM3/DQ2f5vaLL7 P/UB/s/i//B/+L+IUPi/I0Lh//B/a6FWssL//XvYfbb/k6dHqHb6v6dj+N5thf5vjvJO8n+t 9Fnq8n9m1M7/2XHcHUp31vXKQuU+sh7/lyWri/i/pkL/1w/Z/V/H/n+U+HL3f9OBMeL8Xyv+ b/hR+L/ji7vK8X/x8974v/Ss8H8J3YpC/k93a/4vtIcS+//JMkT834Zmcbr/cze8Qv7vmBvT 6f6vPSDUiv8zCv+3HAr/d6/wf2v+T3f4v9RQ9fk/t4wT/xcbCv+XeXyA/0s8gez/lxgK//cW Cv+H/8P/LYfC/6Wmhf97y+oz/Z+eKtz/b93/9ez/t8X/sf/fF/k/u+r/wnxoAf+nv9n/NWv+ L7yYK+H/vBI53v9p3fdNbv9nug/wf4FMlfB/oXf2lf7PrXm8lP/za/+/0/+5bsyy//PzNfi/ TT2mBf83jPn93yfs/4f/w//h//B/b5NM+D/831qzwP/h/96zevV/pm8f1U7/93QMNzFxvv8b 7aPa6//CwCrMEpgO/5clqyf/dxvBuXmN29ig77q9oXTXuztnqBT7/x3o//wjtzL/14y5/V9r m7P9n+39C272/6OcXIL/64+0dnH+rxP/1/wo/N/xxV3l+L/4eW/8X3pW+L+EbkUh/6fGD/B/ VtZHFPF/YVkM/u/PUMv+b8D/fY//a1Rm/2c6/F+GrPB/3+D/2P8P/+d/i/3/FP5v6wnE/yWG wv8lZIX/SwyF/4tMC/93r/B/H+3/htmKPfzfH55i0f+F7YCK+D8Jleb/wvrU3zWPFe7/V87/ eRK17P/ktQj+79/zCez/l+j/tG5P3/+v02E+9Bv9X2tX/N/kn1A5/Z/7Eu7T/Z+/drP6v9tg bsH/mcbdZ/P6P+eU8H8xJ3Ah1LL/c3cL9v9bDLXR//mnx3f6P7W2/9/oL/Gs/s+u+r/+Ue32 f/28qtL/3W4Kp/u/yWT3f/Za/i/cxvF/+L95wf/h//B/+L/VUE9JzYfMtfg/M/mna9s07e5Q z8f4CP/XylNaqr3+L3yn2ItTwv/l9X+DvXVrb0/4/qkfGOn/pm78rfwIHv+XJas3/+dfZNTm /3SX2/+pT/B/bkCQ1f+5L1TD/1Eiy93/6QNjxPm/Xvyf+VH4v+OLu8rxf/Hz3vi/9Kzwfwnd ilL+L4Ra8H9HXFcr+/+F1bb5/J/F/x3j/1o3+VfK/8l1V5v/OwKJLPs//3Ya/7flHQX+Lz0U /g//99YsqvN/7P+3Jyv8X+bxAf4v8QTi/xJD4f/eQn2Z/7PC4vB/UaHwf9/p/6bw3hT/t9f/ heVTaf4vvBFtXkLh/z7c/+n1/f/k7/F/+L9ZOWD/v9Gevv9fJzeuyvxf2P9vmBLeK/0uLZIV mGbN/4Wsq/J/U5N9/z9nX073f/39O0LlfOL/Vvzf7Sl8Jf/X+FP2pf5PFfN/rseE/4sJ9eL/ 3B6oK/5vDpOr8X/SkSji/8JXuZTwf3LzK+L/wnFL+L/QEyvh/6QNlPF/craK+L/2Ue32f+28 wv8p/N8foVaywv9tRHn4v4z+b/DPRDP4cepO//d0DNfLPd//yaNRqr3+z7aziv3/MrxtXPB/ 5jYIHl3vJfzPu/yfbVxHNVSK/f8O9H/+kVuX/zMm+/5/dfo/94Vq+D9KZLn7P3NgjDj/Z8X/ dT8K/3d8cVc5/i9+3hv/l54V/i+hW7Ho/4zO7f/cK+EV/ydT8CX8n0yTldn/L7wLwv/9GQr/ 9xbq2/yfn3nO6f+6Ef+XISv8H/7vNSv8X2Io/F9sqNcziP/LcALxf4mhKvN/xuD/MoXC/+X1 f728ccb/RYXC/+H/fmcuLuX/AgfwXerd/i+s6OhfQr36v9ATlOXAO/2fnlcF/Z+eLuX/wn0c //fv+YSuwf+l+b9+On//v2/2fw7l4f/eQkX4v1Ev+b+27bP7v+4j/J8NzUPO55H+L0ygfqf/ 67tr+T8/p4r/e5/6OW3/P21O93/NmNv/dev7/3Wzqhr/J82miP97OoEH+z9JoYj/k+dgEf8X 7rMF/J+sxCnj/+SZWML/hR50kv+bH0Mp/J/C//0RaiUr/N9GlIf/y+j/bHi6puz/93SMz9j/ L7//u4se/F9W/9c2bhJft12Yy9/n/0b/Mk8q9RH+T8b01fk/P2FRmf+7fUY1+r/O/Tb+j3J2 ufu/9sAYcf5vEP9nfxT+7/jirnL8X/y8N/4vPSv8X0K34nz/J/2JEv4vGCP83xf4P/fCrpT/ k8F/bf6vyRCqeQm17P9aWf+Q0f9pg//LkBX+D//3mhX+LzFUIf/nlnHi/2JD4f8yjw/wf4kn sJT/Gyz+L1Mo/B/+7/kM4v/SQ+H/tjf2a/u/IXAA92O7/d8wr7RZ83/2UaXu//dYn1qf/3tk dbT/c6/VV/yfZI3/w//NCvv/pfo/v0zMTGEx9k7/184qt4Zk0f9N/m5hGunE7V1aFKZY5FuS 7Kr/C9MJ8g+rwv+Z3q33yev/7lm9f1j4v4/zf7dmgf+Lywr/V5f/G5vG5PZ/vrHj/9I+K/yf ihugtvMK/4f/eznGe6h5WoeFwv/h/9ZCrWSF//v3sPts/zf6DoGZUvzf0zHUR+z/p8NwMZ// G9n/7wj/Z8x4e9LrtjOhq7TL/w1uBB0qhf/D/0X5vza7/2s/wP8Nrull9X/u6xfxf5TIcvd/ 3YExovxf24j/0z8K/3d8cVc5/i9+3hv/l54V/i+hW1HI/5nufP/XSh+7jP+bL/bB/0X7v85d L/i/TaHO93+Dyuz/TIf/y5AV/u8b/J/u8H+poerzf+z/tycr/F/m8QH+L/EEsv9fYij831so /B/+D/+3HOp8/yezt/i/LZ4C/xfVLp79X2cr3P8P/4f/O9f/ad3i/yJDbfN/o3dMegqrRXcu LZqxhVr9n7vdLvi/xuL/Ev1fgH8l/J/jAnn9361ZXMr/+Tb3nf5Pmyr9n/usqvN/2n3V3qL/ kymlUO31f/28+gj/J52zIv7vvrDexz3W/8nDqYT/C0ujS/i/cEFV5v+mcv4voL0k/zc/hlL4 P4X/+yPUSlb4v40oD/+X0f8Ng59JlZ3Tdvq/p2P4BVoV+r/7roan+j/7qCrxf3psb71b7VYI 7g6l7eAme0PlTs2I/8uS1Zv/037+pTL/Zzr8H/6PclC5+7/+wBhx/k+L/2t/FP7v+OKucvxf /Lw3/i89K/xfQreikP/T45r/k7VRRfyf9J7wfxuaxfn+r1XF/F94v4D/W/us/vJ/ft1hTv/n Xl3h/5Kzwv99g/9j/z/8n/8t/J/C/209gfi/xFD4v4Ss8H+JofB/kWnh/+4V/u+j/Z8secT/ bel0rvi/sAYW//ca6tL+T5az4P/+mE9wA0f8X9Rn9YH+Lzw+Svg//27RDPfb2D7/N78HtvYT /F9wK2Hp9nf5v75b9H+ji5HX/7kXc/i/mBO4EAr/F3kCt/k/f2P6Uv+nbDH/55bs4f9iQl3D /yn8H/7Pf0b4P/zf1lD4P/zfWqiVrPB//x52n+3/Ov8UNr2fkNzp/56O8ZBy+D/830JWL/v/ Wddj0m1rZTprp/9zKwxC5f4Pg//LkhX+D//3qNx3t+H/KJHl7v/sgTHi/J8R/9f/KPzf8cVd 5fi/+Hlv/F96Vvi/hG5FKf9nPsD/yURtTv9n8X/H+L/eTUbj/zaF+rf/y3oPXPF/rcrs/yaL /8uQFf4P//eaFf4vMRT+LzbU6xnE/2U4gfi/xFCV+b++w/9lCoX/y+z/pL3h/6JC4f/wf78z F9fyf/JPSfN/0gU0w0so/N/eJni+/5Os8H/4v1nJ7/9UPxXzf2rN/434v03+r6nS/416yf+1 rRsSZPZ/5gP8nyyowv+9hnrxf7fH3aX8XyPTjfi/z/F/2lzK/wXIUZn/Gwv6v25WHev/Dlmf uuz/7t3FEv5vNptwsP+Tvy/i/6Qjjf9T+L95UseFwv/h/1ZCPSU1HzLX4v+0dCp074+0L9Tz MWr1f4PB/2XJ6tn/tbdPR/zfYPaG0nZopt/q9jPafoD/kyn92vyfv17wfwuLVM1Tdbr/6wc3 JMX/Uc4ud/83HBgjzv+14v+GH4X/O764qxz/Fz/vjf9Lzwr/l9CtKOT/3OuQFf8nba6A/5PV COz/t6VZnO7/hlbh/7aFOt//GYX/Ww6F/7tX+L81/6c7/F9qqPr8nxnxf/i/9ROI/0sMhf9L yAr/lxgK/xeZFv7vXuH/Ptv/hXTwf3v9n5WJb/zfH/5PTxXu/+dWs+P/4rJ6mk/oGvzf1/i/ 1f3/8vs/W8z/deYT9v8LCxXD0u0a/J+ZhjG3/+s+Yf8//N82/9eM1/J/g6++0v+5bkyF/k9d a/8//B/+D/+H/2vnFf5P4f/+CLWSFf5vI8rD/+Xzf2ryQz3d+AfVzlBPx/gM/ycDq0T/J6fh g/b/C+NtkxJKugn36nT/Z8ahb7z/s93eUA7+jb+Vwv/h/872f+Z8/6fxf5RPKHf/Nx4YI87/ dd7/9fpH4f+OL+4qx//Fz3vj/9Kzwv8ldCtK+T+16v9ktXsJ/zeF1bYF/J+Vr2LG/+30f9a9 0cT/bQp1vv/zM885/Z9b1YH/S84K//cN/o/9//B//rfY/0/h/7aeQPxfYij8X0JW+L/EUPi/ yLTwf/cK//fR/m8I++rg//b6P7kPJfq/YV5ps+L/5qubd/u/1wW+pfzf0F5r/z95LYL/+/d8 Avv/pfq/0V7I/5nWn2AzhcXYO/1fO6vW/J8d/GvMYegTnvhGJgiMHKMzV/J/g8m+/989q7cP C/+X6v/c3SKr/3NjfPxfXFb4v6z+7wP2/2vd3WKcenkA7PN/2reHUPk1jxX6P4v/w//5zwj/ h//bGgr/h/9bC7WSFf7vH8Pu8/3frVNmHtXO/f+ejvEIVZf/sw3+L0tWL/7POjLl/J98SHv9 n/2tZqHwf/i/haxe/F83VLn/n385hv+jnF3u/m86MEac/+vF/7U/Cv93fHFXOf4vft4b/5ee Ff4voVtRyP+16/v/FfN/rUzU4v82NIvT/Z+ba8X/bQp1vv9rFP5vORT+717V4v+sv4Rz+r9x wv+lhqrP/7H/356s8H+Zxwf4v8QTWMr/mQH/lykU/g//93wG8X/poS7j/6QN4P+2eIpF/3df A5vP/5muRv/X9sX8n9bn7/833rOWn8b/4f/UEf5P67aY/1On+z81FvN/avSt3Jg2EJldT/zw 8Uvz/Qj/51c5ZfV/uln0f7c7UW7/p9n/72v838X2/5OFyrX5v8HfZ3P6P9e7xf/FhML/+Vjh Xeu+vsXrZ4X/U3ED1HZe4f/wfy/HeA81T+uwUPg//N9aqJWs8H//GHZ/gP+T5ZxaZmN2+r+n Y7he7uf4P7M/1K//k5HIYPB/WbJ68X9muHXHdNv2k9kb6tZlcJNHoVLs/3ec//MLCirzf3Xu /9f5Q+D/KGeX4P/skdYuzv9Z7/9uP67wf8cXd5Xj/+LnvfF/6Vnh/xK6FRfyfyYYI/zfF/i/ cfBvKKb9dwvt9xC8Vz4U/i8y1NLdooT/myz+L0NW+D/832tW+L/EUPi/2FCvZxD/l+EE4v8S Q1Xm/9j/D//3j1D4v5QPC/+XHgr/t72xX9v/9Tn8XzBl4XaB/4u9336e/wtLzPF//55P6Br8 39fs/7fq//rs/q+t0v+NVfq/dlj0f9pm93/uxRz+L+YELoRi/7/IE7jR//leGf7vfernNP/n Pquz/Z/J7v8M/g//53+0mVcX83/a54H/W3iItPMK/6fwf3+EWskK/7cR5eH/8vk/NUgHffAP /J2hno7hu5z4v/dQ+L9F/9dM3eD9X9PtDXXrMrg+cajUZ/g/K1Motfk/P9CuzP/psUL/1/oh Kf6Pcna5+z99YIw4/zeI/7M/Cv93fHFXOf4vft4b/5eeFf4voVtRyv81H+D/2rDaFv/3Z7M4 2/8NHf7va/yftLmc/m/s8H8ZssL/4f9es8L/JYYq5P/cNg74v9hQ+L/M4wP8X+IJxP8lhsL/ vYXC/+H/8H/Loc73f3Jc/N8WT7Hs/+Sfkub/wvJK/N+X+T+3bHnF/7Uha/lp/B/+Tx3h/z5i /z/83zb/9wn7//k1kSX8322sh/+7sP8b9bX8n29z3+n/vL7C/8U1i7ceE/4v6gTi//B/S5cw /g//tzUU/g//txZqJSv83z+G3Z/g/6RXNvge7V7/Nz/GI1Rd/q8b8X9Zsnrxf52+DVBv/z9M Z+31f/a3Uh/h/wL8w//9NRKp0/813en+r3eXOP6Pcna5+z9zYIwo/9c14v/0j8L/HV/cVY7/ i5/3xv+lZ4X/S+hWFPJ/pvsA/3d/ZVzC/8nIAP+30/+Nbi0b/m9TKPzfW1b4P/wf/m8xK/xf Yij8X2yo1zOI/8twAvF/iaHwfwlZ4f8SQ13K/0kTxf9FhcL/4f9+p1Qv5f+6HPv/hRvAX/6v eUTE/603wXY83//Jty3j//6YT3ADR/xf1Gd13v5/tkb/19o1/9d65KBbaew7/V+4B96/e/1C /q93T6i8/s+t9znd/w1ygvF/f/g/dw/E/0Vlhf/L6v+0uZT/6+UST/N/oSP9Of5vCEsyQhdk X9/i9bM63f+Fp3sJ/9dIyy7h/+6boh/v/3q5GMr4P1lMV8L/hR50kv+bH0Mp/J/C//0RaiUr /N9GlIf/y+j/rORhU+6BT8d4hKrL/7H/X/rbxkX/1/V+/78wq7XX/5nfyv/k6f7PTDIyrcz/ +SsJ/7cw7H7yf26eHf8XFwr/V2m5+7/2wBhx/k+L/2t/FP7v+OKucvxf/Lw3/i89K/xfQrei kP/T4wf4v2CM8H9f4P/cKcP/bQp1vv8bVGb/515d4f+Ss8L/fYP/swb/lxqqPv93663g//B/ qycQ/5cYCv+XkBX+LzEU/i8yLfzfvcL/4f/wf+qP5ZXhBjC8hML/7WqCn7D/nx1C1vLT+D/8 n8L//auxn+T/1vf/E//XdOERmeT//DFaeyX/Z4ZG/F8CHppar4ZC9Rn+L7wmq8v/Te4Qef2f GfB/kVl9nv/z99as/k8b9v+LCvXi/xwiX/Z/T3wt0f/9ZrXo/8LWuDn9X7vq/6RzVsL/yZ7d RfyfPDrL+D9JoYj/kz5LCf8ndyT834KnwP/5Cv+3NdRKVvi/jSgP/5fT/7XScRmm/aGejqF+ d8qry/+1Fv+XJasX/3frZ1vv/0y3N5S21g0xQqU+Yv8/I6tT8X9/jUTwf/g/Ocjr+Opst0TJ U+7+rzswRpz/M+L/+h+F/zu+uKsc/xc/743/S88K/5fQrSjl/8z5/i8MrfB/G5rF2f5vcisF 8H+bQuH/3rLC/+H/vsb/sf8f/s//Fv5P4f+2nkD8X2KoM/2fHV0Lzer/dIP/yxQK/4f/ez6D +L/0UFfxf2HRCP5vi6dY9n+hB+MXEe/0f6EvbcxLqFf/Nz6q3f7PzquC/s+aCv2fmyle8X9h bTn+75/zCV2D/0vzf/1Uo/9Tn+P/dMrSIhueDv09VIX+7zaYW/R/Lgb+bzlU/f5PNyP+LzKr s/yfNuX8n5sRvMz+f9p2uf2fb+xX8n8iGor4Pz07gQf7P0mhiP+TS7yI/5vNJhzr/4LwqNT/ yQWV5v/GZ9GD/8P/rYVayQr/txHl4f8y+r+x8X8c+4R+4NMxavV/mv3/jvF/7TA5/9eG2bmd /k//Vgr/h/872f+5efaz/d/khqRZ/Z8Lhf+jRJa7/+sPjBHn/1rxf8OPwv8dX9xVjv+Ln/fG /6Vnhf9L6FYU8n/uRfey/5MJ0CL+T3pP+L8NzeJ0/zfh/xL937yh5gq14v96hf9bDoX/u1f4 P/zfwo/h/1b8n5tewv/FhsL/ZR4f4P8ST+Dy/n9+oWxW/2cG/F+mUPg//N/zGcT/pYfC/21v 7Pg/hf9bCHWB/f/+4f/6kLX8NP5veT6B/f8S/Z/WbY3+z5bzf2Mx/+ca+7L/CwuqqvJ/esju /9wGiqf7vydmU43/c6Me/N9iqE3+Tzcy3Yj/w//N/N/Q4P/S/N8oL2fxf3v9372fWML/2UeF //t332LR/0kKUu29B86PoRT+T+H//gi1khX+byPKw/9l9H+hzQ1jQqinY/jJhAr931011uX/ zHC6/2tG4/2f2R1KW+tmfELl/lrj/7Jkhf/D/z0qN2+B/6NElrv/swfGiPN/nfd/vf5R+L/j i7vK8X/x8974v/Ss8H8J3YpC/u/WRz7d/5lgjDL6P7vm/3pZioH/2+f/dNPj/y7s/waD/8uQ Ff4P//eaFf4vMRT7/8WGej2D+L8MJxD/lxgK/5eQFf4vMRT+LzIt/N+9wv99tP8LVxH+b4un WPR/rUx8p/k/6QL+6f9CpxP/9+8m2I6l/J93Ssv+z4Ss5afxf8vzCez/h/872f9JC1RvRfyf nu6b2iT5v99FOBX6v3ZY9H+tW2qW1//ds3r/sAr6v0E+pKr8n20ajf/beF3V5//8V1ji/+Ka xVuPqZD/s6v+b35j+jb/p1b9n/TEivi/ZnYCj/V/obkV8X9yO67M/4Udnor4PxnO4//wf/Ok jguF/8P/rYR6Smo+ZK7G/9nQf5mG/aGejuF6uTX6P9vU6P9mKO8k/9e2w+D8n7Hd3lDaWjfa CdUs1In+L8C/2vyfTPXg/xYWqT75P4v/w/9RfLn7v+HAGHH+rxf/1/4o/N/xxV3l+L/4eW/8 X3pW+L+EbsWV/J/8dpH9//B/af7P3/Dwf5tCne//ZP0D+//h/57K04/h//B/Cz+G/1vxf+6b 7fF/saHwf5nHB/i/xBOI/0sMhf97C4X/w//h/5ZDne//Qjr4vy/wf71+VLv937zbPgt1uP/r bIX+T6/v/3dXj/LT+D/8nzrC/6nRFvN/qkb/F3agVG8F/7fWArf5v0Fn3/9Pj/i/Q/xfP7lD 5PV/bY//i8wK/5fV/7nP6lz/Z4cuu/9T+D/8n//RZl5dy//1sqwZ/7fwEGnmFf5P4f/+CLWS Ff5vI8rD/+Xzf7d+9Pio9oV6Pob7yRr939jh/7Jk9eL/bNvl9n9GW/xflqze/J8sZcL/LSxS ffJ/5+//Z212/+dC4f8okeXu/8YDY8T5Pyv+r/9R+L/ji7vK8X/x8974v/Ss8H8J3YpC/s90 a/7vkOtq2f/JNBn+b0OzONv/Na43iv/bFGrF/7UHhFr2f1rWP7D/H/7vqTz9GP5vzf9Zg/9L DYX/e4+F/8P/4f9WQ1Xm/+YoD/+H/3sJda7/8wfG/0WFwv99p/8bZiv28H9/eIp/+T+P8hL9 3xvKe93/bxYK/7feBD9h/7/+jiDkp/F/+D9Vrf8z2f1fW+P+f26WZNn/hRdzVfm/cbDZ/Z/5 AP8XZv1L+D+Zvi3i/7oht/+72v5//pTh/96nfp79n73S/n92tAX9331duD/N1fg/GUyV8H92 mp3Ag/2ftMAi/k/uQvi/3f5PTE0J/xd60En+b34MpfB/Cv/3R6iVrPB/G1Ee/i+f/1ODnxi+ dZLa/aGejqHY/w//F+H/Rjed5fyffEh7/Z/9rWah8H/4v4Ws8H/7/J9bqI//o0SWu/+bDowR 5/8G8X/Dj8L/HV/cVY7/i5/3xv+lZ4X/S+hWnO7/WulPlPB/8k/B/21oFmf7P93j//B/+L+0 rPB/2f1fKy+B7tVO/zfNq4Dy8H8pzeJk/zfq3P7PhcL/xYbC/2UeH+D/Ek8g/i8xFP7vLdS3 +b/J54D/iwqF/8P//d7aL+X/pvZR7fV/0pDuVTeevv9f24Xl4dn83/wEHu3/tD7f/8la4sr8 36hz+z/1MGVX8H/yzTv3aq//62fVPKsL+L/JJ9nqcFp3+r/53cLtKbfk/8xgxke194kfTsn4 2wIv4/+ayTTi//r97yqm1r+bCtWtheH/vsb/WYP/i8zqLP/nXC3+Lyqrbf6vtW755TjaJP/n l3CGyt8DV/zf/MaE/4v3f08n8Fj/J+mU8X+z7uLR/m96VLv9Xzuv1vyf7Yr5P2PK+T/2/8P/ 4f/wf6uhnpKaD5nr8X/htbOv9vq/+TEeoeryf4PB/2XJ6tn/NWN3e7rrttVP/cBY/+c+4VAp 9v87zP8J/KvN/7U2t/+bPfDP8n9t7y7xrP7PjYXxf5TIEvzfcKS1i/J/feP9X6d/FP7v+OKu cvxf/Lw3/i89K/xfQreikP9zr4SX/Z9cREX8n/x2Gf/nU8D/bVlhvuj/Jq3wf9tCrfi/I5DI sv9rJpXZ/3Uj/i9DVvi/7P7PyGryLmlZzNMXcupxwv+lhjrb/9k2t/+7tTD8H/5v9QTi/xJD 4f8SssL/JYbC/0Wmhf+7V/i/z/Z/4b0p/u9z/F9rT/d/RiZTc+7/dxs41uf/3ML5Ff8X1pZX 5f/y7//X2mv5v/Cd4vn8n1tadCH/N/a5/Z+bulje/8+G94yByO964tvwILL3UMv+L2Rdwv/5 FwxZ/Z9uFvyfmmzfif8zSf6vf1T+izlP939hyzT83x/+T09X8n9N2KTtK/2fKrj/n8L/4f/8 udjm/+Qbaor4v6Hc/n/hbVoR/xcWaJXwf2FQVMD/yTeR4P8WHiLNvML/KfzfH6FWssL/bUR5 +L+M/m+a3INVy7B7Z6inY/jebYX+776rIf4vp/9TUz9O+vagMt24O9Rt4G6b38r/5On+z0wy 4VqX/7P+NXBt/k+b3P7Pf3NWdf7PvX7B/1Eiy93/6QNjxPk/Lf6v/VH4v+OLu8rxf/Hz3vi/ 9KzwfwndilL+z3yA/5vCK2P835/N4mz/Z3r83/f4v0Fl9n/u5Sn+Lzkr/B/+7zUr/F9iKPxf bKjXM4j/y3AC8X+JofB/CVnh/xJD4f8i08L/3Sv8H/4P/6f+PSm91f+FoQH+799N8CP2/5Pj 4v/wf7PSy1rijP7Pb7NVyP/ZGv1faIHqreD/1lrgFv/nljOY3P7vntX7h4X/S/N/o+u/5PV/ bY//i8wK/1eX/xua3rXy2+lrQtd9l/+TjokO3wiM/8P/yUGaeXUx/zfg//B/+L8soVaywv9t RHn4v4z+b5CemFR79/+bH8P3Ayv0f3fViP/L6f/0rQyt83+NTGft9H9uhUGo3F9r/F+WrK7h /5rs+/+1tqnQ/3X4P0p8ufs/c2CMOP9nxP/1Pwr/d3xxVzn+L37eG/+XnhX+L6FbUcj/uaHV iv874rpa9n/yT8H/bWgWZ/s/36PF/20KteL/mgyhmpdQK/7PrzvE/214R4H/Sw+F/8P/vTWL 6vyfm17C/8WGwv9lHh/g/xJP4LL/86cM/7clFP7vLdS3+T9ZcIb/iwqF//tS/xdW7OH/9vq/ gF7S/F+4Kv/wf2FZM/7vjybYjuf7v14uLPzfv/1f2H0N/7fb/92uq9P3/2vCfGg+/6eq3P9v XPV/YTpBJv+/zP+1w6L/uzXA3P7Pf4v52f4vOKa6/F/+/f/8JXwd/6cbj17wf+9TP/i/rP7P rPq/OUzG/8X7Pzu/sx/r/+TRWcb/SUeiiP+TUCX8n4yvSvg/LQvni/i/+2SCO8jee+D8GErh /xT+749QK1nh/zaiPPxfRv9nO39cm3IPfDqGGzbW6P/uWeH/8vq/rrn1kW4PqsHuDqVtNzS/ 1e1ntP0A/ycTFpX5P/8Cqzr/1+T2f3Xu/4f/o+wod//XHhgjzv+14v+GH4X/O764qxz/Fz/v jf9Lzwr/l9CtKOX/1Jr/kzcGRfxfMEb4P/zfU8H/Jfo/Wf+Q0f91I/4vQ1b4v/z+L7x6z+j/ rMH/pYaqz/+x/9+erPB/mccH+L/EE1jK/5kB/5cpFP4P//d8BvF/6aHwf9sbO/5PFfJ/8kf8 399NsJD/0+Oa/wujRPzfv/0f+/99kf9b2/+vDasxvtL/fcb+f9/s/1b2/5t6g//7Gv/nOoL4 v8VQG/3f4Kvv9H+qSv/nPqtT/Z+VJZyl9v/7Zv9n1/yfpFPE//XDLOKx/i8MH0r4vyY09gL+ T4f+Nv7v774F+//h/1ZC4f/wfyuhnpKaD5nr8X/W31vt1O4P9XQMmVDF/8WNr5avqyv4v9EO k3tQWdvtDaWtH+2ESuH/8H9n+z9Tpf8b8X+U6HL3f92BMeL8X+/9X29+FP7v+OKucvxf/Lw3 /i89K/xfQreikP9rV/f/C+2hhP9rwytj/N+fzeJ0/+feouH/NoU63/8Zhf9bDoX/u1f4vzX/ x/5/+D//W/g/hf/begLxf4mhKvN/7Yj/yxQK/5fZ/8miW/xfVCj8H/7vd0r1Uv5vyOD/guD6 y/+18mNp/i98WMX9nzUV+j+1uv9foBv4vz/8X4P/S/N/t+uqQv9nP8f/6ZSlRXf/9/t11Sv+ L7gVmfyvwv8ZM2b3f/oT/F83VyJ7/Z+d/6vxfxX4P1kD+6X+r879/z7A/5mxSv9ns/u/Fv+H //OfUTuvVv2ffGUO/m/hIdLMK/yfwv/9EWolK/zfRpSH/8vo/waZpBv8ZOfOUE/HUJXu/2c6 /F+WrJ79nzHNqL3/C12lnf5P/1bqM/xfeKFZmf/zPWj838KwG/+H/6Mslbv/6w+MEef/rPi/ 7kfh/44v7irH/8XPe+P/0rPC/yV0K873f9KdL+H/htBvw//92SzO9n+dwf99j//zM8/4vw3v KPB/6aFq83/s/4f/87+F/1P4v60nEP+XGAr/l5AV/i8x1KX8n7xHx/9FhcL/4f9+p1Txf+4/ u/2fW9iB/0trgvi/uBN4lv9zA0f8X9Rn9eL/hraY/1OX3P8vn/9r7ZX83+3YVe7/V9D/Bfh3 vP+zjcsjr/8bNf4vMqvP83/jN/s/bWr0f6ZK/6fwf/g//xm182rV/zW+ZeP/Fh4izbzC/yn8 3x+hVrLC/21Eefi/jP7PWn+7Hfz88O79/2bHUJXu/2cb/F+WrF78X9v2/kHVD3ZvKG07N0sQ qlko/F9u/+eHHfi/hWE3/g//R1kqd/9nD4wR5/8G8X/2R+H/ji/uKsf/xc974//Ss8L/JXQr Svm/5gP8XzBG+L9v8H9a4f+2hfq3/8t6D1zxf43K7P/cy1P8X3JW+L9v8H9tj/9LDVWf/3Mr 2/B/saHwf5nHB/i/xBOI/0sMhf97C4X/w//h/5ZD4f9S0/oU/ze6c5Po/+7Vqv+7L2fxR9rp /97Wp9bn/8xQyv9ps+r/5IPB//3b/7UW/3eM/wvwr8T+fwH+faf/CwJVvZWS/i8sqKrJ/7Vu kUPF+/8NYUFnkv97vC2rzv/5jUmv5P8Gqb7R/2lTzv/ZS+3/p212//cB+/9NJrv/s2v+b5DB VAn/Z+cn8GD/Jw+nIv5PbsdF/J80N/zfbv9nHtVu/2fmFf5P4f/+CLWSFf5vI8rD/2X1fzI3 4rsgu/3f7Bj4P4X/2+7/Wic38H8rk9/NvML/HeP/zNTV6P/8etms/u/2JMf/UWLL3f8NB8aI 8n+2Ef+nfxT+7/jirnL8X/y8N/4vPSv8X0K3opD/M92a/5O1UUX83/3b/vB/fzaL0/3fiP/D /+H/0rLC/32D/2P/P/yf/y38n8L/bT2B+L/EUPi/hKzwf4mh8H+RaeH/7hX+D/+H/1N/LK/E /+H/NrRA/J+Kua7wf/i/pVBn7f/XmQv5PzN2tub9//B///Z/t5/E/0VmdYX9/wr6v/P3/xuG /Pv/1en/FP4P/+c/o3Ze4f+i74H4P6nwf1tDrWSF/9uI8vB/Gf3fICsKhk7vD/V0DPdAx/8t hMrh/7pHtdv/6Xl1uv8zw3D7bd2aKcX/WfdBh+r2M9ri/7Jkhf/b5//cknb8X1wo/F+l5e7/ xgNjxPk/Lf6v/VH4v+OLu8rxf/Hz3vi/9KzwfwndikL+z33N6On+bwjf24D/+7NZnO3/eveu Bf+3KdTZ/s/4tUtZ/d9g8H8ZssL/fYP/Gyf8X2oo/N97LPwf/g//txoK/5eQFf4vMdSl/J8c GP8XFQr/h//7nVK9lv+TCZs0/ydHxP99m//zJGrJ/+nwWgT/92//F3Zfw/99gf/TBv+X5P8+ Yv8/ySOn/1P94v5/bWOq9H9BieD//u3/dDNeyv+Jr6nN//XZ/V97pf3/jvB/ZtX/dbOqGv8n j84y/u/OBfy/61D/J69Nivi/eXfxYP93728f7//6yYcq4v+CQMX/4f/mSR0XCv+H/1sJ9ZTU fMhcjf+zk35Ue/f/mx9DJlTr83931Xiq/xsf1W7/Z+bV6f6vNW4KVbfd2Jq9obQd3d+FSuH/ DvR/fqBdl/+7fUa5/d+vFq7K/3Ud/o8SXe7+bzowRpz/M+L/+h+F/zu+uKsc/xc/743/S88K /5fQrSjl/8yq/5M2V8D/tU2gG/i/P5sF/i8yq0v7P1n/gP/D/z2Vpx/D/+H/Fn4M/7fi//yi BPxfZCj8X+bxAf4v8QSW8n+2x/9lCoX/y+z/5Ou+8X9RofB/+L/fKVX8n/sP/u/J/w0t/i8y 1FsLrM//sf/f9/g/tbr/nw3zod/o/4JAVW/lgP3/xjX/F27HNfk/Y/WY2//pi/k/G7L+Rv93 G6Dh/yKzwv9V5/9Mdv+3vv9fN6vwf/i/EKpK/ycTF/i/hYcI/s9X+L+toVaywv9tRHn4v5z+ T2ZjRPTs9X/zY7guU43+bzD4vyxZvez/Z5vO+b/eDgn+b+qn32oW6kz/J/fy2vxf6/ualfk/ k33/P7ekvT7/x/5/lB0l+L/xSGsX5/9a7/86+6Pwf8cXd5Xj/+LnvfF/6Vnh/xK6FYX8n3sd crr/kz42/m9Dszjb/1nfEPB/W0Kd7v/8mtys/s92+L8MWeH/8H+vWeH/EkPh/2JDvZ5B/F+G E4j/SwyF/0vICv+XGAr/F5kW/u9e4f/wf1X7v7BQ0T/rd/u/cAO4z02v+T8Jhf/7Av8XLlj8 37/9H/v/Jfo/0zTn7//XhvnQfP6vrdL/mSv5v8l9LSL+bznUh/m/26Cny+z/3J4Hl/J//v3d d/o/bar0f9qc7f/siP/D/13H/02P6lj/Z6Xvgf9beIjg/3yF/9saaiUr/N9GlIf/y+n/5All +2F/qKdjuF5ujf6P/f/S3zYu+b9J38bCzv+Zbm8oB//a38r9H+Z0/xfgX23+z7+txf8tLVJ9 8n8j/g//R/Hl7v/0gTHi/F8n+/81Pwr/d3xxVzn+L37eG/+XnhX+L6FbUcj/dev7/4kUKuD/ zBRW2+L//mwWp/u/Af+H/8P/pWWF//sG/2cN/i81VH3+z23jgP+LDYX/yzw+wP8lnsBS/q8d 8X+ZQuH/8H/PZxD/lx4K/7e9seP/FP5vIdSz/+vsiv+Tg+f0f4+sjvZ/nkTh/6Kywv9Vt/8f /i/R/4Wsa/J/7e2Ontv/3bN6/7Dwf5/m/5zCv5L/82fuS/2fqnP/vyr9n59qr8//2VX/J6Kh hP8Lm7UU8X+SQhH/J8/BIv4vDIrwf3/3LfB/+L+VUPg//N9KqKek5kPmevyfPGTsoPeHejqG +8ka/d9k8X9Zsnr2f63ubm3O+T8ZHuz1f+a38j+E/8uSFf4P//eo8H+UHeXu/8yBMeL8Xy/+ z/wo/N/xxV3l+L/4eW/8X3pW+L+EbsWF/F/bhH8K/u/PZoH/i8wK/5fT//UG/5chK/wf/u81 K/xfYij8X2yo1zOI/8twAvF/iaHwfwlZ4f8SQ+H/ItPC/90r/B/+D/+n/lheGW4A97npNf8X eoJJ/k/S+aD9//L7vw/Y/08FIof/w//NCv7v0v5v/AT/5/4pef2fWfZ/xmTf/898gP/r5QRX 5f9s0+jc/q/vruT/Gv9MrM7/uYWIef2f7i/k/3pbcP+/YG4K+L9xKrf/n+ygUsT/jfMTeKz/ k5F2Ef8ng54i/i88MUr4P8m6iP8L+9ni//B/86SOC4X/w/+thHpKaj5krsj/Sf9lSLgHPh1D Vbr/32Dwf1myevV/bkLJ+b/QVdrp//RvdfsZbfF/WbJ69X8C//B/S4tU8X/4P8pCufu/9sAY cf7Piv/rfhT+7/jirnL8X/y8N/4vPSv8X0K3opD/c6vZT/d/XXg7XcD/hVeZ+L+d/m9o8X8X 9n/s/4f/Ww1Vm/8bWvxfaqj6/J9bRIf/iw2F/8s8PsD/JZ5A/F9iKPzfWyj8H/4P/7ccCv+X mhb+7y0r/F8x/6fX9v9Tk2SN//u3/2st/i/N/40T/i8y1LP/Gz9h/78wnSDPki/zf2Za9H/m dmZz+78R//c1/u9a+//h/z7P/7nPCv+XNpY73f9Z/8Hg/zasTz3d/4WeGP4P/4f/w/+9NAv8 H/7vPas1/2cS+oFPx3iEqsv/jR3+L0tWL/7PmFsvXbd9P5m9obSduum3moXC/+H/FrI63v+Z rkb/13X4P0p0ufu/7sAYcf5vEP9nfxT+7/jirnL8X/y8N/4vPSv8X0K3opT/az7A/0kfG/+3 oVmc7v8m/N+F/R/7/+H/VkPV5v86i/9LDVWf/2P/vz1Z4f8yjw/wf4knEP+XGAr/9xbqy/yf 1X4Ehv+LCoX/w//9Tqley//J3/fu3Oz1f2HyPFRuP6V/+j8/U5To/16zwv9l9n+SAv4P/zcr B/g/a0r5P23W/J/cuHL6P91XuP+fe690Gf9nBvcwzOv/7lm9f1gl/Z98Vvg//N8M9MjeV/i/ hamfZ/83XMr/9U05//e7Ltz/Yaf/k2uzvP+zq/5PBlNF/F83qw72f/LBFPB/agqNvYT/C/3E 4/1fP/oTWMT/Se+2iP8b5Smd5P/mx1AK/6fwf3+EWskK/7cR5eH/cvo/6ZwN/vm61//Nj/HY Ka8u/2ebGv2fm7s91f+ZoesmNygYZXiwy/8N2n3eoZqFwv/h/xayevV/bZPb/7m527P9n19z m9X/mXHE/1Fiy93/9QfGiPJ/t//b+z/9o/B/xxd3leP/4ue98X/pWZ3q/0LnCf/3b//nvizh dP8nvSf834Zmcbb/G12zqdD/zVtPPf7PLyDB/214R4H/Sw9Vm/9j/z/8n/8t/J/C/209gfi/ xFCV+b/J4P8yhcL/4f+ezyD+Lz0U/m97Y8f/KfzfQqjT/F/flfJ/bhHOsv8bw9py/N9rKPwf /m+pBZ7k/0ILVG+l6P5/wa3I5H8d/m80Jrf/6z5i/z/8H/5vwf/5p8d3+j9tqvR/2pzt/wbT 5fZ/vrHX5//UtfzfIetTz/d/06PC//27b7G8/1/7qHbv/9fOK/yfwv/9EWolK/zfRpSH/8vo /0aZWfNr6vaGejqGGzbW6P/uqhH/l9n/uZUjzv81u0M5+Nf8Vref0Rb/lyUr/N8+//erhc/z f11nc/s/Fwr/R4ksd/9nD4wR5/+0+L/2R+H/ji/uKsf/xc974//Ss8L/JXQrCvk/PX6A/7OB buD//mwW+L/IrPB/+L8N7yjwf+mh8H/4v7dmUZ3/cyvb8H+xofB/mccH+L/EE4j/SwyF/3sL hf/D/+H/lkPh/1LTqtH/NTX6v85WuP/fP/yfHBf/h/+blQP839AW839NV8z/zT6rp1C17v9X of+bxo79/y7s//oO/xeZ1Wn+b1zzf77HlNX/tQP+LypUrP+T5BL93+9baPxf5AnE/+H/tvQt 8H/4v5VQ+D/830qop6TmQ+Zq/J+VPru10/5QT8eo1f+N3fn+L3yFUkb/p9uz/d80jYMbFAxP /cBI/9e4XleoZqHwf/i/hazwfzv9n8X/UaLL3f8NB8aI839G/F//o/B/xxd3leP/4ue98X/p WeH/EroVpfyfOd//hdnMnP6vXfN/0v3E/21ZYb7o/9zrkAr9X7jEK/N/sv4ho/+zHf4vQ1b4 P/zfa1b4v8RQ7P8XG+r1DOL/MpxA/F9iqDP9n/Xv4LL6v27E/2UKhf/D/z2fQfxfeqjL+D9Z nof/2+Iplv2f/An/94f/K7j/3yOro/2fWzi/7P9C1vg//N+sfLX/U105/2eL+b/P2P8vnOCw dLsK/2f77P6P/f8O838uD/b/Wwy1zf81/pR9qf9b3f/vq/2f6c72f+1ocvs/dw/E/yV+Vhfy fzo8B/F/3+D/Zqubd/u/1x1S8H8K//evUCtZ4f82ojz8X07/J08o6ydU9/q/+TEeO+Xh//B/ C1m9+L/e9S2c/wuzczv9n/2tZqHwf/i/hazwf/v8n5u3wP9RIsvd/40Hxojzf634v+FH4f+O L+4qx//Fz3vj/9KzOtX/hTXb+L9/+z/3Svh0/3dfbZvP/1n83zH+b+rxf9/j//y6w5z+bxzx fxmywv99g//rLP4vNRT+7z0W/g//h/9bDVWZ/2vZ/y/5KYL/Sz6B+L9cofB/+L/fKVX8n/sP /m/u/0zTXGr/P/zfJv8Xdl/D/+31f+66wv/FhTpr/79L+b+2sWP2/f8s/u9r/N+o8X+RWV3B /7kZwcvs/3eE/zP4P/yf/9FmXuH/8H9vx1AK/6fwf3+EWskK/7cR5eH/Mvq/8NrZ+pmSnaGe jvGwLyf6PyO9sjT/Jz3ou/+7q0b8X1b/1zb97RDO//VmbygH/7rf6vYz2uL/smSF/9vn/9wX Fdbn/xT7/1Hiy93/TQfGiPN/nfd/Vv8o/N/xxV3l+L/4eW/8X3pW+L+EbsWV/J8OdCOf/1Or /k9GBvi/3f6vU/i/baHwf29Z4f/wf1/j/9j/D//nfwv/p/B/W08g/i8xFP4vISv8X2KoS/k/ eemC/4sKhf/7Tv8Xlpbj/7Z4ikX/d1++kOL/guC6V92a/5se1W7/97rA9/T9/8Ki0a/0f27h /LL/6+WDwf/h/2al4P5/nayQzuj/brfs0/3fpLP7v3HV//m1eoGv7fV/cm0O1/N/Zpyy7//X Nvi/r/F/7Xgt/+ff3+H/3qd+ruz/Bpvd/11t/z8RDSX8n3wZTm3+r5l1F4/2f2FQhP/7u2+x 7P+GR7Xb/w3zCv+n8H9/hFrJCv+3EeXh/3L6PxkyW7/+ca//mx/D9XJr9H/s/5f+tnFp/7+x vfV+nf8LE4E7/Z/5rRT+D/8X5f+sze3/3NTjyf6v7brc/s+NhfF/lMgS/N90pLWL83+97P9n fhT+7/jirnL8X/y8N/4vPatz/V94nYv/ex1aPfu/5gP8Xy+DKfzfx/s/07jrCv+3KdT5/s+d 4Kz+b7D4vwxZ4f/wf69Z4f8SQ+H/YkO9nkH8X4YTiP9LDFWZ/1M9/i9TKPwf/u/5DOL/0kPh /7Y3dvyfq/B/r6Hwf/i/hVBP/q+1+L80/9cPpfxfyf3/1Cfs/5fd/41V+j9lFv3fZLL7P/8t 5vi/uGZxlv+zPf4vMqvT/N+I/zvE/xk71uj/ph7/h//D/0WEwv8dEQr/h/9bC7WSFf7v38Pu s/2fldGOVDtDPR3jo/yf73Im+r/+WTXW5f9mKO8s/zca6/2fjKn2+j/9Wyn8H/4vzv9l3/8P /4f/o4Ry93/6wBhx/s+K/+t+FP7v+OKucvxf/Lw3/i89K/xfQreikP8zY3e+/7uvts3n/+ya /+vni33wf/H+z01p4v82harQ/9kO/5chK/wf/u81K/xfYqhC/s9NL+H/YkPh/zKPD/B/iSeQ /f8SQ+H/3kJ9mf/r5ZUd/i8qFP4P//c7pXop/9fJNZ7m/8INYAqHXPN/MjeU5v/C/NHvNFOF /k/rUv7Pzamu+D8ZLuP/8H+zcoD/G7ti/u+R1fN96bv9X8H9/+r0f71d9H/WNtn3/7PX8n+d NLev9H/aGvxfZFbb/F/XDyqv/3N7iZTyf/ZK/q/VTW7/5xv7lfyfNL0i/k9OIP5vt/+TOz/+ D/+H/8P/vTQL/B/+7z2rV/83NPL+pU8I9XQMN+7G/y2Ewv8t+r9+unUyvf/bHcrBv+a3Uvg/ /N/J/s/PnJ3s/3qb2/+5UPg/SmS5+z9zYIw4/zeI/7M/Cv93fHFXOf4vft4b/5ee1bn+Lywg wf+9Dq2e/Z/5AP/Xhe9tyOf/FP4P/ye//VTh/9L8H/v/4f9WQ+H/8H9vzQL/9xYL/4f/w/+t hsL/JWSF/0sMhf+LTAv/d6/wfx/t/8JKWPzfFk+B/4tqF0/+zzRNhf5Pr+//h//D/1W2/5+t 0v8V3P/PXMj/tZ3O7v+utv9fL/fWr/R/t5/E/0VmdZb/0x3+7yD/Z/F/+D/8X8Ql3M6rVf8n Ny7838JDBP/nK/zf1lArWeH/NqI8/F9G/2dlRYFtE0I9HeMRqi7/dxc9Z/q/MNqpyf+17XQb BOP/FkN9nP+zfqyM/1tapHoB/2fxf5Tocvd/7YExYvyfdf+71rozPwr/d3xxVzn+L37eG/+X nhX+L6FbUcj/aXu+/9NTeDuN//uzWZzt/7RbA4b/2xTqfP/nDo7/2/KOAv+XHqo2/9cP+L/U UPi/91j4P/wf/m81FP4vISv8X2KoS/k/WbaE/4sKhf/D//1OqV7L/8k/Jcn/hb70n/4v9AST /J+kw/5/B/u/MJOM/8P/zcp37/9Xpf8LLVC9FfzfWgvctv/faExu/9d9gv8LHxL+7w//Z4Zr +T//3P1O/8f+f1/k/+ya/wvmpjL/14toKOH/enlYl/B/YXhQxP/Jc7CE/9Ohv13A/8n1WsL/ qRH/h//D/yU3C/wf/u89q1f/10/+dpzk/56O4X6yRv83GPxflqxe9v8brO0r9H+y8UF1/s93 APF/S4tU8X/4P8pCufu/7sAYcf5Pi//rfhT+7/jirnL8X/y8N/4vPatz/d8RS4kr9H/N+f7P yNgV/7ehWZzt/0yD//se/+f+Pqv/sx3+L0NW+L9v8H9jh/9LDVWf/3PTS/i/2FD4v8zjA/xf 4gks5f/6Cf+XKRT+D//3fAbxf+mhLuP/wntT/N9e/yfrUxP9nxzx7v+aNf83Pard/u91gW+F +/+1Yyn/50kU/i8qqyf/F3Zfw//t9X9G6yv5v0nn9n/r+//5RYSmkU7cXv83zKpP8H/a95uz +j9tFv1fP9bp/wI5wP/h/2agp/Hbxn+p/1vd/8/6RaNZ/V+75v9MWBaY4v/mx5DP6lz/Z4Yu t/9z90D8X+Jnhf9TUb3bz/N/I/4P/4f/yxJqJSv830aUh//L6P+s9MTS9v+bH+MRqi7/1434 vyxZvfi/vums93/a7A2lh8Z1GkKl8H/4vzj/Z3P7Pzf1eLb/67rc/s+NhfF/lMhy93/9gTHi /J8R/2d/FP7v+OKucvxf/Lw3/i89K/xfQreikP9T3Qf4v/tqW/zfn83ifP9nFf5vW6jT/Z+f 0sT/bXlHgf9LD4X/w/+9NYvq/B/7/+3JCv+XeXyA/0s8gaX832jxf5lC4f/wf89nEP+XHgr/ t72xX9v/WZmwSfJ/ooL+9H/zkdhu//f6YVW4/58x5/s/aRb4v/dQ+L8i+/+10sPM6f9UOf9n i+3/h/87yv91TW7/d8/q/cMq6P+s/FPwf3/4v1Ffyf/pxp8y/N/71M9G/9dm8H/zY8hnhf+L 60i38+oT/J8MQYr4v/vkpK+O9X+HrE9d9n9hrruE/wsXUQn/J09h/N/CQwT/5yv839ZQK1nh /zaiPPxfTv8nwwOp9vq/+TEeoeryf63F/2XJ6tX/6dshboMCO+4O5eBf/1u5e475AP8n3bHK /J+/GKrzf1Xu/4f/o3xEufs/e2CMOP/Xev/XNz8K/3d8cVc5/i9+3hv/l54V/i+hW1HI/xnz Af5vCHQD//dnszjd/7kTiP/bFOp8/+d+G/+35R0F/i89VG3+rx/wf6mh8H/vsfB/+D/832qo yvzf0OD/MoXC/+H/ns8g/i891GX8n8ze4v+2eAr8X1S7uID/0wb/l+T/Wov/O2j/P1n78KX+ r+uK+b9xzf/5qXjT6JSlRQGLSeUa+3X839h02ff/Mx/g/+7MBv/3HOrV//XdpfyfMVJ9o/9T 4yf4P/uodvs/O6/O93+6cSd4tKM8jHf6v358VP/yf+OsOtL/3Z6J2f2fXfF/cl0V8n9hKOd/ 7OD9/6S5FfF/s+7i0f4vDIoK+D95NFbm/3SjH9XOe+DTMZTC/yn83x+hVrLC/21Eefi/jP6v 9xtp357xCf3Ap2PIABX/Fze+Wr6uruD/Bqu193+D2RvKwb/ut/Ij+NP9X4B/+L+/RiL4P/yf HOR1fHW2W6LkKXf/NxwYI87/deL/zI/C/x1f3FWO/4uf98b/pWeF/0voVhTyf9p+gP/rZTCF //sC/+dW0eH/NoU63//5BSQ5/d844v8yZIX/w/+9ZoX/SwyF/4sN9XoG8X8ZTiD+LzFUZf5v GvB/mULh/zL7P+ubNv4vKhT+D//3O6V6Kf8XVmOU8H+hv57m/8IC398PC//3Fmq7/1Pr+//J cBn/92//x/5/X+T/bJX+b3X/P/xfiv9rG53f/43X8n8CUr7U/11s/z/8H/7vzf81jd//zw5J +//JaQ+vU/B/+D/8X63+r31Uu/3f7BhK4f8U/u+PUCtZ4f82ojz8X0b/Z+UhYlP6gU/HeEi5 uvxfN+L/smT14v+m/tYldf5P+tt7/Z/5rdwkncX/ZckK/7fP//lvzsL/pY2vznZLlDzl7v/G A2PE+b9e/F/3o/B/xxd3leP/4ue98X/pWeH/EroVp/s/mQAt4v/uq23xf382i7P9n38Rjv/b FGrF/80baq5QK/7PZZXV/w0W/5chK/zfN/i/scP/pYbC/73Hwv/h//B/q6HwfwlZ4f8SQ13K /8kbZ/xfVCj835f6P1kshv/b4imW9/8La2CT/J908ar2f7eBYyn/17bn7/8XRon4v3/7P/b/ S/R/7ro63//JNBP+b6//CwuqSvi/Qea/M/o/ZRf3/xvasUr/d//WPzkHO/3f64u5Cv3f1fb/ Gx/V1/k/s+b//AuErP5P92v+b3xUu/3fOK/wfwf5P93m9n+uI43/i8vqyv7P9v7v8X/vwwP8 n1T4v62hVrLC/21Eefi/jP6vl1u69bfYvfv/zY/xkHJ1+b/B4P+yZPXi/+zUTN7/yYe01//p 30rh/47zf34OCv+3MOxm/z/8H2Wp3P3fdGCMOP9nxf/ZH4X/O764qxz/Fz/vjf9Lzwr/l9Ct KOX/mlX/J5PRJfxfF763Af/3Z7M43f+5F3b4v02hKvR/vcH/ZcgK//cN/q/t8X+poerzf256 Cf8XGwr/l3l8gP9LPIGl/N/Q4P8yhcL/4f+ezyD+Lz0U/m97Y8f/uV8v4P/mI7Hd/u/1wyrl /9qmQv+nVvf/w//h/4r4v37A/0WGOs3/NRfyf3qYbJX+b5DbLf7v3/5PNyP+LzIr/B/+7/3V 8Iv/M/g//J//0WZe4f/wf2/HUAr/p/B/f4RayQr/txHl4f8y+r9Jpsmk2hnq6RiPUHX5P/eF amf7P5k1lmq3/2vn1en+T9/66o34v92hHPxrfiuF/8P/4f8O8H+mw/9Roov4v6k50trF+b/B +78W/1ekuKsc/xc/743/S88K/5fQrTjd/x1yXS37vz68ncb//dkszvd/WuH/toVa8X/tAaGW /V/vHk5Z/Z9m/z/831qo2vyfNfi/1FD1+T/2/9uTFf4v8/gA/5d4AvF/iaHwf2+hvs3/SXvD /0WFwv/h/36nVK/l/+Sfkub/JEbV/q8fKvR/enX/PytZ4f/wf7PC/n+f5//GD9j/L7yYq8j/ qbFr8H/4P/wf/g//h//7Y9Ut/g//h//D/0WGwv/h/9ZCrWSF//vHsPt8/6d73yEI1b5Qz8d4 hKrL/00W/5clqyf/p0bjJul028tU0z7/ZyfHrkKl8H/H+T/pa+L/FhapmqfqfP832tz+z4XC /1Eiy93/6QNjRPk/3Yj/0z8K/3d8cVc5/i9+3hv/l54V/i+hW3El/yezmUX8nyzKxf9tWWG+ 5P+6Hv93Yf+nOvxfhqzwf/i/16zwf4mh8H+xoV7PIP4vwwnE/yWGOtX/+fEB/m9LKPzfWyj8 H/4P/7ccCv+Xmtbp/q/Psf9fuAH85f/kn1Kb/5PbUG3+T1LA/+H/ZqWk/5O7RRH/Jz0J/N/C PfDj/J9fOF/A/9muNd7/6Wl/C5zazj6qy/m/MOeK//sC/+fPFv5vYern0v7P0Xj831Io/B/+ b+l1Yzuv8H+x90D8X6jwf1tDrWSF/9uI8vB/+fyfCf1ZqfaFej7GI9SZ/k86b60fJez2f/Ik 72Uo9wn+T/oeVfk/a8zg/N/95rfP//Wu3YZK4f/wf1H+T48V+r/Ojz3wf5Szy93/mQNjxPk/ Lf6v/VH4v+OLu8rxf/Hz3vi/9KzwfwndivP9n/QnSvg/eT2G/9vQLM73f43C/20LteL/jkAi K/5P1j/g//B/T+Xpx2rxf/JSFv+3JdSF/J9fhYj/23QG8X8ZTiD+LzHUqf7P34vwf1tC4f/e Qn2b/7N+BIb/iwqF/8P//U6pXsv/yT8lyf+FyfMP8n/yrE/0f83sQ1j3f+EFQgH/ZyYtWaXc Ljb6P1mkU5v/k34z/m9hDck2/yfP3CL+r5V+WRH/5+9CRfyfz6qM/3Nfwl3I/92zlsn/Q/2f 5JHV/7VL/u92HXVuwfdkE16LTK2XKKH6DP8XZv1L+D/ZV7OI/3PzePi/xVCX9n/+EDn9nxqu 4//6W0/p9vf4v6VQ+D/839LrxnZerfo/uV7xf+/DA/yfVPi/raFWssL/bUR5+L+M/q/3w8VQ 7fR/T8fw8xbn+z+ZAWgS1i7rvptVn+D/7l8TV5P/u/3pNpi69V7artsbSls/CA6Vwv8d6P/c Ca7M/xnb1ej/xhH/R/mAcvd/7YEx4vyfEf/X/yj83/HFXeX4v/h5b/xfelb4v4RuxaL/k5nN nP6vteP5/q8NdKOA/+vCuyD835+h8H9vofB/+D/831qoc/2fvLDD/20JdR3/1/sX3fi/TWcQ /5fhBOL/EkOd6f/60bXQrP7PWPxfplD4v8z+LwwJ8H/4v9VQ+D/8Xyiy7lX5Z32q/+teQr34 v3mnc7f/Cwt8X0O9+D9Z+xCkXKL/k897zf+pcMfL6P/caotF/yerMcr4P/lg6vJ/wcbj/xbW kGzyf5009hL+rx18s8np/9oV/9f2YY1JPv9nzIr/88uai/i/wV/CegqrRXf6vxlb+Az/1/gL 6nj/19nJuAXfYwoemoxXQ6H6DP/3pEQO9n/SBo73f/3kfjur/7u1+Uv5v8ajlyL+z319W17/ p82K//P31kL+T5pFmv+bHUM+q7P9n9u4tJT/s7PkjvV/vg1k9X/jmv8LS5lK+L9wMdTm/+Q5 WML/hYVfaf4vvG58rINY9H/yjQpl/J8MDwr4PzWNj2rvPXB+DKXwfwr/90eolazwfxtRHv4v o/+btH1UO/3f0zEeoc70f/JYMz6dvf7vaZHqR/g/ecFVlf/rOgcstWnDi+5d/q/v/IyvVOoj /J+M6avzf379UW3+r6nR//Ua/0f5hHL3f92BMeL8X+f9X9f8KPzf8cVd5fi/+Hlv/F96Vvi/ hG7F6f5PmkUR/yf99CL+rw3fTov/+zPUov/r3bs//N+mUCv+r8kQqnkJteL/3MHz+r8G/5ch K/xffv8nXyCd0/81I/4vNdTZ/s/6Tzqn/zMd/g//t34C8X+JoU71f/7Tyer/FPv/JT9F8H/J J3DR/8lTEf8XFQr/h//7vbVfyv+1OfxfWF7ZvYR69X/yxxL+71dnyfmTaiFUDv8nA8uM/u+R 1Yv/e8oqh/9Tas3/hQW+lfm/yf92Rv+nx2v5P8kjp/+7XVfL/k+sZhH/F75mqoD/GyYXKqf/ U3bZ/+nR32Bz+j+17v/CdILcnI/0f41vcyX8X99Yt+B76BJut5N80NP981YX83+Swnf6P3cP vI7/k4XK+L+FqR/8H/7vr1W36/6vkd3XSvg/2bO7iP87ZH3qsv9ryu3/F54Yaf5P7rP4P/zf RpSH/8P/LYRayQr/949h9/n+r9V+FV0rD/x9oZ6P8Qh1qv+TDyaj/xu78/1f2NUwyf8NMn35 Mf7PuC0Cbt2l8EWgu/xf17mmFyr31xr/lyWrS/g/3Zrs/s+c7/9sg/+jfEC5+7/+wBhx/q8X /2d+FP7v+OKucvxf/Lw3/i89K/xfQrfidP8nE6Al/J+e5J06/u8L/J/F/32N/+vk+4/xf/i/ p/L0Y/i/Ff/nZrLwf4mh6vN/bdfh//B/qycQ/5cY6kz/Z/3SHvzfllD4v7dQ3+b/ZOcm/F9U KPzfd/q/sLQc/7fFU1zJ/8ligYz+r2mX/Z8OO+mV8H9Tbv+nV/f/CxPK+L9/+7+r7f83hKFV Pv/3QHnP11UX8sjo/9Sa/5O1xjn93+yzego1+t5ZTv/Xrvg/NfqFaXoMMmTn0qJpVv1j/78+ fGa+OtL/mSa//2uW/N/gNJnzf8buf1cx6V4/Kg8oT/d/T7tEVeL/bOMuBvzfYqiN/s+3uSL+ b8zu/4RE/adeSmgPef1f84f/k0aU5v9CJ9ec7f/awWb3f+Oq/2tnyR3q/xq/wier/+u6Zf8X tgevbf+/0Gcp4v/kIVLE/8kNz/9Yqv/7vd0u+z/5+zL+T4bz+D/83zyp40Lh//B/K6GekpoP mWvxf2aSvsVk998Dn4/h+4EV+r9uPN//yUOm9Z2K3f4vTKAPT6FO839D292uJK27vuv2htJd 61Zehcr/0On+L8C/6vyfv17q8n/N1OD/tvi/W2PG/1Fiy93/2QNjxPk/K/6v+1H4v+OLu8rx f/Hz3vi/9KzwfwndikL+z3Sr/k9ej5XY/09eSJTxf/64+L8tK8yX/J81+L88/i/rPXBl/z/3 2/i/Le8o8H/poSrzf7rt8X+pofB/77Hwf/g//N9qKPxfQlb4v8RQl/J/ck/H/0WFwv/h/35v 7Vf0f35aIdH/hTn0df8XVjf7Zr7X/72tTy3k/9qmQv/nQMqy/xvY/2+L/3PrEvB/UZ8V/i+r /wstUL2V/P7PhTrd//m7UAH/Nxn32NDt0PQp/s/fJkLl7Qv+L+YELoRa9n9ufSr+bzHURv/n 3999p//T5hP8X/+odvu/fl6p0/f/O8D/OUS+4v/GWfVl/s80q/5PFs4X8X/yIRXxf3JvLeD/ AgQr4v/CjFIJ/yd7NZbwf1qeZyX8n5bHr1Q774FPx1AK/6fwf3+EWskK/7cR5eH/svo/4yv/ kN/t/2bHeEi5uvyf+YD9/yr0f+M0dNYxpSFl/z/jegihcuuwLP4vS1bX8H/DmN3/jef7P38l ZfV/btSI/6NElrv/Gw6MEef/BvF/9kfh/44v7irH/8XPe+P/0rPC/yV0Kwr5Pz2u+j8ZxZXw f42fdcT/bWgWp/u/Ef/3Pf7PLyjK6f+0wf9lyAr/h/97zQr/lxgK/xcb6vUM4v8ynED8X2Io /F9CVvi/xFD4v8i08H/3Cv/30f4vrITF/23xFPi/qHbx7P9W9/+T5PF/G1pgff7PfYMv/i/q s9rq/0QN5fR/tkr/13Qf4P/kX1TC//lGfLz/000zNm7Btx0TVpxN8neh8vblSv4vTDWW8H/u VpTX//XdtfyfX/tfm/+z2f2fXfV/06Pa7f+meXW+/7O9ye3/fGOvzv/dbqf4v8is8H/4v4Xh Af5PKvzf1lArWeH/NqI8/F9W/+dnUif/tnG3/5sd4/YEtOf7PyuP3Iz+b47y8H/Z/N80Ntbt /9f2g90bSnfazZSGyp2aEf+XJSv839f6PztOuf2fC4X/o0SWu/8bD4wR5f9MI/5P/yj83/HF XeX4v/h5b/xfelb4v4RuRSH/d+uqrPk/+TqPEv6vLbf/n2SF/9uywnzJ/w0d/u97/J+sf8jo /wb8H/5vLRT+D//31iyq839uER3+LzYU/i/z+AD/l3gCl/2fzyOr/zMD/i9TKPwf/u/5DOL/ 0kPh/7Y39mv7v/usmV/YsdP/GTOvtFnxf/OR2G7/9/phnb7/X6X+T26u+D/836wc4P+a9kL+ L2yzldX/jcv7/+ne+kWEQ5/i/+QmHbbZdaEq9H99t+j/bs3B+z/bpuz/10yP6kP2/wsfqZwD /N+a/xs1/i8yq7P8n7uzn+7/wrsrX+1dYj4/hnxWZ/u/sZz/s8MsuWr8n3yRRhH/F7A+/m+v /9M5/F+4hP/wf74fWMb/ySRFGf8X5kaS/N/sGErh/xT+749QK1nh/zaiPPxfRv83+L7Hbdi9 P9TzMR6hzvR/Mh+Y0/+N7P93gP+7ZXEbxLlZ6TbMzu3zf4P+rRT7/x3o/3wrr8z/+Y1L8X9L oZ78nx7xf5Tocvd/04Ex4vyfFv/X/ij83/HFXeX4v/h5b/xfelb4v4RuRSH/15nz/V8blmTh //B/TwX/l+j/3MGz+r/W4v8yZIX/w/+9ZoX/SwzF/n+xoV7PIP4vwwnE/yWGwv8lZIX/Swx1 Kf8nXXT8X1Qo/N+X+r+wYg//h/+bFfb/S/V/obnh//7wfxb/9/X7/92FR4H9/yZZ2TeFxdg7 /d8cOaz5PzV23v+1YRZr3xP/bjLC0KlK/zfqRf/XD+L/+nZ/C5xkGXuoPsP/dXMlUon/660b j2b1f7d/9ZX8n24EaX2l/9OfsP9flf7Pdrn9n+ku5v+kJ1bE/93/Kf4Ph/q/Q9anLvo/3cy6 iwf7P9M8qlT/95sV/i/qBOL/QoX/2xpqJSv830aUh//L6f98lzNUe/3f/BiPUHX5v/uuhp/g /1JC3f3fs7460f9Nt9Gv1q3pUvyf69KFSn2E/5MxPf7vz5HIB/i/wVTo/3p/JWmtR5sQ6mmK xE2o4v8okSX4P32ktYvzf8b7v7b7Ufi/44u7yvF/8fPe+L/0rPB/Cd2K8/2ftIcS/i+88czo /yz+7xj/Nzb4v+/xf37mOaf/60b8X4as8H/4v9es8H+Jodj/LzbU6xnE/2U4gfi/xFD4v4Ss 8H+JofB/kWnh/+4V/u+z/V/ADfi/3f4v9GDy+b9HqFf/1z+q3f6vn1cF/d/q/n9y8Jz+79a7 KOT/3ML5Zf8Xdg3D/+H/ZuW79/9T5/u/sXc3vKz+zxTzf62t0v8t7/+nG/fYyOv/nH25kv/r pOmV8H+2zez//CV8If9ntFT4v9epn+v6P2sHk9v/+ca+7P/aWXL1+D8ZTBXxf234p/g/HOr/ 5CFSxv+FBVol9v8L/W3fka7H/8nZKuL/uke12//NjqEU/k/h//4ItZIV/m8jysP/ZfR/ozxd p6bdHer5GO4nz/d/Vh4iaf5POiPdb0ca/5cjqxf/Nzam9/6vNXtDOfjX/VYK/4f/i/J/Nvv+ f61tTvZ/brlZbv/nQuH/KJHl7v/0gTHi/F8r/s/+KPzf8cVd5fi/+Hlv/F96Vvi/hG7F6f5P VruX8H9mCG+n8/k/hf/D/8lvP1XX8n/+zUtW/+dWdeD/krPC/+H/XrPC/yWGwv/Fhno9g/i/ DCcQ/5cYCv+XkBX+LzHUpfyfrFPE/0WFwv99qf8LjAn/h/+blZL7/32z/1Or+//1YXc2/N9r qGf/1+D/0vxfP1xp/7+v9n8fsf+fzzqr/3O32wX/pyfL/n/f4v/GTuP/Nl5Xy/7PL3r4Uv+n bJX+T5uz/d/tCY//27Tq1lzL/xXc/2/eXcT/PTWL9qn6BP9nH9Vu/zc7hlL4P4X/+yPUSlb4 v40oD/+X0f/ZsHeff0W70/89HeP2DDc1+r+W/f8O8X9TezvBzv+Zbm8oB//a30rh//B/+L9m aLP7P4v/o0SXu/8zB8aI83+d939d86Pwf8cXd5Xj/+LnvfF/6Vnh/xK6FYX8X9us+j8ZXpfw f7LVIP5vQ7M43f9Z/N/3+D/321n932Dwfxmywv/h/16zwv8lhsL/xYZ6PYP4vwwnEP+XGKoy /zdq/F+mUPi/3P7Pj8Dwf1Gh8H/f6f/CbQj/t8VTLPq/8NY4zf9JjD/9X7j94f/+bIKn7/8X 1pjh//7wf+z/h/+To3yo/zPCKhL932+oCv3fyv5/w9Tg/9L8n5zgIv7PvbvK6v9u/2r8X2RW p+3/N+L/jvF/Y4P/+xr/Z+d39mP9n3CAUO1dn6rnFf4P//d2DKXwfwr/90eolazwfxtRHv4v o/+TfqLp/duJnf7v6RgPKfcJ/q/bH+rX/4Wxbne6/wuYrCr/p/t2GNz0RSPDg33+zy+xCZXC /+H/ovyf/zamrP7Pvaioz/+ZDv9HiS53/9ceGCPO//Xi/8yPwv8dX9xVjv+Ln/fG/6Vnhf9L 6FYU8n+m+wD/N4ZXxvi/P5sF/i8yK/xfTv83dvi/DFnh//B/r1nh/xJD4f9iQ72eQfxfhhOI /0sMVZn/6zv8X6ZQ+D/83/MZxP+lh7qK/wtLy/F/WzwF/i+qXTz7v7a51P5/4fGE//u3/wv6 Cv+32/+1Df4vMtSz/2u6Uv6vtR/g//yaopz+Tzfjkv8zvYuR1/+59T74v5gTuBCqlP+7NYsr +b9Gphu/0v+56wr/F5XVVv9ny/m/0Pf4Tv/nBsPL/k+WXBTxf3KPLOH/OkmhiP+T52AJ/2ea R3Ww/xOrWcT/hUU/+D/839OndVgo/B/+byXUU1LzIXM1/k9u46Ztp92hno/hF2hV6P8+YP+/ Gv3frdXcnvT69oE99QPj/F8/uq5SqNSH+L/ZZ1WP/5Nhd13+T09jbv+nqtz/r2X/P0p8ufu/ 7sAYcf7Piv/rfhT+7/jirnL8X/y8N/4vPSv8X0K3opD/0+Oa/5NmUcT/tez/9y3+bzL4v+/x f35BEfv/bXhHgf9LD1Wb/2tG/F9qKPzfeyz8H/4P/7caCv+XkBX+LzEU/i8yLfzfvcL/fbT/ Cyth8X9bPMWS/9ONnC7fo9jr/55IlH9Vu+j/ev2odvu/ebd9llVN/s9tSHW6/wtZ4//+2djZ /w//F+X/RhmLhGUgO/1feLnnT9D6/n+t+L8mBQ/ZYDL879Xp/1b3/3PTjnn93z2r9w+rTv8X 7l/4v8/3f41/NH6p/6t0/z/3WZ3s/3rZ/6+XhYh7/V/3qPweqFfyf7JatIj/C0tlS/i/8Gqs sv3/8H/4P/wf/m+5WeD/8H/vWb35P79Ayxi/mG6v/5sfQ/3ulIf/y+7/uke12//ZeeW+u+3k /f+mW+9X3/pk8iHt83+De/yGahYK/4f/W8jqxf8Zk93/dafv/3cbnurc/s+NhfF/lMhy93/9 gTHi/N8g/s/+KPzf8cVd5fi/+Hlv/F96Vvi/hG5FKf9nPsH/SQ8H//cF/m/E/+H/8H9pWeH/ 8H+vWeH/EkPh/2JDvZ5B/F+GE4j/SwyF/0vICv+XGOpS/k+WLeH/okLh/77U/0kbwP9t8RSn +7/uUe32f+O8qtP/PbI62v9ps+b/5AU1/u+Pxo7/+x7/p82q/5NJgIz+z1bp/5rz/Z+e/Mrr 4/2fsXqs0v+FhYqV+T+3IVVe/9f21/J/3tfg/96nfp78n3uIrPi/2XuG3f5v/q5Cnb//X992 3v+ZNP/XPCr/vFr2f5JVEf834P/wfwv+r31Uu/2fnlef4P8G/B/+D/+X3Czwf/i/96xe/Z8e 3e3YmHZ/P/D5GDKherb/kzFcTv93693i/3Jk9bL/X9dpt/9f33W7Q926d67zEyolUyT4vwxZ vfo/gX/V+T9To//zi23xf5Szy93/2QNjRPm/thH/p38U/u/44q5y/F/8vDf+Lz0r/F9Ct6KQ /1N21f+JFCrh/7qw2hb/92ezwP9FZnVp/+fXHeb0f2OH/8uQFf7vG/xf2+P/UkPV5/9ut1P8 H/5v9QTi/xJD4f8SssL/JYa6lP+TlUX4v6hQ+L8v9X/hvSn+73P8XzfW6P+atpj/c2tITt// L+gs/N8/Gzv+D/93Gf/XjVfyf4O7oPL6P7+KCf8X1yxO8n+3ARr+LzKrj/N/vZ/zybr/n+nw f1Ghru7/pCdWwv/JU7qI/5NNZMv4P3kOlvB/OvS3/VIG/F+8/7t/Vq7a6//mx1AK/6fwf3+E WskK/7cR5eH/8vk/PfjJJT360c6+UM/H8F/QXqH/c9PEJ/u/8MjN6f90e7b/6/up9dMXKf5v ciAtVG4dlsX/ZcnqGv5P29z+z43wT/Z/3dDi/ygfUO7+bzgwRpz/0+L/2h+F/zu+uKsc/xc/ 743/S88K/5fQrSjk/7r1/f/K+T/2//sW/3cb/uL/vsb/+VFJVv83Wfxfhqzwf/i/16zwf4mh Svk/g//D/62fQPxfYij8X0JW+L/EUJfyf/LGGf8XFQr/h//7nVLF/7n/4P+aWVVy/z/839f4 v87g/77F/81Q3vN96QD/p9b8n8nt/4JAVW/lAP9nruT/jG5y+z+/ign/F9csTvJ/t381/i8y q7P8n+nwf9/i/9zzCv+X+Fnh/1RU7xb/h/9zP4r/W8oK/4f/w//l8X9qGOTObvb7v+dj1Or/ Wnu6/ztg/78ZyjvJ/2mrB+f/Brs7lO4n1zEJlcL/4f9O9n/KNmf7v3YY8H+UDyh3/zceGCPO /xnxf/2Pwv8dX9xVjv+Ln/fG/6Vnhf9L6FYU8n9tnfv/WfzfMf7Pv502XTfuD6Wt7y2HyofC /0WGWrpbLPg/9/fs/7flHQX+Lz0U/g//99YsqvN/t2cf/g//t3oC8X+JofB/CVnh/xJD4f8i 08L/3Sv832f7P5m9xf9t8RSn+79gjORI+L/z/Z82q/4vZI3/+2djZ/8//N9l/J8LVaH/G/Wi /2v7Lrf/a5sP8H82oBc5B/i/Nf/XjNfyf77Nfaf/q3T/P/dZ4f/iOtLtvLqY/wsSpoj/k7NV wv81obGX8H9y5y/h/+QE4v8WhgezYyiF/1P4vz9CrWSF/9uI8vB/Gf2flWfi4EcfO0M9HeMh 5eryf7eONP4vR1Yv/s+5K+//zO5Qup9s/1upz/B/ViZc8X/4v3P8X+/aXFb/d3uS4/8oseXu /6YDY8T5v1b83/Cj8H/HF3eV4//i573xf+lZ4f8SuhWl/F/zAf5PPiT2/9vQLPB/kVnh//B/ G95R4P/SQ9Xm/26PRvxfYqj6/B/7/+3JCv+XeXyA/0s8gfi/xFD4v7dQ+D/8H/5vORT+LzUt /N/7h/WR/q9p8X+Rod5aIP5PxVxX+L9C/k9eveD/Fu6Bc/9X6f5/K/7v1pvI7f/cCcT/xZzA hVCF/J9rFpfyfx694P/ep37Y/y+n/3P3wLP9n27xf/g//F9EKPzfEaHwf/i/tVArWeH//j3s Pt3/yZ3fpvQDn46hfqVcXf7vE/b/k39oGO3s9X/zbutvqPP8X9vf+pfO/2mzN5SDf91v5Ufw +L8sWeH/8H+Piv3/KDtK8H/mSGsX5/968X/6R+H/ji/uKsf/xc974//Ss8L/JXQrCvk/032A /5NRHv5vQ7M43f/1k39DkdDb1Na/JQ+VD4X/iwy1dLco4f8mi//LkBX+7xv8nzX4v9RQFfq/ Ef+H/1s/gfi/xFCV+b/J4P8yhcL/ZfZ/0t7wf1Gh8H9f6v/Cij38327/F+a/S/g/WaiI//sY /+dJ1KL/G+Qqwv/h/2blAP93u66u5/+asGg1zf/dJ8f+6f/u6+eT/J8N3yv5Af7Pv1fK6v/a YdH/aZ19/z/9Cf6vl6zxf//2f3por+X//HP3O/2f6db8n//XZvV/2lxo/7/Wj6zGfkryf519 VP/yf90suWP9X5Pd/7Vr/k86EkX8X1gxXcL/hbtQEf8nd6ES/s80j2q3/2vm1ar/k+FDEf8n Ta+I/5NJ1DT/Nz+GUvg/hf/7I9RKVvi/jSgP/5fR/4XvX7T+rrsz1NMxZEK1Pv83GPxflqxe /F8zNoP3f023N5SDf+1vpWRG+mT/18px26SVo0bPqw/wf9a/Bsb/LS1Sxf/h/ygL5e7/9IEx 4vyfFf/X/ij83/HFXeX4v/h5b/xfelb4v4RuxZX8n8y14v82NAv8X2RWV/Z/ftUH+/9teUeB /0sPVZv/Y/8//J//rSf/13X4P/zf+gnE/yWGqsz/2R7/lykU/g//93wG8X/pofB/2xs7/k/h /xZCXcD/6dX9//B/+D/2//sC//fX/n85/Z+9kv/rp+z+z51A/F/MCVwIVcr/dRb/F5kV/g// 9/5qGP+n8H9LofB/+L/34QH+Tyr839ZQK1nh/zaiPPxfRv83yPNKqp2hno7xCIX/w/8tZPXi //r2NoDN6/+Mtvi/LFnh//B/jwr/R9lR7v7PHBgjzv8N4v/6H4X/O764qxz/Fz/vjf9Lzwr/ l9CtKOT/9PgB/k8+JPzfhmZxtv8zDkHg/zaFwv+9ZYX/w/99jf9re/xfaqj6/B/7/+3JCv+X eXyA/0s8gfi/xFD4v7dQ3+b/pIni/6JC4f++1P9Jrx7/t8VTLPm/O/Tyr2p3+78nZmPW/F9Y UoL/+6MJ9t0H+D/5YPB/+L9ZYf+/j/N/Jff/u5T/s22T2//ds3r/sAr6P3ngF/F/4bsFCvi/ YRxy+79mvJL/040gLfzfbv/XPqrd/q+dVx/g/6Ymt//zjX3R/4W9Rirzf8Kti/i/LqQzX/d9 kP8TSVfG/0nLLuH/wsKvEv5PWmgR/ycPkRL+T02hT9+o/ffA+TGUwv8p/N8foVaywv9tRHn4 v5z+z489QrXX/82P8QhVl/9rLf4vS1av/m+4dUm1mXSYndvj/6zvrIdKxsL4vxxZvfm/oUb/ 13a5/Z97UXG2/xum3P7PzUjj/yiR5e7/2gNjRPm/rhH/1/wo/N/xxV3l+L/4eW/8X3pW+L+E bkUp/2c+wP/JbCb+b0OzON3/Dfi/7/F/sv4ho/+bLP4vQ1b4v2/wf+z/h//zv4X/U/i/rScQ /5cYqjL/Nxn8X6ZQ+L+P939mwP+lhsL/JYbC/8WGwv/l9H9tcyn/Z8PubPi/t8aO//vO/f+0 WfN/NsyH5vN/Fv+3cGfP4f988y7h/zo75vZ/7vu+8X8xJ3AhVCH/dxugXcv/eV+D/3uf+sH/ 4f/+XHW7vv+fLJwv4f/CgKWI/5OHUxH/FxZo1bX/n3y/SmX+7753X4r/ezqGUvg/hf/7I9RK Vvi/jSgP/5fR/1kZlls77A/1dAw3bMT/LYTK4f/so9rt/6Z5db7/69xErfN/Jsn/6d9Ksf8f /g//d4D/c1nh/yiR5e7/ugNjxPk/Lf7P/Cj83/HFXeX4v/h5b/xfelb4v4RuRSH/19rz/V8b 3nji/77B/1mF/9sW6nz/J+sf2P8P//dUnn4M/7fm/9j/D//nfwv/p/B/W08g/i8xVGX+j/3/ 8H//CHWq/5N1ijn9n27xf6mh8H+JofB/saG2+T+bw/+FLl44kXbF/7U5/J+cGfzf0f7vPlyW n8b/4f/UIf7vE/b/K+j/xuz+b1zzf349kB6mFP8X0Et/Qf/Xuvts5v3/LP7va/yfGS7l/6Qh 1Ob/fJvL6v+UXfN/3aPa7f+6eaXNpfzf00Yqh/q/Rpax5/R/Q7/m/2SZTwn/18/v7Mf6v7BE qoj/k45EZfv/4f/wf/g//N96qJWs8H//GHZ/gP8b5Ek/yCB45/5/82PU6v8Gg//LktWL/2sb 2f8vNL2d/s9Nb4ZK4f/wf1H+b2hy+z//zVkn+78uu//r8H+U+HL3f/2BMeL8nxH/1/0o/N/x xV3l+L/4eW/8X3pW+L+EbsWl/J//7Zz+z+L/jvF/bYv/u7D/Y/8//N9qKPwf/u+tWdTn/wz+ D/+3fgLxf4mh8H8JWeH/EkPh/yLTwv/dK/wf/g//p/49Kf3s/1RXo/9r2mL+75HV0f7PO6VF /ydPEfzfQmN/8n8N/u9b9v9TXbfi/6Tpfef+f0GgqreS3/+55Sqn+z/jsirh/3qd3f85p3S6 //v91j8f6kj/p+QRj//bMHeG/4vK6hL+T11r/79v9n/uvRL+Ly6rS/u/zofC/70PD/B/UuH/ toZayQr/txHl4f8y+j8rE0NS7d3/b36MR6i6/J9tzvd/YbxtUkJJN+Fene//Onv7dJz/k+ms vf7P/lbqQ/yfjPjwf5f0fx+w/98B/m/E/1Giy93/2QNjxPm/Vvyf/VH4v+OLu8rxf/Hz3vi/ 9KzwfwndilL+rznf/xkT+m35/J/C/x3k/yb8H/4P/5eWFf4P//eaFf4vMRT7/8WGej2D+L8M JxD/lxgK/5eQFf4vMRT+LzKtZ//nHvn4v7RQ+L/EUPi/2FAx/k/5dSqp/i+MvFf9n9xO/Erb VP/3eNeN/4tqFlv9n7wWwf/94f/Y/+979v9b9X8SI6f/a4v5P7cy5kr7/xXzf527pVe4/1+V /m90j868/q/vruX/Bqnwf69TP/i/rP7P1uj//rH/n7ycLeL/5B5ZxP/JcYv4PzlbRfxf6Cr5 jjT+D/93dCj8H/5vLdRKVvi/fwy7P8H/yWsJ65+Je/3f/Biq0v3/7lnh//L6v3a0sv/fuDuU g3/9b6Xwf/i/KP9nu9z+r7UN/i8yFP6v0nL3f8OBMeL8X+f9X9/8KPzf8cVd5fi/+Hlv/F96 Vvi/hG5FIf9nuvP9X3t/O43/+7NZnO3/uh7/h//D/6Vlhf/D/71mhf9LDIX/iw31egbxfxlO IP4vMRT+LyEr/F9iqEv5P2lv+L+oUPg//N/vlOq1/N99EkCp3f7PPCbP/edQo/9rm2L+zwyl /J82q/7vPlyWn8b/Lfu/oK/wf1/g/2637BX/18jjA//3b/93rf3/rMH/Xdj/uZniS/m/8VHh /+ZTP1v9X/+odvu/fl59gP8bTG7/5x4i+L/Ezwr/p+IGqO28wv/h/16O8R5qntdhofB/+L+1 UCtZ4f/+Mez+BP8n91ab8j0QT8dwvdwa/d89K/xfXv9n9e0Z7vyf7faGcvCv/a1mofB/+L+F rI73f+z/h/+jhHL3f+OBMeL8Xy/+z/wo/N/xxV3l+L/4eW/8X3pW+L+EbkUh/6fH8/2fkZnN Iv5Ppu7xf1tWmOP/4u4Wn+f//LpD/N+GdxT4v/RQ+D/831uzwP+9xcL/4f/wf6uh8H8JWeH/ EkPh/yLTwv/dK/zfR/u/+6QZ/m+v/+sz7P9nHksL/eew5v+CEknyf2GBb83+75HV0f5Pre// J80N//dv/9c2+D/8n5L/ZV4V839hB0r1Vir1f418/11G/6fHRf9n3BMqr/9z631O93+DfEj4 v3/7P38JX8j/NYK0avN/7nrN6/9a/F9UqBf/167v/9fNkqvH/8lSpiL+T+4mRfyfPN0L+D81 zbqLR/u/8G1CviN9rP/zX2NQxv/JbaKE/7t/Vin+7+kYSuH/FP7vj1ArWeH/NqI8/F9G/9fL /SvJ/z0dw0/SVej/PmL/v+5R7fZ/el6d7/+0veXh/F+3O5SDf81vpdj/D/+H/8P/UT6j3P3f dGCMOP9nxf91Pwr/d3xxVzn+L37eG/+XnhX+L6FbUcr/mQ/wf/d+G/7vz2Zxtv/rNf4P/4f/ S8sK//cN/q8Z8X+poSr0fwb/h/9bP4H4v8RQlfm/dsT/ZQqF/8P/PZ9B/F96KPzf9sZ+cf8X zEaS/5N/7l/+Lywp6YQc7PR/dl4V9H9NW+H+f+v+T/anwP+9h3r2fxb/l+b/Zjvl4f92+L/V /f8mWTE/yAZEe5cWDbPqUv5PT0OT2/85p4T/izmBC6FK+b++u5T/81NK+L+FqZ9n/2cv5P/6 Sdvc/s+tebyS/5N0ivi/IaxE9z92rP8LfZYi+//JXaiy/f/wf/g//B/+bz3USlb4v38Pu8/2 f1aGD2n7/82P8ZBy+L/P939u7vZU/6cnPYn/M93eUNr6cWCoFP4P/3ey/2vtB/i/Fv9H+YAS /F97pLWL83+D939d/6Pwf8cXd5Xj/+LnvfF/6Vnh/xK6FYX8n7Ln+7/2/nYa//dns8D/RWZ1 Zf/X+Jln/N+GdxT4v/RQtfk/9v/D//nfYv8/hf/begLxf4mhKvN/7P+H//tHKPxfyoeF/0sP dRX/NwTcgP/b7f9myxcS/V+Y61OmRv9XcP+/cv5PG/xfmv9j/7+v8X+qq9H//bn/H/5vl/8z TWOr3P9PyFRt/s9dUFn93+1fjf+LzAr/h/97fzWM/1P4v6VQV/Z/ssasTv8nVZr/u1f4P4X/ +yPUSlb4v40oD/+X0/9J73fw49S9/m9+jFr931301OX/ZijvLP/X3rpjzv81u0M5+Nf/Vgr/ h//D/+H/KJ9R7v5PHxgjyv/1jfi/5kfh/44v7irH/8XPe+P/0rPC/yV0Kwr5v/YD/J+RmU38 34Zmcbr/G/B/+D/8X1pW+L9v8H+dxf+lhqrP/3Ud/g//t34C8X+JoSrzf+z/h//7Ryj8X8qH hf9LD3UR/6cbuY/j/7Z4ikX/J6tyE/2fdPH+9H9hJJbk/+TMVL3/X9/h/yJPIPv/fav/u11X Fe7/Z8/f/w//t9YCN/o/01Xp/8KsP/7v3/7v1iO6kv9rJplu/Er/p8cq/Z82Z/u/Yezwf/g/ /F/EJdzMq1X/N+D/8H/4vyyhVrLC/21Eefi/nP5Pxm22n/aHejqG7wfi/95DfaT/+4D9/6zJ 7f/ct6bj/3Jkhf/b5//c1CP+Ly4U/q/Scvd/5sAYcf5Pi/8zPwr/d3xxVzn+L37eG/+XnhX+ L6FbcSH/14Z36vi/z/d/tsX/fY//c3+P/9vyjgL/lx4K/4f/e2sW1fk/9v/bkxX+L/P4AP+X eAJL+b/J4P8yhcL/4f+ezyD+Lz3UZfxfwA34P/zfrHy3/3tkdbT/805p2f9Jy8b//eH/2P/v a/b/w/9V4P8afwln9X8u1IL/a920I/5vORT+D//3x+I29Qn+z0OwrP6v1Vfyf8NYo/+TM5fV /7nBMP4vrhtzZf8nzQb/t/AQwf/5Cv+3NdRKVvi/jSgP/5fR//XyR5vSD3w6hvvJGv3ffVdD /F9W/2fMMPau9zKF2bmd/k//Vuoj9v8zYxiZ1uX//MWA/1sYdn+c/2sH/B/lA8rd/7UHxojz f0b8X/ej8H/HF3eV4//i573xf+lZ4f8SuhWl/F/zAf7v/na6gP9r/fWK/9uywhz/F3e3wP9l buz4v+RQ+L+Y6+rZ/+kJ/5caqkL/Nxj8H/5v9QTi/xJD1eX/3FME/5cnFP4vs/+TJor/iwqF //tO/xeWKOP/tniKZf8XQvkVsXv9X3itHkbeesX/hU6nn67b7f9eF/iW8n/9UMz/meF8/2fl g8H//eH/2P/va/yf6sr5P4X/W7izf6b/c7fbJf/nvkC/Rv8nj7W6/N8wDpn9n7bmSv5Pexvz rf7P4P++3//ZaZbct/k/u+r/pOmV8H92fmc/2P/J2Sri/+RsFfF/oavkO9LH+j+5jZfxf9IC 8X/4v3lSx4XC/+H/VkI9JTUfMtfj/+TTsW27P9TTMR5Sri7/11r8X5asXv2fmSbxf7tDOfjX /FYyFj7b/wX4V5v/k2E3/m9hkeqn+T8/IMjq/25PcvwfJbbc/V93YIw4/9eK/7M/Cv93fHFX Of4vft4b/5eeFf4voVtRyP+Zbs3/yQRoEf/Xy2AK//cF/m/C/+H/8H9pWeH/8H+vWeH/EkPh /2JDvZ5B/F+GE4j/SwxVl/9j/z/8H/7v9Z+E/8P/LfzYsf4vrIzG/+H/ZoX9/5L9nwyX8X/4 v1mp1P/ZL/Z/YQdK9Vby+z8Xatn/BadUl//rxtz+z90t8H8xJ3AhVCH/5y9h/F9UVuz/l9X/ uc8K/xfXkX4dHuD/Ik8g/g//t6Vvgf/D/62Ewv/h/1ZCPSU1HzJX4/8GeZEk1c5QT8d4SDn8 H/5vIatX/zdam9n/fcL+f/g//F91/s/g/yjR5e7/+gNjxPm/zvu/vvlR+L/ji7vK8X/x8974 v/Ss8H8J3YpC/k+PH+D/wnfqFvF/YbEP/u/PUIv+b+jxf9/i//Qo6x/wf/i/p/L0Y/g//N/C j+H/8H9S8H/4P/wf/u81FP7vLRT+D/+H/1sOdbb/U1OYNMP/4f9m5QD/1zYV7v+nDf4vzf81 +D/8n5L/ZV6V83+2nP+zV/J/nXsY5vV/7nZ7vv/rZlUt/m90j868/u/WLC7l/8ZHhf+bT/08 +z83I4j/iwj14v/cQwT/l/hZne7/bDn/J59lEf9nmkeF//t332LZ/9lHtdv/2XmF/1P4vz9C rWSF/9uI8vB/Gf2f1aH/0u4P9XSMWv2fbfB/WbJ68X+duXUq8vq/W3L4vyxZ4f/2+b/WNvi/ yFD4v0rL3f/ZA2PE+b9e/J/5Ufi/44u7yvF/8fPe+L/0rPB/Cd2KUv7PfID/68L3NuD//mwW +L/IrPB/Of3f2OH/MmSF//sG/9dZ/F9qqPr8X9fi//B/6ycQ/5cYqjL/Z3v8X6ZQ+D/83/MZ xP+lh7qM/wu4Af+H/5uV797/r5z/U+v7/0lzw//h/2blAP93u67wf3Ghnvyf+2bsQv7PhbqO /9Otye3/3N5X+L+YE7gQqpT/G/W1/F8v1Tf6P9Ph//B/cjLm1Sf4P+lAFfF/oYUW8X+SQhH/ J6GK7P8XVmH7jjT+D/93dCj8H/5vLdRKVvi/fw+7T/d/0s2xo9kf6ukYbthYo/8bu/P9nzwa c/o/3Z7t/5qhYf8//F9d/o/9//B/lFDu/m84MEac/7Pi/7ofhf87vrirHP8XP++N/0vPCv+X 0K043f8dcl0t+j8ZKRbyf9KZwv/t9H+jxv99j//zC4rwfxveUeD/0kPV5v/Y/w//538L/6fw f1tPIP4vMVRd/s89RfB/eULh//B/z2cQ/5ce6ir+b5Tlefi/LZ5i2f/dIZhS+/1fM68eoV79 3/Sovs7/9UOF/k+v7/8nVxH+7w//Z/F/X7P/3yOr5/vSV/u/kvv/dd2K/wsv5uryf11Xpf8b 5EOqzP+5FWf4v8VQG/1fJxX+73XqB/+X0/+5lZwr/m+YJVeN/wudsxL+73dhvY97qP/r5ele wv810gaK+L8wOeI70sf6P5m8KuL/5JSV8X/yWab5v9kxlML/KfzfH6FWssL/bUR5+L+M/m9o pke1M9TTMR6h6vJ/n7D/X5X+r9eD939dtzeUttpNLoVK4f+O83++2eD/Fobd7P+H/6Mslbv/ Gw+MEef/BvF/9kfh/44v7irH/8XPe+P/0rPC/yV0Kwr5v9vfr+3/J6O4Evv/yVtT/N+GZnG6 /xvwf9/j/1xWWf3fYPB/GbLC/32D/2P/P/yf/60n/9cO+D/83/oJxP8lhqrL/6nJ4P8yhcL/ 4f+ezyD+Lz0U/m97Y7+2/wuv2fF/f/i/Kvf/w//h/072fwX3/7NV+j/Z1VC9lQP2/2su5f+G 7P7Pr3m8jv+7Pxq/0v/pZryW/zNS4f9ep37wf1n3/2uq9H8K/3fU/n+z7iL+76lZtE/VJ/g/ +6jY/28jysP/4f8WQq1khf/797D7bP9npRsz6IR74NMx1O9OeXX5v/uuhnX5vxnKO8n/eUzm /J+Mqfb6P/tbKZkiwf9lyAr/t8//+W/Oqs7/3U4U/o8SW+7+bzowRpT/s1r8n/lR+L/ji7vK 8X/x8974v/Ss8H8J3YpC/q+1q/7viOtq2f/d6Qb+789mcbb/m1r83/f4Pzfbn9X/dSP+L0NW +L/8/k8W6mX0f+6brPB/iaHO9n9jk9v/uekl/F9sKPxf5vEB/i/xBOL/EkPh/95CfZv/s345 EP4vKhT+7zv93yD3cfzfFk9xuv8Lcuor/Z/uivm/vvsA/xd2Z6vK/w06t//rbIf/i/usPnD/ vy6sMcnn/+zp/k83bXb/NzYr/i9kXcL/hfnvjP7PhXrzf2pqm6bO/f/CekU5B5X4v2EcMvs/ N1N8Jf/nmxv+b2Hq58L+zy0Cc1MVowlLTPf4v8bv6BUqmWpf9n92lty3+b/1/f/kblLE/4V0 OvnsjvR/obkV8X9h/FXA/zWhv+1vhYf6v16+uKiM/5PhQRH/Jy0wzf/NjqEU/k/h//4ItZIV /m8jysP/5fN/t5Gen95sfDdmX6jnYzyk3Jn+T14Fsf/fe6jP8n9qMo34PyvDg33+r3Gfd6jU R+z/Z2T4UJv/G2SSDv/3b//3Cfv/de63s/o/dw/E/1EiS/B/3ZHWLs7/Ge//uvZH4f+OL+4q x//Fz3vj/9Kzwv8ldCtK+b/mA/xfL4Mp/N8X+L8J//c9/s8dHP+35R0F/i891Ln+T9615Nz/ b5zwf6mhzvZ/dszu/wz+D/+3fgLxf4mh8H8JWeH/EkNdyv+FIQH+D/+3Gqoe/xcmzfB/+L9Z OcD/dfpa+//JB1OX/7N9dv9n2P/va/zf6v5/+f2fKub/3KZ8hfb/c4twVvxfmE6Qu/KX+b/l /f+abrBV+r8w64//+7f/uw3QLuX/GpluxP/94f9sOf+nTY3+z6z5v7DavTb/J6KhiP+b39kP 9n+SQgn/1xTc/y98m5DvSB+7/5/c/Ir4v/AhFfF/4QGQ5P9mx1AK/6fwf3+EWskK/7cR5eH/ 8vk/NQq3ltH3zlBPx3A/if9bCIX/W9r/r2nH20jl1nvRdneo26/6l3lSqc/wf2MYmVbm//xA uzL/14+5/d8n7P+X3/+5eQv8HyWy3P2fPjBGnP9rxf/1Pwr/d3xxVzn+L37eG/+XnhX+L6Fb Ucj/mW7N/8lq9yL+T96a4v82NIuT/V/X9Pi/7/F/fuYZ/7fhHQX+Lz0U/g//99Ys8H9vsfB/ +D/832qoyvyf7fF/mULh//B/z2cQ/5ce6ir+bwqMCf+32/91j2qv/3sCKbNQr/4v9ARbf6Sd /u9t0Sj7/0U1C/xfTv/XWvxfmv9rWvxfZKhN+/8d4P/cLEmF/k8t7f+nG2uN+L+EdxWTbvSj 8rfb0/3fIB8S/u8P/+cu4Qv5P39jwv8tTP3g/8rs/1en/+v8B1PE/4UBSwn/F67dIv4vjL8K +D/TPKqD/Z8MCIr4v05MTRH/Zx/Vbv9n5xX+T+H//gi1khX+byPKw/9l9H+DCe9f9P5QT8dw f6zR/7X2fP9nukdVi/+zum9vn8AwyZhql//rJ9dZD5X6EP/n/ym1+T+/KAH/t7RItX7/1zb4 P0p0ufs/c2CMOP/Xif8bfhT+7/jirnL8X/y8N/4vPatT/V/oPOH//u3/9Ljq/6Q7X8D/mdBv w/99vv/zr0Mq9H/hs6zM/7m/z+r/3Ksr/F9yVvg//N9rVvi/xFCF/J9bxon/iw2F/8s8PsD/ JZ7AQv5P6wn/lykU/i+z/5M1D/i/qFD4P/zf75Qq/s/95wD/1z6qb/N/ahxW/F87n7qoZv+/ sMQc/4f/mxX835X93z/2/wtuRW7wVfg/fRsoiv9r9rfASfTCdEcM7P93kP8b3aMzq//TzXgt /6elwv+9Tv3g/9j/789Vt+v+L3wlc+iC7OtbvH5Wy/6vl450Ef8nKRTwf2oKjb2q/f8GGX8V 8X9heID/w//NkzouFP4P/7cS6imp+ZC5Gv9npUtq/RzTzlBPx1CV7v/Xjfi/LFk9+z/dTrcH vjbDaLq9oXQ/uV54qNRH+L8A/6rzf77p4f8WFqnW7//cWBj/R4ksd//XHhgjzv/13v/1+kfh /44v7irH/8XPe+P/0rPC/yV0Ky7k/1p5O13E/0kvCf+3ZYU5/i/ubvFx/s+PyPF/W95R4P/S Q+H/8H9vzaI6/+e/lBj/FxkK/5d5fID/SzyB+L/EUPi/t1D4P/wf/m85FP4vNS3831tWH+n/ 1vf/y+//Hlkd7f88icL/RWX15P/cG3z8X9Rn9eL/2qaY/1M1+r+uwf9F3i02+j93n83r/zr8 39fs/+dmii/l/xqpqvJ/nb9bZPV/7YX8Xzda9v/bvOr2dP/3dGevxf/p8BzE/+H/8H/4v4VQ K1nh/zaiPPxfVv/njzvohFBPx1C/O+XV5f9sg//LktWr/xvc9xbd7n2D2RtK95P7LolQKfwf /i/K/3U2u/8zVfq/Ef9HiS53/9cdGCPO/1nxf+2Pwv8dX9xVjv+Ln/fG/6Vnhf9L6FaU8n9m zf9Jsyiy/5/MbOL/NjSL0/3fUKf/C5d4Xf6vz+7/Ovwf/m8tVG3+zxr8X2qoCv2fwf/h/9ZP IP4vMRT+LyEr/F9iqEv5P1mrjf+LCoX/+07/N8ryPPzfFk+x6P86mfhO83+hL43/q2f/P0kB /4f/mxX838f5v4L7/7nGvuL/wkyy3OAr8X9u2pH9/5ZD1e//bgO0S/k/v+gB/7cw9XNl/+cX O+L/lkJt9X/SOSvi/8KNy//Ysf4vXK8l/F8TGnsJ/xf6243aP0DF/+H/NofC/+H/1kKtZIX/ +/ew+3T/58ceamj0/lBPx6jV/92zwv/l9X9dc+tkajP0Znco3U+u/xIq/5P4vyxZ4f++1/+1 Lo+s/u/2JMf/UWLL3f/1B8aI83+D+L/+R+H/ji/uKsf/xc974//SszrV/4V1Jvi/f/u/7hP8 XxdW2+L//mwWZ/s/v1oK/7cp1Pn+zy8oyun/tMX/ZcgK/4f/e80K/5cYCv8XG+r1DOL/MpxA /F9iKPxfQlb4v8RQ+L/ItPB/9wr/99n+T3r1+L8tngL/F9UunvyfGodi/k/rYv5vxP/h//zP X8D/2XL+z1a5/19zJf9n3WMjr/9zTul0/zfMlUgt/q+zbWb/d7X9/77Z/7luTIX+z31W5/q/ YTT4v02rbu2q/5OlTCX8X0BLJfxfWCJVxP9JGyji/yQU/g//h//D/700C/wf/u89qxf/p3Wn H9W+UM/HeISqy/+x/1/628Yl/9d32vu/MJ210//5N2xSKfb/w/+d7P9a21To/1wo/B8lstz9 nz0wRpT/u/3f3v81Pwr/d3xxVzn+L37eG/+XnhX+L6Fbcb7/k1FcCf8X3prg//B/TwX/l+b/ /JRmVv+n2P8P/7cWqjL/Z5oG/5caqkL/N+L/8H/rJxD/lxiqLv+nJoP/yxQK/4f/ez6D+L/0 UJfxfyEd/N9e/zdXbnv9n2nm1br/k6x833O3/3tbn1rf/n/tWMr/eae06P/C4wn/h/+blQP8 n+7wf5Ghnv2fvdT+f9pfdyX83zA1Ve7/V6f/c3e9vPv/meFK/q/xfYsv9X/s/3eM/+vH0eb2 f76xX8f/6XBHKuH/wnCxhP+TR2cZ/ydnq4j/C/dZ35HG/+H/jg6F/8P/rYVayQr/949h9wf4 P+ufUNqa/aGej/EIVZf/60b8X5asXvyf7Sbxf/Lc3+v/zG/lTs2I/8uSFf5vn//7gP3/Jov/ o3xCufu/4cAYcf5Pi/8zPwr/d3xxVzn+L37eG/+XntW5/i+8zsX/vQ2t5v6vtR/g/6SHg//b 0CxO938T/u97/J+sf8D/4f+eytOP4f9W/J8eWvxfaij833ss/B/+D/+3Ggr/l5AV/i8xFP4v Mi38373C/+H/8H/qj+WVzbxa93/2UeH/1ptgwf3/DP4P/+d//iz/1+ka/Z+qcf+/j/B//tMp sv/fOOb2fx3+7yD/109jbv/nLmH8X1RWn+f//H02q//TPf4vKtTF/Z98SLXt/2eK7f+nQme9 iP8Lswm+I43/w/8dHQr/h/9bC7WSFf7v38Pus/1f65+utwdVuzvU8zEeUq4u/zdHeaf5v/FR 7fZ/Zl6d7/96N+hx/q81e0PpfnIdvFAp9v/D/53t/5quQv/nvg8M/0eJLHf/Nx4YI87/teL/ +h+F/zu+uKsc/xc/743/S8/qXP8n4yH837/9n+nO939teKdewv/JCzv835YV5kv+r+3xf9/j /2T9Q0b/Zzr8X4as8H/4v9es8H+JoUr5P9vh//B/qycQ/5cYqjL/Z3v8X6ZQ+D/83/MZxP+l h7qK/wsrYfF/WzzFkv+773ngq73+74lEuaWwy/5vvrp5t//r51Wd/u8T9v8Lo0T8H/5vVr57 /z91vv+bxBqEb0fc6/+mWeVM2aL/m7wPNF0njX3fE99KqEFC1en/+m7B/6npdify/q9LwENT 41zavfrN6v3DKuj/Aumsy/8NbkoQ/7cYaqP/c1nh/xamfi7s/6belPN/dpglV4//E9FQZP+/ +Z39YP8nt4Yi/k86Ev5xuNv/mXm17v+kuSX5v3Y+mlFr/s/6J1Qh/yctsIj/k88yzf/NjqEU /k/h//4ItZIV/m8jysP/ZfR/t8/nUe30f0/HcFj8fP8nY7ic/m+y+L8sWT35v1t3qRl75/+0 dDH2+b/RTTWHSskUycn+z4xhZFqZ//NXemX+rzfZ/d94+v5/7eRe+WX1fx3+jxJf7v5vOjBG nP/rxP8NPwr/d3xxVzn+L37eG/+XnhX+L6FbUcj/6fED/F/4dlr83+f7v07j/77H/7nGjv/b 8o4C/5ceqjb/N074v9RQFfo/9v/D/+H/XkLh/9b8H/v/4f/+EepU/yf7e+D/okLh//B/v1Oq +D/3H/xfM6vwf/g//N93+79P2P/Pn7LW6pQ3MLNf9neDtf3/xP/phPdKKiyulcds21zH/92e 72N+/2c/wf/Jh4T/+8P/3ZrFhfyfbiZffaX/c9+jX6H/c5/Vyfv/2TG3/3M9phX/Z2fJVeP/ ZA+fIv4vrJgu4v/kzl7A/8lAu4z/C1kl+b+N+/+F3y7h/+RBxf5/Cv83T+q4UPg//N9KqKek 5kPmWvyfGkThjzrhHvh0DNfLrdH/tfi/A/yfbnp9G19pY22f4v98N0GqWahT/Z+M+PB/n+// 2i63/3OznGf7v/z7/+H/KDtK8H/9kdYuzv/14v+aH4X/O764qxz/Fz/vjf9Lz+pc/3fEUuIK /Z/5AP8nEKyM/5OJWvzfXv834P++x/+5g+P/tryjwP+lh6rN/1mD/0sNVZ//c9NL+L/YUPi/ zOMD/F/iCSzl/9oR/5cpFP4vs/+TJZH4v6hQ+L8v9X/SBvB/WzzFsv+TdIr4v6BE8H//boLl /J82a/5PPjr83x+NvbX4vyT/p8YB/xcZ6sn/re7/d4D/sxfyf7fupRX/1+1vgZOs/wyVfIv5 2f4vbOlYl/8b3aMzq//TzXgt/+dP2Xf6v3/s/+cPkdP/qeFC+/8d4f/Gi/m/0EJDF2Rf3+L1 s1rxf/L3Jfxf6FQU8X9yOy6y/1/YKtmHwv/h/44Ohf/D/62FWskK//fvYffZ/s9OMjfiH/g7 Qz0dw3WZ8H8LoTL4vzBN7Kvd/m/e6/oNdZr/003Tef/X6RT/15jfynWYLf4vS1b4v33+z31r zOn+j/3/KJ9Q7v5PHxgjzv9Z8X/mR+H/ji/uKsf/xc974//Ss8L/JXQrCvk/ZT/A/zVhtS3+ 789mcbb/85N/+L9NofB/b1nh//B/X+P/2P8P/+d/63n/P4P/w/+tn0D8X2Io/F9CVvi/xFD4 v8i08H/3Cv+H/8P/qX9PSm/1f+Oj2u3/5vZlltXh/q/TFfo/tbr/n5UPBv/378bO/n+J/s9d VxX6P1vO/5li/s+FqtD/mWHR/7W1+j8Jhf/7t/+73P5/X+z/Vvf/6+UQWf1fc6X9/3qb3f9V uf+f+yIN/F9cVlf2f1b6mvi/hYcI/s9X+L+toVaywv9tRHn4v5z+T55n1iaEejpGrf7PdPi/ LFm9+L+2ufXKtLFhc8N9/m9wnfVQqc/wf4NvgdX5Pz/Qxv8tLFKd+79P2P/Pr5fF/1HOLnf/ Zw6MEef/BvF/3Y/C/x1f3FWO/4uf98b/pWeF/0voVpTa/2883/+Z8NakhP+TmU3835YV5ov+ b8L/fY//8zPP+L8N7yjwf+mh8H/4v7dmgf97i4X/w//h/1ZDVeb/tMb/ZQqF/8vs/3p/YPxf VCj8H/7vd0r1Sv5PhcX5af5P/rmhP27GFf8ndyapdvu/ebd9lhX+D/+nFP7v6/yf7or5P7Xm /3R2/9fW6P8q3f9v2f8Z03RV+r+n9YrV+D+34gz/txhqm/+ThoD/e5/6ubT/a7L7vyr3//Mt cNH/3XeoDP3tfX2L189q2f8FTIb/w//NCv5P4f/wf/i/xVD4v8z+b5Bhx2Db/aGejuEn6Sr0 f3fViP/L6v+Mbm+H0MaaMcX/OeQUKvUR/i/AP/zfHyORxwO/Jv/3Cfv/HeD/DP6PEl3u/q89 MEaM/xvc/367MLrmR+H/ji/uKsf/xc974//Ss8L/JXQrruT/7j0c/N+fzQL/F5kV/i+n/2st /i9DVvi/b/B/1uD/UkPh/95j4f/wf/i/1VCV+T/b4/8yhcL/4f+ezyD+Lz0U/m97Y8f/qaz+ zy0WqM7/qXFY83+zZez1+D/5tmX830Jjn/u/1uL/vsb/re7/J88N/N/CPfAC/q/vFv1fp7P7 P43/+x7/Z4ZL+T/fo/pS/2c6/N+3+D/3EKnQ/63u/xc6ZyX8XziBRfyfHLeA/1NTaOy+d3uw /5MnBv4P/4f/w/+9NAv8H/7vPau3/f/k6S7V3v3/5sd4hKrL/w2mRv/nvkzoXP/XupXEtwdV P9i9obTt3IcUKoX/w/9F+T+b3f8p9v/D/1Gk3P1fd2CMOP+nxf+ZH4X/O764qxz/Fz/vjf9L zwr/l9CtKOX/zPn+rxUIVsb/haUY+L8/Qy36P9vj//B/+L+0rPB/3+D/2P8P/+d/C/+n8H9b TyD+LzEU/i8hK/xfYij8X2Ra+L97hf/D/9Xt/8L8dwH/F5Y1p/m/MHVZ2v/9Y/+/7P5P61L+ zy1bXvF/YW05/u+tsc/9H/v/fZH/Ux/g/5rc/i8IVPVWgv9rTcrSorv/6++hruP/hrHJ7f/c CcT/xZzAhVCl/N+or+X//Cn7Tv9Xcv8/eyX/N0zW+79BXg3v9X/No6p1/z/8H/5PPqNmXuH/ ou+B+D+p8H9bQ61khf/biPLwfzn9n/TErE24Bz4dQ/3ulFeX/7PN+f5POgQ5/Z9uz/Z/gxkH 96Dq+hT/57sJUvkRPP4vS1b4v33+T9e5/x/+jxJf7v6vPzBGnP8z4v+6H4X/O764qxz/Fz/v jf9Lzwr/l9CtKOT/lD3f/5n7vs34vz+bxdn+b3DHxf9tCnW+/3N/n9X/dSP+L0NW+L8v8H/u m6zwf4mhTvd/Jrf/819KjP+LDIX/yzw+wP8lnkD8X2Io/N9bqG/zf7KQDf8XFQr/h//7nVK9 lP8LG735V7W7/d8Ts1n3f2FokOT/5MyU93+6K+b/zHD+/n+yWQv+b6Gx4/9y+r9On77/Xzu1 EjGf/9N9hf7PNfbL+D/djmNu/9ex/99B/s+6Vp7V/7k1j5fyf62vvtL/ldz/D/+H/5NzsdH/ yWCqiP+b39mP9X9yDyzj/yRUCf9nmkd1sP+T71fB/y08RPB/vsL/bQ21khX+byPKw/9l9H/D oB/VzlBPx3iEqsv/jR3+L0tWz/5Pt03TuQdVa3aH0rZzvblQqQ/Z/08+K/zfJf3fWKX/M/g/ SnS5+z97YIw4/9eK/7M/Cv93fHFXOf4vft4b/5eeFf4voVtxIf/Xahm04//wf08F//dp/s+9 T8L/JWeF/8P/vWaF/0sMhf+LDfV6BvF/GU4g/i8xFP4vISv8X2Io/F9kWvi/e4X/w//V7f9k /jvN/8kKxL/8Xytz7Pi/b/B/kgL+D/83K5X6vzHoLPzf2z3wqv7v1j93047O/yW0wKnxC31C hf/bcbvF/5Xxf/7M4f8Wpn7wf1n9n8H/4f/8j+L/8H8LDxH8n6/wf1tDrWSF/9uI8vB/+fyf 7vx9NlT7Qj0f4xGqLv83Wfxflqye/J8am2bSt09gCj3off7PNP1vpfB/x/k/P9rB/y0Mu5/8 nxvhn+3/Br8oMKf/c6Hwf5TIcvd/w4Ex4vxf5/1f3/wo/N/xxV3l+L/4eW/8X3pW+L+EbsWV /J9AMPzfhmZxuv8b8H9f4/9GWf+A/8P/PZWnH8P/4f8Wfgz/h/+Tgv/D/13G//VuPI//2xIK //cWCv+H/8P/LYfC/6Wmdbr/k3e3if4vXJXhRK76P1momOb/wvzRH/5PPszWf+x71xL306xa 93/Sn6jN/4Wv3cX/4f9mJSCIRP8X3rj94f9sGDCmNPat/k94WwH/N8jXt+H/tjyvFv2fn7Io 4P+sGcX/6X7/u4qp8R2UUF3O/wWUhP/D/+H/vtP/uVaO/1sKhf/D/y1dws28wv9F3wPxf1Lh /7aGWskK/7cR5eH/8vk/0/ieWKj2hXo+xiPUmf4vTGCl+b/Q4f8c/ycv/aryf7aZbp+ONv1k dofS/eD6L6FS+D/8X5T/65rc/q87f/+/rsX/UT6h3P3feGCMOP/Xi/8zPwr/d3xxVzn+L37e G/+XnhX+L6FbcSX/14TVtvi/P5sF/i8yqyv7Pz+hhP/b8o4C/5ce6lz/J/P3Gf2ftgb/lxrq dP/XtP7E4f82nEH8X4YTiP9LDHWq//OjIvzfllD4v7dQ3+b/ZFUz/i8qFP4P//c7Gr6W/5MF jkn+L6xT+ST/J4sFSvg/WWtcxP8NPlQZ/yfNrTL/1+H/Ev2fb4E5/d/tulr2f51vNmX8X1hj UsD/tTJ9O6U8G+97oPqqbdb8n8/aGLkzJvq/+/dwne7/mnFQmf2fbpb8X2+s93+9TXhXMTW+ FYcK/7fjdov/K+L/3KYRqjr/1/n7bFb/1+L/vt7/Nf5fm9P/3Q624v/kgyni/6RzVsb/ycOp iP+Ts4X/w//h//B/C6FWssL/bUR5+L+M/k/mRkK10/89HeMR6kz/14f9/8z+UDoMrLr7Df50 /2dk4qdtTUKosZ1Xyp7s//pG+/3/GtuavaF03wzTb6Xwf/i/GP+n7Vij/xtdHvg/ytnl7v+m A2PE+T8r/q/7Ufi/44u7yvF/8fPe+L/0rPB/Cd2KRf/X+OaW0/+ZwZzu/0x4a4L/+3z/N7b4 v2/xf8a/AMH/bXlHgf9LD4X/w/+9NYuT/V/vZyXxf5vOIP4vwwnE/yWGOtP/9X4te1b/ZzT+ L1Mo/F9m/yezV/i/qFD4P/zf72j4Uv4vrDX2rGK3/ws3gPB11eOa/ws9Qd/M9/q/sGj0sT51 yf9pgX+t9G/3+r9hXg3Nsv9Td0wm6eTwf+47pM/2f7Kwvjb/Z1r5xPB/b419m/8LA0bpXCT6 v3u17P9agck5/V+75v9a3x5y+j81rPg/v9CniP8b/DoVY5oUPGTDzU8Wm36C//Mtq4D/6/rh 1pPW7W3It/9dxTj5ZYGh+gz/N4T1inIOjvR/MuNdxP/1rqHm9X9dj/+LzGqb/2ttbv+nu27F //k5n0L+Lwzuk/zf7BjyWZ3t//Soivk/PUvuWP/nZ/0L+T8RDUX2/wvp+B871v+FTYWL+D95 Dpbwf/q+l6PaP0Dd6P/khlfE/2lZFFTE/+lHtdv/6XmF/1P4vz9CrWSF/9uI8vB/Gf3f5H87 VDv939MxfN/ifP8na8wq83/ySjjR/8mD6lP8X9c2t3v5rSsjQ/t9/q/r3NgiVOoz/F8jk9+V +T//GdTm/xp3t6jN//WG/f8on1CC/7NHWrs4/zd4/9f1Pwr/d3xxVzn+L37eG/+XnhX+L6Fb cSn/J2888X/4v6eC/8P/4f+SQuH/Yq4r/N9vhf/D/0nB/+H/LuP//B0P/7clFP7vLdTX+T+f A/4vKhT+D//3OxrG/7n/fLf/k8UCRfzfbBk7/u+fLRD/p2Kuq0/0f2Fo5atj/V8fRtwpjX2r /5PPsoD/89+MXcr/uVDV+T9/3BL+rxmn/nbTa+2U4v+8RAkV/m/H7Rb/h/9buITxf/i/pUdj O6/wf0f5P1ul/zPNo8L//btvgf/D/62Ewv/h/1ZCPSU1HzLX4v9ao/Wj2hfq+Rh+ku58/ydz TJX5P+m8VeX/2mG6PcNv3aU2TATu8X+3g5jfSn2G/wvTXfi/j/d/TTvV6P96/B/lE8rd/+kD Y0T5P92I/2t+FP7v+OKucvxf/Lw3/i89K/xfQrfiSv5vDOsj8H9/Ngv8X2RWV/Z//sRk9X/a 4P8yZIX/y+//+vsiO1dl8X/jhP9LDXW+//OPjZz+r8H/4f/WTyD+LzHUufv/uRaa1f/NUR7+ D//3EupU/ycsDv8XFQr/h//7vbVfy/9J9yzJ/8kKw0/yf9b/U8ISiL3+zz5V3bL/02GVfEb/ 98jqxf91klUJ/yeAsjL/1wv8w/8tNPZt/k8+q4z+Tw162f910gJz+j/1Af7Pz2jl9H+mW/N/ /kPK6f9cqNP9nx/MZfV/atH/2aHT3v/1Ce8qxsmf/VD9ZvX+YRX0f2HWvzL/5xZUZfV//m5x Hf8nB/9S/3drzMv+rzfZ/Z/C/x3k/8IJ/k7/5wbDS/4vXAxl/J98SCX8X3iNWcT/SQpF9v8L kyM+VC3+794CS/g/edKn+b/5MZTC/yn83x+hVrLC/21Eefi/jP6vkRkf3ezvBz4f4/YMNzX6 v/YD/J+8hMvq/5qT/Z/txtvAVzdj2Ltvn//re/NbuVMz4v+yZHUN/9fU6f/cczer/7v9JP6P Elvu/s8cGCPO/2nxf+ZH4f+OL+4qx//Fz3vj/9Kzwv8ldCtK+T/9Af5P5tbxfxuaxen+b8L/ fY3/83cL/N+WdxT4v/RQ+D/831uzqM//sf8f/g//9xKqEv9n/Wog/N+WUPi/t1Df5v9kjyP8 X1Qo/B/+7/fWjv9z/znA/9lHtdv/va1Pxf9FNQv8X07/5waO+L+oz+rF/01jlf6vKeX/9Phv /6ebhPdKd/8nH/S6/wtOqYD/01ZO4OH+b+jHwfk/Mya0wHH0/4xQ+dvt6f6vyv3/Bndjwv8t hrqA/zMf4P/uz5oU/zc/hvuh0/3f6MhUVv93u7mt+L/hm/2fXfF/Wu78Rfzfk+zG/320//PT B9X5P/b/w//h//B/q6GekpoPmWvxf0bGHqY1+/uBz8f4KP/n7Uuq/wt9NHO6/2ulN9HKPzrR /z0/r07zf0PnPp3bY6oJXaVd/q91LTBUfgR/uv8z0iGozv/5Vl6V/9PTpHP7v9Y2p/s/k33/ P6ca8X+UyHL3f+2BMeL8nxH/1/0o/N/xxV3l+L/4eW/8X3pW+L+EbkUh/6emNf8nawOL+D8T 6Ab+789mcbb/m3r837f4Pz1l93+qw/9lyAr/9w3+zxr8X2oo/N97LPwf/g//txqqMv9nBvxf plD4v8z+T0Zx+L+oUPg//N/vlOql/F8QP/5Zn+r/updQL/5vPhLb7f9eP6zT/V8bdIOkc6T/ a5vc/s99Ae2y/7NhbTn+7zUU+//V5v864QLf6f/+2v8vo/9rmyr9320wt+D/xklP3v+ltMBx 9DFCJd9ijv+LaxYn+T+358Gl/N8g1Vf6P9vU6P/U+fv/HeD/DP4P/+d/FP9Xnf9rH9Vu/9fO K/yfwv/9EWolK/zfRpSH/8vn/3QXpmH8XN2+UM/H8H2LCv1fN+L/smT17P/GYbBu/z/bSdPb 6f/cb4VKyeQ3/i9DVtfwf2Of2/+5efaT/V/nxx74P8rZ5e7/ugNjxPm/Vvyf/VH4v+OLu8rx f/Hz3vi/9KzwfwndilL+r13zf7JWpYj/s/JOHf/38f6vbzT+78L+T1v8X4as8H/4v9es8H+J oUr5vwb/h/9bP4H4v8RQp/o/v2QU/7clFP7vLRT+D/+H/1sOhf9LTet0/xfe3Sb5v/vyyu4l 1Kv/6x/Vbv83ty+zUDX5PwdSyvg/tbr/H/5vk/9j/79U/zfoYv7P4v+S/F+l+/8t+7+pa3rv /9ph/7uKcfRbOITKc+vz/Z+00AL+7y68Cvg/v0kj+/8thtro/3qpvtL/qU/wf/ZR7fZ/dl7h /77G/7k7+7L/kxfiZfyffEhF/J88nIr4PzluCf937yr5UIf6v14Ojv9beIi08wr/p/B/f4Ra yQr/txHl4f/y+b/b4Nf//WT3+7/nY3yG/5PnVU7/11r8X5asnv3f1HbN4PyfMd3eUPp26xx/ K98xOt//hQkL/N8l/d94uv9rR+v9XxPmRHf6v3nvFv9H2VHu/q8/MEac/+u8/+ubH4X/O764 qxz/Fz/vjf9Lzwr/l9CtKOX/QqgF/ydtroT/a8P3NuD//mwW+L/IrC7t/2T9A/4P//dUnn4M /4f/W/gx/B/+Twr+D/+H/9vr/9z7EPxfnlD4P/zf8xnE/6WHuoz/k+Pi/7Z4CvxfVLu49v5/ 8vf4P/zfrHy3/1M1+j89FvN/LtSy/wsv5iryf9rtiOb9nxlT/J9/uRcq+Rbzs/1f+Egr83/u dpzX/92axaX8XyPVV/q/j9j/b9Yv2O3/5n0LVaX/6zr8H/7P/+iV/Z/02fF/f6yQVvg/hf/7 I9RKVvi/jSgP/5fR/1l5bPgNyfeGejpGrf7vnhX+L6f/07eO0u3TCdXOULodXTqhmoXC/+X2 f507/XX5P9P4lVlZ/d/sgX+a/+vxf5RPKHf/Zw+MEef/evF/5kfh/44v7irH/8XPe+P/0rPC /yV0Kxb9nywgKeP/OlkpUGT/Pxm04/++wP8N+L/v8X9+QVFO/2dG/F+GrPB/+L/XrPB/iaHw f7GhXs8g/i/DCcT/JYaqy/85DID/yxMK/4f/ez6D+L/0UPi/7Y0d/6cK+T/5I/7vjyb4Cfv/ hbEv/g//NyuV+j/J6jv931/7/zX3LXKT/N/vLMl1/F8z5fd/I/7vIP/nLtq8/u/2wMf/xWV1 af83hz97l5i/4aH6/N/t5lah//Mt8EL+T+BfCf93n+Yp4f9M86jwf//uW+D/8H8rofB/+L+V UE9JzYfM1fi/YdCPameop2M8QtXl/7oR/5clqxf/15h+9CsDZXiwy/91nm6F6vYz2uL/smR1 Df9n8/s/2+D/IkPh/yotd/83HBgjzv9Z8X/dj8L/HV/cVY7/i5/3xv+lZ4X/S+hWFPJ/7mtG T9//T+ZS8X8bmsXZ/s+v7MH/bQp1vv/z6w5z+j/V4f8yZIX/+wb/N074v9RQFfo/i//D/62f QPxfYij8X0JW+L/EUPi/yLTwf/cK//fZ/i+8N8X/7fV/vUx8l/B/YQVimv8LHxb+79j9/3r5 e/wf/m9WDvB/01jM/9kV/9dO2f1fey3/F7Kuyv9Nesrt/+5ZvX9YBf1feJ7h//7wf6O+lP/z oyn838LUz7P/s5fyf7rJ7f/cmsdl/xeeNZX5v0ZEQwn/Z+d39oP3/5PmVsT/ydkq4f906Cr5 UMf6v66g/5ObXxH/J59lmv+bHUMp/J/C//0RaiUr/N9GlIf/y+j/RlmzMqbcA5+O4Xq5+L+F UPi/Rf83jk3vHuZh8nuX/+sbN7oN1SzUmf5P5rFq83/+7UFl/k+bKbf/cy8qzvZ/k8nt/1wo /B8lstz933hgjDj/N4j/sz8K/3d8cVc5/i9+3hv/l54V/i+hW1HI/7n3tCv+74jratn/Se8J /7ehWeD/IrO6tP9zIwf2/9vyjgL/lx6qNv/X9vi/1FD4v/dY+D/8H/5vNRT+LyEr/F9iqEv5 P/Eo+L+oUPg//N/vlOql/J/N4f/mpmwW6nX/v/5Rfd3+fw+UV5H/U+v7/0kK+D/836x89/5/ Bf2fWvF/45Tb/7kve1z0f5Nf5WT0kPLED+vTpXJ0Y8X/hemEsLjlu/yfC/Xu/0xjs/u/j9j/ T2Q3/u811Kv/uz2FL+T/msn3yr7T/7nVgef7P/2odvs/Pa8+wP/5BcB5/Z9Z9X9mllwt/i/M oRTxf+GfUsT/yXGL+D85bhH/J82thP+T4UMR/yfd2iL+T570af5vfgyl8H8K//dHqJWs8H8b UR7+L6P/s3IHHfxc3c5QT8d4SDn8X27/Z7pHVYn/M01j21vVTU/9wEj/Z037W6nP2P9PXr1X 5//8sLsu/2d0dv/nZ87Y/y9ufNXMK/xfNeXu/6YDY0T5P9OI/9M/Cv93fHFXOf4vft4b/5ee Ff4voVtxvv+TNlfC/8nUC/5vQ7M42/8ZNwWP/9sUasX/zRtqrlD4v8hQ+L97hf9b83/W4P9S Q1Xo/xr8H/5v/QTi/xJD4f8SssL/JYa6lP+TZo7/iwqF/8P//U6p4v/cf/B/T/7vavv/SQr4 v3/7v6Cv8H/f4P9Ulf5vXPF/oxX/F+5PO/f/m2ZVay/l/4Ye/4f/u4j/035NJP5vYern2f8p /N/X+z/d5vZ/vgVeyP8J/KvN/5nmUeH//t23wP/h/1ZC4f/wfyuhnpKaD5nr8X/y29Ym9AOf juF+skb/d9/VEP+X2f/1t26OvnVuU/xfP42/1SwU/g//t5DVm/9rs/u/D9j/r2/wf5QPKMH/ DUdauzj/p73/68yPwv8dX9xVjv+Ln/fG/6Vnhf9L6FYU8n96XPV/slKghP+TASP+b0OzON3/ Dfg//B/+Ly0r/B/+7zUr/F9iKPb/iw31egbxfxlOIP4vMVRd/k83I/4vUyj8X17/Z6WzhP+L CoX/w//9Tqley/9J9w3/94f/q3L/v3X/Z8Pacvzfa6jn/f8a/F+a/5vGD/B/8vjA/13S/7nb 7YL/m3qd2/+5E4j/izmBC6EW/d/gPp2s/s/NFOP/4rI6zf+N+L+v8X9jjf5PfcL+f7JUFv+3 MOjB/+H/FP5vntRxofB/+L+VUE9JzYfM9fg/2z6q3fv/zY7xCIX/w/8tZPXi/yajx9uDqulk WnCX/7Ote7kWqlmoU/2fjPgq83++m1Ob/+uy+7/ZAx//h/+7drn7P31gjDj/Z8T/dT8K/3d8 cVc5/i9+3hv/l54V/i+hW1HK/5k1/ydvCUr4v1aH1bYF/J+sFMD/bVlhjv+Lu1ts9H/dAaFW /J+fecb/bXhHgf9LD1Wb/xsn/F9qqAr9H/v/4f/wfy+h8H/4v4Ufw//h/5bSwv/h/xZ+DP/3 2f5P/j6n/7Nr/i8snBdysNP/2XmF/zvM/8lx8X9/+D+L//ua/f9slf7PFPN/nbmS/7NTy/5/ X+P/xja3/7uN8S/l/8ZH9W3+T9kq/Z82+L+FE/iJ/k9/wv5/+D/8n3orYVFQEf83X9289x74 tEJa4f8U/u+PUCtZ4f82ojz8X07/F+Yc/Ye01//Nj/GQcvg//N9CVi/+z5rbb98eVGHye5// 6/TwW7kOsz3d/wX4h//7YyTyeOCf5//6vkb/12l/8Iz+7/Ykx/9RYsvd/5kDY8T5v1b8n/1R +L/ji7vK8X/x8974v/Ss8H8J3Yrz/Z/0J0r4P+no4v82NIuz/Z8f/+L/NoVa8X/tAaGW/Z+f gcnq/26De/xfelb4v2/wf+z/h//zv4X/U/i/rScQ/5cYqi7/p0aN/8sUCv+H/3s+g/i/9FD4 v+2N/eL+T/4pJfxfWIGY5v+CfSnu//ruWv5Phsv4P/zfrNTp/8I3pef0f3bN/7XZ/V+5/f/+ 4f/Czq5hcUsN/u/2t9ot+O6GaX8LHCc/XR8q/N+O2+1Z/s/fAy/k//xEKP5vYeoH/5fV/xn8 H/7P/+g2/xeeg0X8X/uodvu/p0sY/xd9D8T/SYX/2xpqJSv830aUh//L6f/kKSzVXv83P8Yj VF3+rxvxf1myevZ/7q5n3LxFL2Oqff5vdGOLUCn8H/4vyv9NQ3b/Z/F/+D+KL3f/1x4YI87/ 9d7/9fpH4f+OL+4qx//Fz3vj/9Kzwv8ldCsK+T+3KGHZ/8m8eAn/F7rv+L8NzeJ0/+cG9/i/ TaFW/N8RSGTF/7lzktX/qQ7/lyEr/B/+7zUr/F9iqEX/J1+Pl9X/Wfwf/m/9BOL/EkNV5v/6 Dv+XKRT+L7P/EySS0/+ZAf+XGgr/lxgK/xcbapv/Cyt70/xfuAGEM7jq/+SPaf4vzB/V7P8e oY72f94pLfq/MErE/+H/ZuW7/Z/6AP+Xff+/0ALVa9GN7/qZRjpxe/3fMKscX1vxf+HOHha3 HOn//OL8rP5PNwv+73aTcPfZ201vSEAOU9PrR/UZ/i98SPi/f/u/2yd/Lf/nT9l3+j9tqvR/ 7rM61//p3nj/18jsyE7/53v6oWL/P/wf/u92FfjrFf/3xwpphf9T+L8/Qq1khf/biPLwf/n8 3/NG2vtCvWzG/RvqVP9nH1Ue/zd2+L8sWT35PzWN+paHbjszJvi/YbS/lfKrps73f1qquvyf f1FRmf9r2ym3//MzZ9X5PxcK/0eJLHf/1x0YI87/WfF/7Y/C/x1f3FWO/4uf98b/pWeF/0vo Vpzv/2R4XcL/Se8J/7ehWZzt/zr3rgX/tynUiv874h647P8Gd7fIu/+fwf9lyAr/9w3+r+3x f6mh8H/vsfB/+D/832qoyvwf+//h//4R6kz/108+B/xfVCj833f6vymsjMb/7fV/XZg1cwdJ 9X8hq/bf/k9674n+77E+9WT/pya5YDP6v0dWR/s/vbr/H/4P/1fE/01jjfv/qWL7/635v9uj 0V9JUx8Wte/zf+2s+sf+f3JCS/g//5Iiq/9TS/5Pa9sb8X9tiv/rpkd1uw/g/47xf9ZNNWb1 f27Pg0v5P//0qM3/jd/s/87f/68Z3Qkem8mEJaa7/J9/ZRmqWv3fuOr/pOmV8H9DWInuf+xY /ycttIj/k0FPGf8X7rOt2j9A3bj/nzxk8H8bVkjj/xT+71+hVrLC/21Eefi/jP7PDN2j2un/ no7xCFWX/xsM/i9LVs/7/+nejVR029rB7A2l7eB6XaFSH7L/H/7vW/yfyb7/n5t6PNv/9RP+ j/IB5e7/+gNjxPm/Qfxf/6Pwf8cXd5Xj/+LnvfF/6Vnh/xK6Faf7P1kbVcT/yYQ3/m9Dszjd /7mpYfzfplCn+78xu/9z75Pwf8lZ4f++wf+x/x/+z//Wk/9z00v4v9hQ+L/M4wP8X+IJZP+/ xFD4v7dQ+D/8H/5vORT+LzUt/N9bVp/p/0a9sv+fLCrN6f9u99vT/Z+cQPzfeyj8X5H9/wL8 w/8t3C3m/s9NXeD/3kIl+z/T3vf/y+f/PmP/P2l6dfk/475xHv+3GGqb//N9C/zfwtTPdff/ 66bO4P/S/J90oMr4v/md/Vj/F16NFdn/r39Uu/1fO6/W/V/7qA72fzJexf9tWCGN/1P4v3+F WskK/7cR5eH/Mvq/0XeVQrXT/z0d4xHqTP8nLz5z+r/J4v+yZPXs/27jVu32/2s7aXr7/N9t yPRbqc/wf2Hyuzb/505wdf5PZ/d/5+//1+kW/0f5gHL3f/bAGFH+r23E/zU/Cv93fHFXOf4v ft4b/5eeFf4voVtRyv81q/5P2lwJ/yevror4P1nChP/bssJ80f9N+L/v8X++zeH/NryjwP+l h8L/4f/emkV1/o/9//Zkhf/LPD7A/yWewFL+zwz4v0yh8H/4v+cziP9LD4X/297YL+7/Qih3 kL3+L0yem+Yl1Kv/s4/q6/xfOxbzf1qf7/9ktTv+7z0U/g//t9QCP83/jX1u/+feK53u/1r5 /rvj/d/QjNn3/7Mf4P9aud0W8X9ypRfwf517/mf1f/4SvpL/86fsO/2fu7Pj/6Ky2uT/rG6b 3P7PN/ZF/xdOcG3+T0RDEf8X0vE/drD/C2/TSvg/eQ4W8X/hPtuq/QPUD/R/cvMr4f9CDzrJ /82PoRT+T+H//gi1khX+byPKw//l839GpslCtS/U8zHcD9Xo/7oR/5clqxf/17sBrPN/rdkb yrG06bdS+D/839n+7/T9/3TT9/g/ygeUu/8bDowR5/+0+D/zo/B/xxd3leP/4ue98X/pWeH/ EroVhfyf6Vb9n0ihEv6vDf02/N+fzeJs/9c7ZoP/2xTqfP/nFxTl9H+mw/9lyAr/h/97zQr/ lxiK/f9iQ72eQfxfhhOI/0sMVZn/m6M8/B/+7yXUqf5PevU5/Z9u8X+pofB/iaHwf7Ghtvm/ PnSi3UHwf0+v1Z/8n+2L+b8HNTzR/8nNFf+H/5uVr/Z/2tTo/0ILVG/lAP9nP8D/SR45/Z/b bvXd/7X90LsF37af9rfASVhVqD5j/79+rkRq8X/WXVf4v8VQF/B/Cv93jP/Lv/+fwv/h/+Qg +L/a/B/7/+H/8H/4v9VQT0nNh8zV+L/GP0Tc+vjdoZ6P8ZBydfm/u2qsy/+5yYRT/V/b3rrr bvoipLPP/42uFx4qP4LH/2XJCv+3z//p0/f/c+4vu/+z+D9KdLn7v/HAGHH+z4j/634U/u/4 4q5y/F/8vDf+Lz0r/F9Ct+J0/ycToEX8n0y94P82NAv8X2RW+D/2/9vwjgL/lx7qVP/XtuEh 4n8sh/9To8b/pYaqz/9p/B/+D//3Egr/t+b/2P8P//ePUPi/lA8L/5ce6ir+bwzp4P92+r8n jbPX/92XFkrVjSv+L2w16Kvd/m9uX2ZZPb+sbaVp5/R/fVfh/n/uBfSK/5Pmhv/7t/+bmbIr +D8rvaRQ7fR/pplVritdof+zK/5vCnzt+P3/tPan3/Thi6/2PfHDOuiwCMdU6f/cnf3d/+mp a8X/DQn7/2m/sCtU+L8dt9uN/s9dtHn9361ZXMr/+V7Zd/o/r6/q83/anO//xuz+z1bp/8yq /5OmV8L/hb5aEf8nD6cS/k8GPWX8X+iZtmr/AHWj/5vwf/g//F+WUCtZ4f82ojz8X0b/J8P5 UO30f0/HeISqy//Vuf/f6f5PD82tq3Qbeo+hq7TP/7n531Ap9v/D/0X5v3bK7f/ckvZz/Z/q G9fmsvo/Nx+I/6NElrv/mw6MEef/WvF/9kfh/44v7irH/8XPe+P/0rPC/yV0Kwr5P/c65HT/ J3Op+L8NzeJs/2c1/u9b/J/xw2D835Z3FPi/9FDn+j95N5hz/79xwv+lhqrP/7npJfxfbCj8 X+bxAf4v8QTi/xJD4f/eQn2b/xv8GB//FxUK/4f/+x0N4//cf/B/c//nvwIZ/5fWAiv0f7bD /8V9Vs/+79aq8H+RoZ7931jM/7XNB/g/P2FzvP9Tk+60+L+E2+0k3YRQfYj/Cx9pWPp4pP8L KXyn/3MwGf8XldXn+T//9/i/TT2m0/1fN0uuGv8XOmdF/N/8zn6s/5MWWsb/hQFqAf8XFn6V 8H/SHor4P7lNFPF/oQed5P/mx1AK/6fwf3+EWskK/7cR5eH/Mvq/3j89QrXT/z0d4xGqLv9n G/xflqye/N/t8Tnd+oG6be+zc7v832D0b6U+wv+ZMGFRm//z3Vr838Ii1bn/a21Tof9zy87w f5TIEvzfeKS1i/N/nfd/3fCj8H/HF3eV4//i573xf+lZ4f8SuhWF/F/3Cf4vvFMv4v98Vvi/ LSvMF/3fgP+7sP9rLf4vQ1b4v+z+L8z54P+2hML/xc2OzP1fx/5/+D/830so/N+a/+s7/F+m UPg//N/zGcT/pYe6iv+TFor/29LpXPZ/9+0V/AnC/32C/2vHUv7Pk6hF/ycvufF/C4197v/a 7lL+r5ev2svo/9zSolL+byzn/9SK/xttKf+nxtEjh9akLC2SBf5hIqf7hP3/8vs/F+rd/42D Gbz/68aE/f8af6sJ1eX8X+ihl/B/k87s//yN6UL+z6+J/FL/59YS4/+istrk/3rbmtz+z0+1 L/o/yepL/d+I/8P/+c9ok/+z0q8u4v+Gcv6P/f/wf/g//N9qqKek5kPmavxf4x8bRvsO2U7/ 93QM9btTXl3+r879/2Yo7yT/1zfd4B5USf6vG/RvpT7C/wX4V5v/882mNv/nV2Zl9X9+5uxc /9dNU27/x/5/lB3l7v/0gTHi/F8v+//pH4X/O764qxz/Fz/vjf9Lzwr/l9CtON3/hfZQwv/J RC3+b0OzwP9FZnVp/yfrH/B/+L+n8vRjtfi//q6zXIX/w//5gv/7R6jXM4j/y3AC8X+JofB/ CVnh/xJDXcr/yWugnP7PPfLxf2mh8H+JoVb8nxwX/7fFUyz7v7CW2J+gg/1fUCLf6P/8Eohl /ycfTEb/Z8z5+//h/zb5PzNey//Jq7Gc+/8NbSn/p+ya/2vDGpNv9H+tLef/xg/wf/63s/o/ 95X9C/v/tW71jfN/fZL/Gx4V/m/H7fYs/+fG+Jfyf41UVfk/a77Z/7nPqjr/167u//fN/s/t 5LDi/2QwVcT/hZXo/seO9X/33a9L+D/pSBTxf6G/3ar9A9Rr+7/ZA2C3/3t9iOD/FP7vX6FW ssL/bUR5+L+c/s+/NDEyJb3X/82P4Xu3+L/3UPi/Jf836eZ219NtEz6kff7Pd+lCpfB/+L8Y /2cmjf/D/1EOKnf/Zw6MEef/rPi/9kfh/44v7irH/8XPe+P/0rPC/yV0K0r5P/MB/k8mvHP6 P7vq/8K7IPzfn6EW/d/Q4v++x//5BUX4vw3vKPB/6aFq83/W4P9SQ+H/3mPh//B/+L/VUPi/ hKzwf4mh8H+RaeH/7hX+77P9X3hviv/b6f/UKIsy/Avo3f6vn1dmzf+1AXrJ2vKd/u/1w1r2 f00QHtn83z/2/6vT/8lrEfzfv/1f1+D/0vb/axr8X2So5/3/zJr/86ffGElur/+T9iDN9yP2 /yvk/3Rj+0n8X0ILnBq/jD1Ufpco/F/MCVwIVcr/uUsY/xeVFf4P//f+avgK/m99/z/rs8b/ LYT6OP8nf4//29K3WPZ/9lHt9n92XuH/FP7vj1ArWeH/NqI8/F8+/6c73xPTne/G7Av1fIxa /Z/p8H9Zsnryf7rpu366fQKT6XaH0la7bm2oZqHwf/i/haxe/d9Q5f5/Lf6P8gnl7v/aA2PE +b9B/F//o/B/xxd3leP/4ue98X/pWeH/EroVhfxf26z5PzknZfb/8xcR/m9Dszjd/034v+/x f37dYU7/516e4v+Ss8L/4f9es8L/JYYq5P9cjwn/FxsK/5d5fID/SzyB+L/EUPi/t1Df5v9k pRn+LyoU/g//9zuliv9z/8nv/+YjsYr8n7SHyvxfyBr/h/+blZL7/zVhxJ3S2J/8nzZr/s/g /7b4v9ZW6f9GveT/9NAP3v+14/4WODX+XITKt8Ar+T9bzP8Nbusm9v9bDLXN//m+xZf6P23K +T9bzv9pU6H/czvlLfu/sK6yNv8nd6QS/q+XjnQJ/xeu1wL+T02hsbP/31uzaJ+qNf8nD/wy /m94VLv93zCv8H8K//dHqJWs8H8bUR7+L6P/a3xHQjcJe6A+H8M90M/3f6N9VHn831014v+y +r/boPv2hLr1XsbW7A2lrX+9ESrlV02d7f/M5E9wbf5v8H3Nyvyfzb7/X2ubs/1fOw34P8oH lLv/6w6MEeX/ukb8X/Oj8H/HF3eV4//i573xf+lZ4f8SuhXn+78jrqtF/6eH7P5P4f/wf/Lb T9XF/J+fec7p/waD/8uQFf4P//eaFf4vMVQp/2fxf/i/9ROI/0sMhf9LyAr/lxjqUv5PvnAe /xcVCv/3pf4vyA78H/5vVg7wf9aU839DKf/nSdSy/5Pmhv/7t/9rO/xfmv/rbCn/p1b3//tq /zf+2//J66VE/yd9Svde6XT/51tJVv/XLu7/51Z6i/9LQA5T41etheo3q/cPq6D/CzIB//eH /1OX2v+v8d7iW/3fuOL/+im7/2uvtP9fY8fc/s89r1b8XztLrh7/J02viP+7cwH/h2P9nxy3 iP+TUEX8nzS3NP8X5vj+8H/yY0X8XyfLA4r4P/n7NP83O4ZS+D+F//sj1EpW+L+NKA//l8// 3Z6+/o/j1O8P9XQMv0CrQv/3Cfv/yRg7p//T7cn+r23cINg9qGQ6a5//a90HHSp30P58/zfK hGtl/q/zYyP838Ii1bn/89+cdbL/G9j/j/IJ5e7/+gNjxPk/Lf7P/Cj83/HFXeX4v/h5b/xf elb4v4RuRSH/575ib9n/yQRnkf3/pKOL/9vQLM72f2OP//se/+f+nv3/tryjwP+lh8L/4f/e mgX+7y0W/g//h/9bDVWX/9PNiP/LFAr/l9n/yTpF/F9UKPwf/u93ShX/5/6D/zvL/2n9Afv/ 4f/wf3Xt//cR/q/J7f9au+L/pi63/+vGKv2fbhb9360H7RZ8j2H2cZ//k9dg0/1t2Ij/+xb/ Z7TF/0Vmhf+rzP/pMfv+f+4pXJ//c0su8H9xWeH/8H9LDxH8n6/wf1tDrWSF/9uI8vB/Gf3f IA+ZoU3wf0/HcMPGGv1fa2v0fzOUd5L/s5P3f2MYX+3yf4NxQ/dQyVgY/5cjq0v4v7bra/R/ k87t/9xYGP9HiSx3/2cPjBHn/4z4v+5H4f+OL+4qx//Fz3vj/9Kzwv8ldCsK+T/3OmTF/0l7 KLH/n7wEyun/7Jr/kzcz+L8tK8zxf3F3i0/zf9qvXWL/vy3vKPB/6aHwf/i/t2ZRnf/zX0qM /4sMhf/LPD7A/yWewFL7/00G/5cpFP4P//d8BvF/6aEu4/9kSQH+b4unONv/zTudu/1f+/Jh FfJ/pmmK+b92LLb/X9Ot+L8wk4z/+7f/6xr83/f7v/tSk3z+z57v/8YR/5fi/yZt+ts94naL TNj/r2vaR/UZ/q8PfXsBVDv939vbskX/F9rAV/q/2wDtWv7PZfWt/s/g/77f//XTLLkv83// 2P/PZ1XE/3VyAkv4v7aY/9My6Cni/0z7qHb7v9dL+HT/J1mV8X+STpr/mx1DKfyfwv/9EWol K/zfRpSH/8vo/3rZ6l1u8DtDPR3jIeXq8n+2wf9lyerF/43tbYjoOkqt2RtKD9ZNoIfKJ4f/ y5LVm//zA6va/N+Q3f/93i2q8n9u3gL/R4ksd/83HBgjzv914v+GH4X/O764qxz/Fz/vjf9L zwr/l9CtKOX/zKr/k+F1Cf8nM5tF9v/D/6X5v0nj/77H/7nfZv+/Le8o8H/pofB/+L+3ZlGd /2P/vz1Z4f8yjw/wf4knEP+XGAr/9xbq2/yffN03/i8qFP4P//c7pYr/c//B/839n3NK9e3/ t+7/5NPB/y009rn/MyP+72v832Ovxuf70gH+T32A/zO5/V/bXMr/dWNu/3fP6v3Dwv99mv+7 Pe7wf5FZ4f/wf++vhp/9n/usKvR/Bv+H//MfAv4P/7c1FP4P/7cWaiUr/N+/h91n+z8rQ70k //d0jFr9331XwzP9n/yxLv83tW3jOkpDn+D/ejeGC5VPDv+XJas3/zfi/zb5v8cDH/+H/7t2 ufu/8cAYcf6v9/7P6h+F/zu+uKsc/xc/743/S88K/5fQrSjk/7r1/f+kP1HC/4XuG/7vC/zf gP/D/+H/0rLC/32D/2t7/F9qKPzfeyz8H/4P/7caCv+XkBX+LzEU/i8yLfzfvcL/4f/q9n8y Lirh/+Yjsd3+7/XDKuX/rCnm/8xwvv8LS8zxf/i/WTnA/41Tjfv/rfo/W87/+aWHegqrRXf6 vxlb8KEq9H/tsOj/urGpcv8/W87/hRfpX+n/3FP4Uv7Pr/2vzf/5EWxW/6d7/F9UqFf/d+ty Lvu/zs6Sq8f/iWgo4v/CYu1OPrsj/V+4Xov4v7BAq4D/k5dBRfzfICipgP8Lkq6M/xse1W7/ N8wr/J/C//0RaiUr/N9GlIf/y+n/ZCbSjgn9wKdjPKQc/g//t5DVi//r9NC6jpKV6ayd/s99 0KFyHWZ7uv8L8K82/+f7gZX5v1sLzO3//MzZyf6v73P7P5cV/o8SWe7+bzowRpz/s+L/2h+F /zu+uKsc/xc/743/S88K/5fQrSjl/1b3/5NmUcL/GR3+Kfi/P5vFyf7PekiB/9sU6nz/J+sf 8H/4v6fy9GP4vzX/x/5/+D//W/g/hf/begLxf4mh8H8JWeH/EkNdyv/JrR3/FxUK//ed/i8s Lcf/bfEUi/5PrvFE/zfv4lXq/8YJ/xcZ6q0F1uf/2g7/h/9T8r/Mq2L+z73sKeT/3HKV6/g/ Oxj834X936jxf5FZneb/Rvzft/g/39jr838j/g//5z8E/B/+b2so/B/+by3USlb4v38Pu0/3 f/JiJ83/zY/xCIX/w/8tZPXi/2zTTN7/ybTgXv9nfiuF/8P/xfk/nd3/mfP9Xzfh/ygfUIL/ m460dnH+b/D+r+9+FP7v+OKucvxf/Lw3/i89K/xfQreikP9zq9nP9n9aZjbL+D8tWeP//gyF /3sL9W3+z2WV1f8NBv+XISv8H/7vNSv8X2KoQv7PTS/h/2JD4f8yjw/wf4knEP+XGAr/9xYK /4f/w/8th8L/paZ1uv/rw3I7d5C9/i+sDn7M/VTo/+rc/8+u+j9JAf+H/5uVA/zf7brC/8WF Omv/v3X/F5zSd/q/2z1w0f/Z7Pv/aYP/O8j/uQ8pr//ruyv5P934U/al/o/9/47yf2M5/yd7 ueP/NnxW+D8VN0Bt5xX+D//3coz3UPO0DguF/8P/rYVayQr/9+9h9+n+T1YjDk1CqKdjuJ+s 0f/ZBv+XJasX/zc0be/9n3xIe/2f/q2UzEjj/zJkhf/b5/9a25zv/9ztOKv/u9148H+U2HL3 f/rAGFH+r2+8/+uGH4X/O764qxz/Fz/vjf9Lzwr/l9CtKOX/mlX/J1OBJfb/M+F7G/B/fzaL 0/3fhP/7Hv/n1x3i/za8o8D/pYfC/+H/3poF/u8tFv4P/4f/Ww1Vmf+zPf4vUyj8H/7v+Qzi /9JDXcX/hZWw+L8tnmLZ/0ko/N+//Z//CuRC/u+R1Xn+Lyysx//h/2YF//dx/q/k/n/mUv6v ze7//JrHs/1fWNqO//vD/5nhWv7P+xr83/vUD/4P//fXqlv8H/4P/4f/iwyF/8P/rYVayQr/ 9+9h99n+r/cbaYf+y85QT8d4SLm6/F9rP8D/jY9qt/8z8+p8//e7/1+3O5SDf81v5f5a4/+y ZIX/2+f/PmL/v/z+b8T/UaLL3f+ZA2PE+T8t+//pH4X/O764qxz/Fz/vjf9Lzwr/l9CtuJL/ a8MrY/zfn80C/xeZ1aX9nxs54P+2vKPA/6WHwv/h/96aBf7vLRb+D/+H/1sNhf9LyAr/lxgK /xeZFv7vXuH/8H/4P/XH8spt/i/017/S/+lxqnD/P0+iFv2fjLzxf++h8H9Z/d/tusL/xYXa 6P/a3P7PfQn32f5PrqSs/s8tLVrwf32X3f91n7D/H/4P/7fk/3ybq83/Wdf0svo/NeD/okJ9 oP9r/AnO6f/U2OH/IrP6PP8nf4//29K3wP/h/1ZC4f/wfyuhnpKaD5mr8X9WnoPWPyH37v83 P4ZfoFWh/+vG8/2fltFOaxJCje280u3Z/q8b7JDZ//kvv8P/ZcgK/7fP/9W5/1/X4f8o0eXu /9oDY8T5PyP+r/1R+L/ji7vK8X/x8974v/Ss8H8J3YpC/s90a/5PJjiL+D/pduD/NjSLs/2f dm9e8H+bQq34v3lDzRVqxf/J+oeM/s+t6sD/JWeF/8P/vWaF/0sMhf+LDfV6BvF/GU4g/i8x VGX+bzL4v0yh8H95/Z+VJxr+LyoU/u9L/Z8cF/+3xVMs+7/wRHMHwf89vVbf5v/0fOriy/yf Wzi/7P9kMTb+7z0U/q+I/+tkQdWX+j97Mf8nWVfl/7oxv/8b8X8H+T+XTl7/13eX8n/SEPB/ 71M/p/k/bSr0f+6zWvF/46z6Mv/nW+Ci/5M5lCL+L7zPrcz/hePi//B/+D/830KolazwfxtR Hv4vp/+TrpId2v2hno7hJxMq9H/3rOryf27u9mT/557u+L/FUPi/3wr/h/+jfGW5+7/uwBhx /q8V/9f/KPzf8cVd5fi/+Hlv/F96Vvi/hG5FIf+nxw/wf0a6byX8X9j1EP+H/3sq+D/8H/4v LRT+D//31iyq839uegn/FxsK/5d5fID/SzyB+L/EUPi/t1D4P/wf/m85FP4vNa3T/V9YmOq7 6rv9n3TxTP8S6sX/zUdi+L8tWR3t/9Tq/n+yPhX/9x4K/5fV/1lzvv/rs/u/tpz/azr833uo dP9n8u//d8/q/cMq6P9Cp6KE/2vC68iv9H8X2//PDxuL+D/j1FBW/3d7suH/4rL6QP8X1lV+ pf/zL1GX9//zWZfxf3IxFPF/ofNWwv9JqBL+LwzlSvi/Tk5/Ef8ni+mK+D/zqHb7PzOv8H8K //dHqJWs8H8bUR7+7wD/ZxPugU/HUL875eH/8H8LWb34P9PdsnL+z3R7Q+mhd73wUM2yOtX/ tVLV5f/88AD/t7RIde7/3Lec4f/iQuH/Ki13/9cfGCPO/3Xi/4Yfhf87vrirHP8XP++N/0vP Cv+X0K0o5P+6T/B/4a0J/u/z/Z9xbzTxf5tC4f/essL/4f++xv+1Pf4vNRT+7z0W/g//h/9b DYX/S8gK/5cYCv8XmRb+717h/z7b/4X3pvi/3f6vfZxI/N/Ta/Ur+79Rbq74P/zfrFS6/19+ /6fK+b+x2P5/nVn1f/Jj3+n/VDH/9xH7/9Xp/9wtPa//c5fwlfyfb3P4v/epn63+b9a73e3/ 5u8q/GdVnf9zT2H8X+Jnhf9TcQPUdl7h/w7zf7PVzbv933yFtML/KfzfH6FWssL/bUR5+L+c /k+GILZP+B6Ip2M8pFxd/m8w+L8sWb36v9szKrf/m6E8/B/+761v8XRVsf/fP0I99W5vT3L8 HyW23P2fPTBGnP/rvf+z+kfh/44v7irH/8XPe+P/0rPC/yV0K0r5P7Pm/0J7KOH/ZGazjP/z KeD/tqwwX/R/btEm/m9TqBX/1x4Qatn/+YVZWf1fN+L/MmSF/8P/vWaF/0sMVcj/uYVZ+L/Y UPi/zOMD/F/iCcT/JYbC/72Fwv/h//B/y6Hwf6lpne7/Qic6yf8FufOX/wuYLM3/hQW+r1Lu cP9nzYr/k4Pn9H9uDUkZ/+c2Y1nZ/09aNv4P/zcr7P/3cf6vtcX8X9us+b/w0ZXwf/7aLeD/ jO1N9v3/LP7vGP839i3+b+N1tez/Gr/2/0v9n2xM+p96Kbb3QCmv/2vxf1GhXvf/Gy/m/2SZ Twn/J3t2F/F/QcqV8H9haXQR/yd9lrr8n+5lMV0R/9c/qt3+r59X+D+F//sj1EpW+L+NKA// l9P/deOj2uv/5sdwP1Sj/2P/v/S3jQv+z9jb//P+T4YHe/3f8Fspv2rqfP/Xzyr837X8n//m LPxf3PiqmVf4v2rK3f8NB8aI839W/F/7o/B/xxd3leP/4ue98X/pWeH/EroV5/s/6U+U8H/y neD4vw3N4nz/pxX+b1uoFf93BBJZ8X/u4Pi/Le8o8H/poWrzf9bg/1JD1ef/2P9vT1b4v8zj A/xf4gks5f9sj//LFAr/h/97PoP4v/RQl/F/ATfg//b6vzsHSNr/L7xW3+b//Hxnqv/7XfNY yv8NbYX+T63u/yfbluD/3kM9+T8z4v/wf0r+l3lVbv8/8wn+L3Rsw+KWKvzfoLP7v/YT/J+8 5Snj/6S5lfB/rjeR1//dnsIX8n/NJNON3+n/VJX+T5uz/V9n8u//p1b9XzdLrh7/J02vhP+T 3y7j/+S4RfyfPAeL+L9wn23V/gFqeIX9l/+Tf0oR/ydLMsr4P0knzf/NjqEU/k/h//4ItZIV /m8jysP/5fR/Mqq0Y7s/1NMx/AIt/N97KPzfsv/rbx/SraPUT2ZvKAf/ut/Kze/b8/1fI6t8 K/N/ftiB/1tapDr3fx+w/1/XuQFBVv/nvn4R/0eJLHf/Nx4YI87/DeL/+h+F/zu+uKsc/xc/ 743/S88K/5fQrSjk/1xn6XT/F96a4P8+3/+1Hf7ve/yfn3nG/214R4H/Sw+F/8P/vTUL/N9b LPwf/g//txqqLv+n9YT/yxQK/4f/ez6D+L/0UJfxf+E9Gv5vr/+T+5BUu/3fMK+0WfN/06P6 Nv9nmqZC/6dX9/8LzQ3/92//1zX4P/yfkv9lXq34v8nHMFNYjL3T/83vge6bsRf93+SvV9OO 0sB3+r95R/Ba/q93eCiv/3O3W/xfzAlU7+8AS/m/vsP/RWa1zf+1Bv/3Lf6vs/i/r/F/g9xN 8H9f4P+kd4v/W3iIzI6hFP5P4f/+CLWSFf5vI8rD/+X0f/JHqfb6v/kx3E/W6P/Grkb/N0N5 J/m/vhk67/+kO7jX/5nfSuH/8H9x/m/I7f8+Yf+/3r/gzun/XFb4P0pkufu/6cAYUf7PNuL/ mh+F/zu+uKsc/xc/743/S8/qVP8XFpjg//7wf82a/5NmUcT/BWOE//sC/+dGDhX6v3nrOdj/ NRlCNS+hlv3fIOsfMvq/1uL/MmSF//sG/zdO+L/UUPi/91j4P/wf/m81VF3+T00G/5cpFP4v s/+T92Q5/Z8Z8H+pofB/iaGW/V9YWo7/2+IpFv3ffdFokv8L61Qq9n9u4Fif/1Ndt+L/evb/ 2+L/2g7/l+b/btfVhfyf7P9XxP+NsqVra1KWFskC/zCR42ZJlv1fmGov4P/kUV/C/zV99v3/ /Cqm6/g/Nd3nXH31Xf5PN+O1/J8/ZV/q/yz+7xD/146N939juGns9H/jo/L3wBX/Z2bJVeP/ 5O/L7P8X0inh/+SDKeD/AgQr4v+aMJvQqv0D1G3+b5COdBH/J3kU8X8y+5fm/+bHUAr/p/B/ f4RayQr/txHl4f8y+r/Bto9qZ6inYzxC1eX/BoP/y5LVs//T06QH11EK01k7/Z/ro4ZqFupU /6flI6vL//l/SnX+L/v+f53B/+H/KL6I/9OO4x1W4vyfdv7v9r/9KPzf8cVd5fi/+Hlv/F96 Vvi/hG5FIf9nug/wf/LbRfzf/V0Q/u/PUIv+r9N1+r/wWeL/3oZW+L97hf+7lv9re/xfaij8 33ss/B/+D/+3Ggr/l5AV/i8x1JX8Xy+j4Zz+T7P/H/5vMRT+LzWtCv3fI9Sr/wsrEL/S/1lT zP/1Hf4v8gTi//B/S5/VWf7PlvN/5lr+z7ffEv7Puu9mr9D/haXt+L9/+z83xr+Q/wvo5Tv9 3+0n1/yfyyqv/9PF/J/7rM71f7fWndv/uUfjyf5PT/6WntX/mQ7/F5nV5/o/35FO9H+/I3z8 X9wJxP9Jhf/bGmolK/zfRpSH/8vo/6zMmFj/7mTv/n/zYzxC4f/wfwtZvez/Z92Oyc7/ybTg Tv/nVl6FSsmX353t/+S4+L+/RiL4v2P8X9e4We+s/s+NhfF/FAqFQqFQKBQKhUKhUCgUCoVC oVAoFAqFQqFQKJcr/wPmW/0FACjcAA== --------------020206010906060800060906-- From webmaster@rapidforum.com Mon Feb 21 16:11:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 16:11:24 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1M0BHc5006491 for ; Mon, 21 Feb 2005 16:11:18 -0800 Received: (qmail 7163 invoked by uid 1004); 22 Feb 2005 00:11:17 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 22 Feb 2005 00:11:17 -0000 Message-ID: <421A7886.8060302@rapidforum.com> Date: Tue, 22 Feb 2005 01:10:46 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: ARGH MORE BUGS!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> <20050221213610.GC26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221213610.GC26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 702 Lines: 22 I FOUND IT!!! At least I were able to track this down very far. It seems it only appears on Port 80. So might there be a problem if too many sockets are sharing the same port? In this case, port 80? What can I do now? The problem is still there. All 60 seconds a break for 5 seconds. I am not really willing to reboot anymore. So bug-hunters, please help. Francois Romieu wrote: > Christian Schmid : > >>I started it after one break-cyclus and stopped it immedately after the >>next break-cyclus ended. > > > I'd welcome several cycles to feed the data through gnuplot. > A sample based on 15 minutes or more would not hurt: I speak perl too. > > -- > Ueimor > > From romieu@fr.zoreil.com Mon Feb 21 16:23:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 16:23:47 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1M0Ngt9010819 for ; Mon, 21 Feb 2005 16:23:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1M0NK8w032565; Tue, 22 Feb 2005 01:23:20 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1M0NFnw032564; Tue, 22 Feb 2005 01:23:15 +0100 Date: Tue, 22 Feb 2005 01:23:15 +0100 From: Francois Romieu To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: argh more bugs!!! Message-ID: <20050222002315.GE26248@electric-eye.fr.zoreil.com> References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> <20050221213610.GC26248@electric-eye.fr.zoreil.com> <421A68D5.6020808@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A68D5.6020808@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1931 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: 1771 Lines: 33 Christian Schmid : > It suddenly appeared again. there you go.......... Thanks. I'll do some graphics tomorrow to be sure but the slabs do not seem wrong. vmstat output looks weird: procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 3 0 8496 25236 7941848 0 0 37920 0 7563 2788 13 19 34 33 2 2 0 9268 25172 7941300 0 0 36688 0 7424 2814 15 19 40 26 1 0 0 19576 25264 7928356 0 0 9468 13080 8072 607 22 13 59 6 1 0 0 18052 25264 7928356 0 0 0 0 7975 40 18 7 75 0 1 0 0 17660 25264 7928356 0 0 0 0 7487 38 21 4 75 0 1 0 0 18560 25264 7928356 0 0 0 0 6500 44 22 3 75 0 1 0 0 20072 25264 7928356 0 0 0 0 5834 44 23 2 75 0 1 3 0 21516 25320 7928300 0 0 0 3408 6796 153 24 3 58 15 0 4 0 10596 25436 7942056 0 0 44084 2220 11226 4282 12 10 31 47 2 2 0 9324 25240 7943952 0 0 39292 0 8433 3212 9 13 39 38 4 1 0 11596 25300 7941580 0 0 35820 0 7945 4306 17 21 30 32 0 5 0 13208 25560 7939280 0 0 40684 6456 7920 4081 19 18 32 31 4 1 0 12620 24944 7859724 0 0 32204 272 7306 2304 12 28 27 34 1 3 0 64964 24852 7888240 0 0 44944 96 7314 2631 19 31 24 27 ??? Since you have a lot of cpu, could you "strace -f -T -o /tmp/nitz -p xyz" one or two of your perl processes when they hang ? If you do not have too many processes, monitoring "echo t > /proc/sysrq-trigger" for some time could tell what the system is waiting for. -- Ueimor From jgarzik@pobox.com Mon Feb 21 16:27:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 16:27:18 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1M0RD3m011343 for ; Mon, 21 Feb 2005 16:27:13 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D3NtP-0004hk-BZ; Tue, 22 Feb 2005 00:27:11 +0000 Message-ID: <421A7C4E.6010404@pobox.com> Date: Mon, 21 Feb 2005 19:26:54 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: Re: [patch 2.6.11-rc4-netdev1 0/5] r8169: intro References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050221235125.GD26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1932 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: 224 Lines: 10 Francois Romieu wrote: > 2 - The current 2.6.11-rc4 r8169 driver would benefit from several patches > availables in your -netdev serie: It's far too late for all but the most critical (crash-level) patches... Jeff From webmaster@rapidforum.com Mon Feb 21 16:38:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 16:38:23 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1M0cHeY012110 for ; Mon, 21 Feb 2005 16:38:17 -0800 Received: (qmail 15103 invoked by uid 1004); 22 Feb 2005 00:38:17 -0000 Received: from p3ee0448c.dip0.t-ipconnect.de (HELO ?62.224.68.140?) (62.224.68.140) by www.rapidforum.com with SMTP; 22 Feb 2005 00:38:17 -0000 Message-ID: <421A7EDA.4090205@rapidforum.com> Date: Tue, 22 Feb 2005 01:37:46 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: argh more bugs!!! References: <421A3EB8.4050607@rapidforum.com> <20050221202854.GA26248@electric-eye.fr.zoreil.com> <421A45CA.80001@rapidforum.com> <20050221205606.GB26248@electric-eye.fr.zoreil.com> <421A4FFA.7090003@rapidforum.com> <20050221213610.GC26248@electric-eye.fr.zoreil.com> <421A68D5.6020808@rapidforum.com> <20050222002315.GE26248@electric-eye.fr.zoreil.com> In-Reply-To: <20050222002315.GE26248@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 2464 Lines: 46 OK the problem with the break is solved. I am REALLY sorry but it was not the net-code in linux. The SQL-Server has experienced an index-key collision as I added a second multi-key to it. It seems the sort-buffer overflowed and it suddenly raised the cpu-time very high. I will contact mysql-developers and ask them about it. The break was due to the table-lock mysql does for every update. The problem with the slowdown at many sockets still exists. This isnt solved yet. I hope this isnt my fault as well. Else I feel forced to spend 1000 dollars to some open-source foundation. *grin* Francois Romieu wrote: > Christian Schmid : > >>It suddenly appeared again. there you go.......... > > > Thanks. I'll do some graphics tomorrow to be sure but the slabs do not seem > wrong. vmstat output looks weird: > > procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- > r b swpd free buff cache si so bi bo in cs us sy id wa > 2 3 0 8496 25236 7941848 0 0 37920 0 7563 2788 13 19 34 33 > 2 2 0 9268 25172 7941300 0 0 36688 0 7424 2814 15 19 40 26 > 1 0 0 19576 25264 7928356 0 0 9468 13080 8072 607 22 13 59 6 > 1 0 0 18052 25264 7928356 0 0 0 0 7975 40 18 7 75 0 > 1 0 0 17660 25264 7928356 0 0 0 0 7487 38 21 4 75 0 > 1 0 0 18560 25264 7928356 0 0 0 0 6500 44 22 3 75 0 > 1 0 0 20072 25264 7928356 0 0 0 0 5834 44 23 2 75 0 > 1 3 0 21516 25320 7928300 0 0 0 3408 6796 153 24 3 58 15 > 0 4 0 10596 25436 7942056 0 0 44084 2220 11226 4282 12 10 31 47 > 2 2 0 9324 25240 7943952 0 0 39292 0 8433 3212 9 13 39 38 > 4 1 0 11596 25300 7941580 0 0 35820 0 7945 4306 17 21 30 32 > 0 5 0 13208 25560 7939280 0 0 40684 6456 7920 4081 19 18 32 31 > 4 1 0 12620 24944 7859724 0 0 32204 272 7306 2304 12 28 27 34 > 1 3 0 64964 24852 7888240 0 0 44944 96 7314 2631 19 31 24 27 > > ??? > > Since you have a lot of cpu, could you "strace -f -T -o /tmp/nitz -p xyz" one > or two of your perl processes when they hang ? > > If you do not have too many processes, monitoring "echo t > /proc/sysrq-trigger" > for some time could tell what the system is waiting for. > > -- > Ueimor > > From alex@neterion.com Mon Feb 21 16:52:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 16:52:10 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1M0q4K1013082 for ; Mon, 21 Feb 2005 16:52:04 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1M0pFdG025931; Mon, 21 Feb 2005 19:51:15 -0500 (EST) Received: from aaizmanlt ([10.16.16.164]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1M0pDDD020128; Mon, 21 Feb 2005 19:51:13 -0500 (EST) Message-Id: <200502220051.j1M0pDDD020128@guinness.s2io.com> Reply-To: From: "Alex Aizman" To: "'Jeff Garzik'" Cc: "'Andi Kleen'" , "'Leonid Grossman'" , "'rick jones'" , Subject: RE: Intel and TOE in the news Date: Mon, 21 Feb 2005 16:50:34 -0800 Organization: s2io MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <421A45DD.3020805@pobox.com> Thread-Index: AcUYVNM5SN6v/J2pRwaaNhu0rLY+DwAIyEcg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 814 Lines: 29 "Cookie" or no "cookie", demux in the OS or in the driver, does not matter (well, it matters just a little bit :). The important think is to run MSI handler on two (for starters) CPUs. Will check on it this week with 2.6.11. Alex > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Monday, February 21, 2005 12:35 PM > To: Alex Aizman > Cc: 'Andi Kleen'; 'Leonid Grossman'; 'rick jones'; netdev@oss.sgi.com > Subject: Re: Intel and TOE in the news > > Alex Aizman wrote: > > 2.6.11-rc4 MTHCA driver still does request_irq() just once for MSI > > (note: MSI, not MSI-X). > > > I doubt that will change. > > request_irq() is passed a "cookie" that enables your > interrupt handler. > This cookie can be associated with more than one interrupt vector. > > Jeff > > > From romieu@fr.zoreil.com Mon Feb 21 17:11:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Feb 2005 17:11:53 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1M1Bgb0014050 for ; Mon, 21 Feb 2005 17:11:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1M1ABvS000878; Tue, 22 Feb 2005 02:10:11 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1M1A5X6000877; Tue, 22 Feb 2005 02:10:05 +0100 Date: Tue, 22 Feb 2005 02:10:05 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: Re: [patch 2.6.11-rc4-netdev1 0/5] r8169: intro Message-ID: <20050222011005.GA32698@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <421A7C4E.6010404@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A7C4E.6010404@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1935 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: 335 Lines: 12 Jeff Garzik : > Francois Romieu wrote: > >2 - The current 2.6.11-rc4 r8169 driver would benefit from several patches > > availables in your -netdev serie: > > > It's far too late for all but the most critical (crash-level) patches... Fine with me. The "open after close" bug simply hangs the host. -- Ueimor From herbert@gondor.apana.org.au Tue Feb 22 01:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 01:58:56 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1M9wkv0007184 for ; Tue, 22 Feb 2005 01:58:47 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D3Wnx-0001oO-00; Tue, 22 Feb 2005 20:58:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D3Wn9-00071h-00; Tue, 22 Feb 2005 20:57:19 +1100 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: Frequent Oops on Shutdown 2.6.10 Cc: AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, yoshfuji@linux-ipv6.org Organization: Core In-Reply-To: <20050221.162949.65179228.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 22 Feb 2005 20:57:19 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 856 Lines: 21 YOSHIFUJI Hideaki / ???? wrote: > In article <20050221.162241.24618885.yoshfuji@linux-ipv6.org> (at Mon, 21 Feb 2005 16:22:41 +0900 (JST)), YOSHIFUJI Hideaki / ???? says: > >> [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. Sorry, but I don't see how this patch explains the oops the people saw. I googled for this oops and found three distinct occurences. They share the property that idev->stats.proc_dir_entry->name contains a bogus value. In two cases it had 0x5 and 0xa respectively, in the other it had 0x61696265. The last one could be an important clue. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Feb 22 02:17:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 02:17:13 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MAH4Xl008800 for ; Tue, 22 Feb 2005 02:17:05 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D3X5v-0001xo-00; Tue, 22 Feb 2005 21:16:43 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D3X4g-0001Wf-00; Tue, 22 Feb 2005 21:15:26 +1100 Date: Tue, 22 Feb 2005 21:15:26 +1100 To: YOSHIFUJI Hideaki / ???? Cc: AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org Subject: Re: Frequent Oops on Shutdown 2.6.10 Message-ID: <20050222101526.GA5814@gondor.apana.org.au> References: <20050221.162949.65179228.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1681 Lines: 48 On Tue, Feb 22, 2005 at 08:57:19PM +1100, Herbert Xu wrote: > YOSHIFUJI Hideaki / ???? wrote: > > In article <20050221.162241.24618885.yoshfuji@linux-ipv6.org> (at Mon, 21 Feb 2005 16:22:41 +0900 (JST)), YOSHIFUJI Hideaki / ???? says: > > > >> [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. > > Sorry, but I don't see how this patch explains the oops the > people saw. OK, I think I see what you were trying to fix now. Unfortunately I think this patch doesn't quite cure the problem. First of all you can't sleep in snmp6_unregister_dev so semaphores are out. More importantly, the race is still on. Here is what happens: CPU0 CPU1 ifdown eth0 ... ifup eth0 snmp6_register_dev adds proc entry in6_dev_finish_destroy snmp6_unregister_dev deletes new proc entry The next ifdown may fail because snmp6_unregister_dev will retrieve the name from a proc entry that's already been deleted. I see two solutions: 1) Unregister the proc entry earlier. In other words, do it in addrconf_ifdown. Since this is highly serialised it means that we can't add the new proc entry before the old proc entry has been deleted. 2) Fix procfs so that we delete by pointer instead of name. This makes sense from a semantic pointer of view. However, for this particular instance it means that we may have two "eth0" entries for as long as the old idev entry sticks around. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From AndyLiebman@aol.com Tue Feb 22 06:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 06:16:17 -0800 (PST) Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MEG4h1026420 for ; Tue, 22 Feb 2005 06:16:04 -0800 Received: from AndyLiebman@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.8.) id 7.110.440df51c (3924); Tue, 22 Feb 2005 09:15:00 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <110.440df51c.2f4c9863@aol.com> Date: Tue, 22 Feb 2005 09:14:59 EST Subject: Re: Frequent Oops on Shutdown 2.6.10 To: herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org CC: terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: netdev Content-Length: 2896 Lines: 75 For what it's worth, I believe I only get this Oops if I have unplugged an Ethernet cable while running the server. I have 4 Ethernet ports on the server -- and in fact I am testing and configuring many servers at the same time. All servers are set up with the exact same image, and the same set of IP addresses. Sometimes for convenience, I unplug an ethernet cable from one server and plug it into another server -- while they're running -- so that I can operate a machine remotely (I never connect more than one server to my network at a time, to avoid IP address conflicts). Unplugging and plugging Ethernet cables while running ALWAYS leads to nmbd errors on shutdown -- guaranteed -- but with the 2.6.6 kernel never an Oops. I only get an Oops with the 2.6.10 kernel. I'm going to do a more rigorous test today to see if the Oops behavior really is 100 percent correlated with unplugging and plugging the Ethernet cable. So, should I test the patch? Andy Liebman -------------------------------------------------------OLD MESSAGES BELOW -------- In a message dated 2/22/2005 5:17:19 A.M. Eastern Standard Time, herbert@gondor.apana.org.au writes: On Tue, Feb 22, 2005 at 08:57:19PM +1100, Herbert Xu wrote: > YOSHIFUJI Hideaki / ???? wrote: > > In article <20050221.162241.24618885.yoshfuji@linux-ipv6.org> (at Mon, 21 Feb 2005 16:22:41 +0900 (JST)), YOSHIFUJI Hideaki / ???? says: > > > >> [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. > > Sorry, but I don't see how this patch explains the oops the > people saw. OK, I think I see what you were trying to fix now. Unfortunately I think this patch doesn't quite cure the problem. First of all you can't sleep in snmp6_unregister_dev so semaphores are out. More importantly, the race is still on. Here is what happens: CPU0 CPU1 ifdown eth0 ... ifup eth0 snmp6_register_dev adds proc entry in6_dev_finish_destroy snmp6_unregister_dev deletes new proc entry The next ifdown may fail because snmp6_unregister_dev will retrieve the name from a proc entry that's already been deleted. I see two solutions: 1) Unregister the proc entry earlier. In other words, do it in addrconf_ifdown. Since this is highly serialised it means that we can't add the new proc entry before the old proc entry has been deleted. 2) Fix procfs so that we delete by pointer instead of name. This makes sense from a semantic pointer of view. However, for this particular instance it means that we may have two "eth0" entries for as long as the old idev entry sticks around. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jchapman@katalix.com Tue Feb 22 06:49:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 06:49:38 -0800 (PST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MEnSFP028442 for ; Tue, 22 Feb 2005 06:49:30 -0800 Received: from [84.92.108.75] (helo=[192.168.1.10]) by ptb-relay01.plus.net with esmtp (Exim) id 1D3bLi-00078j-4Q; Tue, 22 Feb 2005 14:49:18 +0000 Message-ID: <421B466C.4010902@katalix.com> Date: Tue, 22 Feb 2005 14:49:16 +0000 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Jeff Garzik CC: Netdev Subject: PATCH: add GigE PHY support to MII library Content-Type: multipart/mixed; boundary="------------040006030702040804040605" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 9274 Lines: 240 This is a multi-part message in MIME format. --------------040006030702040804040605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The attached patch adds support for GigE MII PHYs in the MII support library. This allows GigE drivers to use the MII library the same way 10/100 drivers do. Since the MII library is already used by lots of network drivers and the GigE MII register bit definitions were "reserved" when many 10/100 PHYs were designed, the new GigE registers are accessed only if a driver specifically enables it. Existing 10/100 drivers should see no behavior differences with this change. -- James Chapman PGP key : http://www.katalix.com/~jchapman/pgpkey.txt --------------040006030702040804040605 Content-Type: text/plain; name="mii.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mii.patch" --- linux-2.5-mv643xx-enet.orig/drivers/net/mii.c 2003-01-03 19:37:55.000000000 +0000 +++ linux-2.5-mv643xx-enet.new/drivers/net/mii.c 2005-02-22 12:31:16.000000000 +0000 @@ -37,6 +37,7 @@ { struct net_device *dev = mii->dev; u32 advert, bmcr, lpa, nego; + u32 advert2 = 0, bmcr2 = 0, lpa2 = 0; ecmd->supported = (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | @@ -54,6 +55,9 @@ ecmd->advertising = ADVERTISED_TP | ADVERTISED_MII; advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); + if (mii->supports_gmii) + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + if (advert & ADVERTISE_10HALF) ecmd->advertising |= ADVERTISED_10baseT_Half; if (advert & ADVERTISE_10FULL) @@ -62,19 +66,29 @@ ecmd->advertising |= ADVERTISED_100baseT_Half; if (advert & ADVERTISE_100FULL) ecmd->advertising |= ADVERTISED_100baseT_Full; + if (advert2 & ADVERTISE_1000HALF) + ecmd->advertising |= ADVERTISED_1000baseT_Half; + if (advert2 & ADVERTISE_1000FULL) + ecmd->advertising |= ADVERTISED_1000baseT_Full; bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); lpa = mii->mdio_read(dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) { + bmcr2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + lpa2 = mii->mdio_read(dev, mii->phy_id, MII_STAT1000); + } if (bmcr & BMCR_ANENABLE) { ecmd->advertising |= ADVERTISED_Autoneg; ecmd->autoneg = AUTONEG_ENABLE; nego = mii_nway_result(advert & lpa); - if (nego == LPA_100FULL || nego == LPA_100HALF) + if ((bmcr2 & (ADVERTISE_1000HALF | ADVERTISE_1000FULL)) & (lpa2 >> 2)) + ecmd->speed = SPEED_1000; + else if (nego == LPA_100FULL || nego == LPA_100HALF) ecmd->speed = SPEED_100; else ecmd->speed = SPEED_10; - if (nego == LPA_100FULL || nego == LPA_10FULL) { + if ((lpa2 & LPA_1000FULL) || nego == LPA_100FULL || nego == LPA_10FULL) { ecmd->duplex = DUPLEX_FULL; mii->full_duplex = 1; } else { @@ -84,7 +98,8 @@ } else { ecmd->autoneg = AUTONEG_DISABLE; - ecmd->speed = (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10; + ecmd->speed = ((bmcr2 & BMCR_SPEED1000 && (bmcr & BMCR_SPEED100) == 0) ? SPEED_1000 : + (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10); ecmd->duplex = (bmcr & BMCR_FULLDPLX) ? DUPLEX_FULL : DUPLEX_HALF; } @@ -97,7 +112,7 @@ { struct net_device *dev = mii->dev; - if (ecmd->speed != SPEED_10 && ecmd->speed != SPEED_100) + if (ecmd->speed != SPEED_10 && ecmd->speed != SPEED_100 && ecmd->speed != SPEED_1000) return -EINVAL; if (ecmd->duplex != DUPLEX_HALF && ecmd->duplex != DUPLEX_FULL) return -EINVAL; @@ -109,21 +124,30 @@ return -EINVAL; if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE) return -EINVAL; + if ((ecmd->speed == SPEED_1000) && (!mii->supports_gmii)) + return -EINVAL; /* ignore supported, maxtxpkt, maxrxpkt */ if (ecmd->autoneg == AUTONEG_ENABLE) { u32 bmcr, advert, tmp; + u32 advert2 = 0, tmp2 = 0; if ((ecmd->advertising & (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | ADVERTISED_100baseT_Half | - ADVERTISED_100baseT_Full)) == 0) + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Half | + ADVERTISED_1000baseT_Full)) == 0) return -EINVAL; /* advertise only what has been requested */ advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); tmp = advert & ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (mii->supports_gmii) { + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + tmp2 = advert2 & ~(ADVERTISE_1000HALF | ADVERTISE_1000FULL); + } if (ecmd->advertising & ADVERTISED_10baseT_Half) tmp |= ADVERTISE_10HALF; if (ecmd->advertising & ADVERTISED_10baseT_Full) @@ -132,10 +156,18 @@ tmp |= ADVERTISE_100HALF; if (ecmd->advertising & ADVERTISED_100baseT_Full) tmp |= ADVERTISE_100FULL; + if (mii->supports_gmii) { + if (ecmd->advertising & ADVERTISED_1000baseT_Half) + advert2 |= ADVERTISE_1000HALF; + if (ecmd->advertising & ADVERTISED_1000baseT_Full) + advert2 |= ADVERTISE_1000FULL; + } if (advert != tmp) { mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, tmp); mii->advertising = tmp; } + if ((mii->supports_gmii) && (advert2 != tmp2)) + mii->mdio_write(dev, mii->phy_id, MII_CTRL1000, tmp2); /* turn on autonegotiation, and force a renegotiate */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); @@ -148,8 +180,10 @@ /* turn off auto negotiation, set speed and duplexity */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); - tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX); - if (ecmd->speed == SPEED_100) + tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | BMCR_SPEED1000 | BMCR_FULLDPLX); + if (ecmd->speed == SPEED_1000) + tmp |= BMCR_SPEED1000; + else if (ecmd->speed == SPEED_100) tmp |= BMCR_SPEED100; if (ecmd->duplex == DUPLEX_FULL) { tmp |= BMCR_FULLDPLX; @@ -207,6 +241,7 @@ { unsigned int old_carrier, new_carrier; int advertise, lpa, media, duplex; + int lpa2 = 0; /* if forced media, go no further */ if (mii->force_media) @@ -243,17 +278,21 @@ mii->advertising = advertise; } lpa = mii->mdio_read(mii->dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) + lpa2 = mii->mdio_read(mii->dev, mii->phy_id, MII_STAT1000); /* figure out media and duplex from advertise and LPA values */ media = mii_nway_result(lpa & advertise); duplex = (media & ADVERTISE_FULL) ? 1 : 0; + if (lpa2 & LPA_1000FULL) + duplex = 1; if (ok_to_print) printk(KERN_INFO "%s: link up, %sMbps, %s-duplex, lpa 0x%04X\n", mii->dev->name, - media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? - "100" : "10", + lpa2 & (LPA_1000FULL | LPA_1000HALF) ? "1000" : + media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? "100" : "10", duplex ? "full" : "half", lpa); --- linux-2.5-mv643xx-enet.orig/include/linux/mii.h 2004-08-22 21:57:31.000000000 +0100 +++ linux-2.5-mv643xx-enet.new/include/linux/mii.h 2005-02-22 12:18:11.000000000 +0000 @@ -20,6 +20,8 @@ #define MII_ADVERTISE 0x04 /* Advertisement control reg */ #define MII_LPA 0x05 /* Link partner ability reg */ #define MII_EXPANSION 0x06 /* Expansion register */ +#define MII_CTRL1000 0x09 /* 1000BASE-T control */ +#define MII_STAT1000 0x0a /* 1000BASE-T status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -84,7 +86,8 @@ #define LPA_100HALF 0x0080 /* Can do 100mbps half-duplex */ #define LPA_100FULL 0x0100 /* Can do 100mbps full-duplex */ #define LPA_100BASE4 0x0200 /* Can do 100mbps 4k packets */ -#define LPA_RESV 0x1c00 /* Unused... */ +#define LPA_PAUSE 0x0400 +#define LPA_RESV 0x1800 /* Unused... */ #define LPA_RFAULT 0x2000 /* Link partner faulted */ #define LPA_LPACK 0x4000 /* Link partner acked us */ #define LPA_NPAGE 0x8000 /* Next page bit */ @@ -105,6 +108,15 @@ #define NWAYTEST_LOOPBACK 0x0100 /* Enable loopback for N-way */ #define NWAYTEST_RESV2 0xfe00 /* Unused... */ +/* 1000BASE-T Control register */ +#define ADVERTISE_1000FULL 0x0200 /* Advertise 1000BASE-T full duplex */ +#define ADVERTISE_1000HALF 0x0100 /* Advertise 1000BASE-T half duplex */ + +/* 1000BASE-T Status register */ +#define LPA_1000LOCALRXOK 0x2000 /* Link partner local receiver status */ +#define LPA_1000REMRXOK 0x1000 /* Link partner remote receiver status */ +#define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */ +#define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */ struct mii_if_info { int phy_id; @@ -114,6 +126,7 @@ unsigned int full_duplex : 1; /* is full duplex? */ unsigned int force_media : 1; /* is autoneg. disabled? */ + unsigned int supports_gmii : 1; /* are GMII registers supported? */ struct net_device *dev; int (*mdio_read) (struct net_device *dev, int phy_id, int location); --------------040006030702040804040605-- From webmaster@rapidforum.com Tue Feb 22 07:08:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 07:08:12 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MF87EK030543 for ; Tue, 22 Feb 2005 07:08:08 -0800 Received: (qmail 32298 invoked by uid 1004); 22 Feb 2005 15:08:06 -0000 Received: from p3ee04891.dip0.t-ipconnect.de (HELO ?62.224.72.145?) (62.224.72.145) by www.rapidforum.com with SMTP; 22 Feb 2005 15:08:06 -0000 Message-ID: <421B4AB7.9030003@rapidforum.com> Date: Tue, 22 Feb 2005 16:07:35 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Bug-hunting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 442 Lines: 9 Hello. I am still trying to hunt down the bug with the slowdown-on-many-sockets. Is there any way I can see how much tcp-memory is used right now? Why did you change the behaviour? In 2.6.10-rc2 I was able to see the amount by looking in slabinfo but now the buffers are gone. And where did you introduce the buffer-limit? It seems its now globally limited to xxx MB. I want to disable this in order to check if thats the reason. Chris From Robert.Olsson@data.slu.se Tue Feb 22 07:41:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 07:42:01 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MFftSj000372 for ; Tue, 22 Feb 2005 07:41:56 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j1MFfVwe031089; Tue, 22 Feb 2005 16:41:31 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 33BF3EE2A4; Tue, 22 Feb 2005 16:41:31 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16923.21163.112945.608974@robur.slu.se> Date: Tue, 22 Feb 2005 16:41:31 +0100 To: davem@davemloft.net Cc: "Randy.Dunlap" , Robert Olsson , Francois Romieu , netdev Subject: Re: [PATCH] pktgen: reduce stack usage In-Reply-To: <421A0880.5070205@osdl.org> References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> <42166E3F.2050304@osdl.org> <16921.60572.951532.31861@robur.slu.se> <421A0880.5070205@osdl.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1941 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: 3003 Lines: 109 Randy.Dunlap writes: > > Here is version with just one buffer. > > Yep, even better: few changes + using sizeof. Hello. OK! Then we ask DaveM to apply the patch. --ro --- net/core/pktgen.c.050221 2005-02-21 14:02:40.000000000 +0100 +++ net/core/pktgen.c 2005-02-21 15:02:44.000000000 +0100 @@ -151,7 +151,7 @@ #include -#define VERSION "pktgen v2.57: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -811,6 +811,7 @@ struct pktgen_dev *pkt_dev = (struct pktgen_dev*)(data); char* pg_result = NULL; int tmp = 0; + char buf[128]; pg_result = &(pkt_dev->result[0]); @@ -1071,7 +1072,6 @@ return count; } if (!strcmp(name, "dst_min") || !strcmp(name, "dst")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_min) - 1); if (len < 0) { return len; } @@ -1091,7 +1091,6 @@ return count; } if (!strcmp(name, "dst_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->dst_max) - 1); if (len < 0) { return len; } @@ -1112,9 +1111,7 @@ return count; } if (!strcmp(name, "dst6")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1136,9 +1133,7 @@ return count; } if (!strcmp(name, "dst6_min")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1159,9 +1154,7 @@ return count; } if (!strcmp(name, "dst6_max")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1181,9 +1174,7 @@ return count; } if (!strcmp(name, "src6")) { - char buf[128]; - - len = strn_len(&user_buffer[i], 128 - 1); + len = strn_len(&user_buffer[i], sizeof(buf) - 1); if (len < 0) return len; pkt_dev->flags |= F_IPV6; @@ -1205,7 +1196,6 @@ return count; } if (!strcmp(name, "src_min")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_min) - 1); if (len < 0) { return len; } if (copy_from_user(buf, &user_buffer[i], len)) @@ -1224,7 +1214,6 @@ return count; } if (!strcmp(name, "src_max")) { - char buf[IP_NAME_SZ]; len = strn_len(&user_buffer[i], sizeof(pkt_dev->src_max) - 1); if (len < 0) { return len; } if (copy_from_user(buf, &user_buffer[i], len)) From ak@muc.de Tue Feb 22 09:27:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 09:27:37 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MHRVDb008526 for ; Tue, 22 Feb 2005 09:27:32 -0800 Received: (qmail 77451 invoked by uid 3709); 22 Feb 2005 17:27:29 -0000 Date: 22 Feb 2005 18:27:29 +0100 Date: Tue, 22 Feb 2005 18:27:29 +0100 From: Andi Kleen To: Leonid Grossman Cc: hadi@cyberus.ca, "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050222172729.GA70246@muc.de> References: <1108993498.1089.149.camel@jzny.localdomain> <200502211653.j1LGr3DD025897@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502211653.j1LGr3DD025897@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1942 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: 1384 Lines: 32 On Mon, Feb 21, 2005 at 08:52:13AM -0800, Leonid Grossman wrote: > Yes, the question was with regards to the burst of random packets. > I agree that this may be not too useful and arguably doesn't warrant the > significant stack change. The reason I asked is that one of our engineers > was under impression (from reading Linux TCP/IP Stack book) that the feature > is already supported. There is some support to process list of skbs, but it's only used for IP fragments belonging to the same IP packet; and is also only valid for some small parts of the stack between IP and transport layer. The only IP protocols that support it are UDP and RAW. TCP doesn't support it; or rather it would always try to reassemble them first. In short it's a hack to avoid one copy of data for NFS over fragmented UDP. I guess he thought it was a more general facility or the author of the book didn't make it clear enough that it was a quite special case hack. > WRT to the burst of packets related to the same flow - we are hoping to be > able to collapse the burst into a single oversized frame and pass it to the > stack, this way no or very minimal changes to the stack will be needed. > There is enough intelligence on the NIC to do that efficiently, we just need > to try and see how well this works. Hopefully you don't need too many cache misses to figure this out though. -Andi From shemminger@osdl.org Tue Feb 22 10:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 10:03:10 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MI33cL011332 for ; Tue, 22 Feb 2005 10:03:04 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1MI2Eqi017563 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 10:02:15 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1MI2Ecf018165; Tue, 22 Feb 2005 10:02:14 -0800 Date: Tue, 22 Feb 2005 10:02:27 -0800 From: Stephen Hemminger To: "Leonid Grossman" Cc: , "'Leonid Grossman'" , "'Andi Kleen'" , "'rick jones'" , , "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050222100227.7ea76f2c@dxpl.pdx.osdl.net> In-Reply-To: <200502211803.j1LI3cDD009072@guinness.s2io.com> References: <1109005880.1076.77.camel@jzny.localdomain> <200502211803.j1LI3cDD009072@guinness.s2io.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1943 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: 1947 Lines: 42 On Mon, 21 Feb 2005 10:02:47 -0800 "Leonid Grossman" wrote: > > > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > Sent: Monday, February 21, 2005 9:11 AM > > To: Leonid Grossman > > Cc: 'Andi Kleen'; 'rick jones'; netdev@oss.sgi.com; 'Alex Aizman' > > Subject: RE: Intel and TOE in the news > > > > On Mon, 2005-02-21 at 11:52, Leonid Grossman wrote: > > > > > > WRT to the burst of packets related to the same flow - we > > are hoping > > > to be able to collapse the burst into a single oversized frame and > > > pass it to the stack, this way no or very minimal changes > > to the stack will be needed. > > > There is enough intelligence on the NIC to do that efficiently, we > > > just need to try and see how well this works. > > > > Indeed, would be nice to see what you come up with. I think > > there may be value in sending one huge chunk packet which > > itself is actually a collection of several independet packets > > when you have a huge amount of small packets. The benefit > > being you amortize the cost of DMA setup. > > But then you may need to be able to break them down in the > > driver; is this what you are talking about? > > Pretty much. Actually the ASIC separates the headers so the driver doesn't > need to break packets down. > The driver just chains the payload (for several packets from a same-flow > burst) and builds the header for this single oversized frame. Kind of > inversed TSO, but on receive side. > We are going to post an experimental driver code in 2-3 weeks, along with > this "Large Receive Offload" algorithm, for review. Be careful, this may have the same problems that original TSO code did. Make sure and force the PUSH flag on these jumbo receives or the TCP "every other segment" ACK logic will be busted. There are other parts of TCP that depend on packet count as well and this inverse TSO logic will break them. From ak@muc.de Tue Feb 22 10:07:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 10:07:16 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MI7BRg011963 for ; Tue, 22 Feb 2005 10:07:12 -0800 Received: (qmail 90929 invoked by uid 3709); 22 Feb 2005 18:07:11 -0000 Date: 22 Feb 2005 19:07:11 +0100 Date: Tue, 22 Feb 2005 19:07:11 +0100 From: Andi Kleen To: Stephen Hemminger Cc: Leonid Grossman , hadi@cyberus.ca, "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050222180711.GA84438@muc.de> References: <1109005880.1076.77.camel@jzny.localdomain> <200502211803.j1LI3cDD009072@guinness.s2io.com> <20050222100227.7ea76f2c@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222100227.7ea76f2c@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1944 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: 556 Lines: 12 > Be careful, this may have the same problems that original TSO code did. > Make sure and force the PUSH flag on these jumbo receives or the TCP > "every other segment" ACK logic will be busted. There are other parts of TCP > that depend on packet count as well and this inverse TSO logic will break them. Linux TCP RX path didn't care about PSH last time I checked. It should make no difference how PSH is set on RX or if it is set at all. At least unless Leonid wants to run his driver on Darwin too, but that would be someone else's problem. -Andi From davem@davemloft.net Tue Feb 22 10:45:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 10:45:35 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MIjTaC014755 for ; Tue, 22 Feb 2005 10:45:30 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D3f1c-0000zJ-00; Tue, 22 Feb 2005 10:44:48 -0800 Date: Tue, 22 Feb 2005 10:44:48 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Bug-hunting Message-Id: <20050222104448.31373a99.davem@davemloft.net> In-Reply-To: <421B4AB7.9030003@rapidforum.com> References: <421B4AB7.9030003@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 619 Lines: 11 On Tue, 22 Feb 2005 16:07:35 +0100 Christian Schmid wrote: > I am still trying to hunt down the bug with the slowdown-on-many-sockets. Is there any way I can see > how much tcp-memory is used right now? Why did you change the behaviour? In 2.6.10-rc2 I was able to > see the amount by looking in slabinfo but now the buffers are gone. And where did you introduce the > buffer-limit? It seems its now globally limited to xxx MB. I want to disable this in order to check > if thats the reason. The global TCP memory limit, controllable by sysctl()'s, has been there for at least 3 years. From webmaster@rapidforum.com Tue Feb 22 11:18:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 11:18:34 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MJIRZH019412 for ; Tue, 22 Feb 2005 11:18:27 -0800 Received: (qmail 16949 invoked by uid 1004); 22 Feb 2005 19:18:26 -0000 Received: from p3ee04891.dip0.t-ipconnect.de (HELO ?62.224.72.145?) (62.224.72.145) by www.rapidforum.com with SMTP; 22 Feb 2005 19:18:26 -0000 Message-ID: <421B8563.9030608@rapidforum.com> Date: Tue, 22 Feb 2005 20:17:55 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> In-Reply-To: <20050222104448.31373a99.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 21 No. This is a new thing and this wasnt there before. In 2.6.10-rc2 the kernel aborted programs with "Out of memory" when too many buffers are allocated and low memory was full. NOW it just shrinks the buffers dynamically. I don't want that. I have a 2/2 system and I want 1600 MB for buffers but you only allow around 700 MB for buffers. This is definetly NEW. David S. Miller wrote: > On Tue, 22 Feb 2005 16:07:35 +0100 > Christian Schmid wrote: > > >>I am still trying to hunt down the bug with the slowdown-on-many-sockets. Is there any way I can see >>how much tcp-memory is used right now? Why did you change the behaviour? In 2.6.10-rc2 I was able to >>see the amount by looking in slabinfo but now the buffers are gone. And where did you introduce the >>buffer-limit? It seems its now globally limited to xxx MB. I want to disable this in order to check >>if thats the reason. > > > The global TCP memory limit, controllable by sysctl()'s, has been there for > at least 3 years. > > From akpm@osdl.org Tue Feb 22 11:33:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 11:33:14 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MJX8n6020575 for ; Tue, 22 Feb 2005 11:33:08 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1MJWsqi027414 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 11:32:55 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1MJWrOb021964; Tue, 22 Feb 2005 11:32:54 -0800 Date: Tue, 22 Feb 2005 11:32:40 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: agulati@nextone.com Subject: Fw: [Bugme-new] [Bug 4239] New: ARP sent with wrong MAC address Message-Id: <20050222113240.5e886c6a.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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1947 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: 1439 Lines: 44 Begin forwarded message: Date: Tue, 22 Feb 2005 07:31:58 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4239] New: ARP sent with wrong MAC address http://bugme.osdl.org/show_bug.cgi?id=4239 Summary: ARP sent with wrong MAC address Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: agulati@nextone.com Distribution: Hardware Environment: P4 Software Environment: 2.6.10 Problem Description: Turning ARP OFF and sending something out from that interface creates a NOARP entry in the ARP table which does not go away when you turn ARP back ON. ip link set eth0 arp off ping -I eth0 1.1.1.1 (creates ARP entry with own MAC address -- 1.1.1.1 dev eth0 lladdr nud noarp) This entry in arp table with 'nud noarp', stays there even after turning ARP on. ip link set eth0 arp on And ping 1.1.1.1 doesn't work after that since it considers that 'nud noarp' entry as valid and doesn't send ARP request but sends an ICMP request to its own MAC address! Shouldn't that entry be removed after enabling ARP on eth0? If not, is there a way to remove that entry (I tried 'ip -statistics neigh flush dev eth0 nud noarp', but that goes in a loop) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From davem@davemloft.net Tue Feb 22 11:51:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 11:52:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MJpvSS021934 for ; Tue, 22 Feb 2005 11:51:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D3g3u-0001M3-00; Tue, 22 Feb 2005 11:51:14 -0800 Date: Tue, 22 Feb 2005 11:51:14 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Bug-hunting Message-Id: <20050222115114.0d0e568e.davem@davemloft.net> In-Reply-To: <421B8563.9030608@rapidforum.com> References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1479 Lines: 30 On Tue, 22 Feb 2005 20:17:55 +0100 Christian Schmid wrote: > No. This is a new thing and this wasnt there before. In 2.6.10-rc2 the kernel aborted programs with > "Out of memory" when too many buffers are allocated and low memory was full. NOW it just shrinks the > buffers dynamically. I don't want that. I have a 2/2 system and I want 1600 MB for buffers but you > only allow around 700 MB for buffers. This is definetly NEW. It always shrinks the TCP socket buffer usage when the total socket memory used by TCP is over the threshold. This code has been there for 3 years at least. If the behavior has changed, that's interesting and probably due to some other change. It could even be a MM layer change that is causing things to behave differently now for you, and because things are being tweaked in the memory management all the time (particularly the handling of lowmem vs. highmem) this would not surprise me at all. But the basic framework for shrinking socket buffers when total TCP memory usage crosses some threshold has been there and has been enabled for a long time. Anyways, we're stalled on figuring out exactly what is wrong due to lack of information and difficulty in reproducing. The ball is still in your court. Why don't you put together a very simple test case that others can use to analyze and reproduce your bug? I bet we'll fix it or figure out what is wrong with your app within 24 hours once you do that. :-) From leonid.grossman@neterion.com Tue Feb 22 12:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 12:54:22 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MKsDbn028343 for ; Tue, 22 Feb 2005 12:54:14 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1MKqddG002360; Tue, 22 Feb 2005 15:52:39 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1MKqaDD022407; Tue, 22 Feb 2005 15:52:37 -0500 (EST) Message-Id: <200502222052.j1MKqaDD022407@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'Stephen Hemminger'" Cc: "'Leonid Grossman'" , , "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Tue, 22 Feb 2005 12:51:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZCVRS5Rx0lHkCTVirPnPtn7fRGQAE9dhA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050222180711.GA84438@muc.de> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1345 Lines: 40 > -----Original Message----- > From: Andi Kleen [mailto:ak@muc.de] > Sent: Tuesday, February 22, 2005 10:07 AM > To: Stephen Hemminger > Cc: Leonid Grossman; hadi@cyberus.ca; 'rick jones'; > netdev@oss.sgi.com; 'Alex Aizman' > Subject: Re: Intel and TOE in the news > > > Be careful, this may have the same problems that original > TSO code did. > > Make sure and force the PUSH flag on these jumbo receives > or the TCP > > "every other segment" ACK logic will be busted. There are > other parts of TCP > > that depend on packet count as well and this inverse TSO > logic will break them. TSO case is probably different - TSO hardware just sets PSH on the last fragment only (and only if the flag was set on the original large tx packet). Receiver doesn't really know if the sender is TSO-capable or not and will ACK the same way - will it not? Anyway, with LRO we do change rx packet count so affecting parts of TCP that depend on packet count is indeed a concern; I guess we'll find out soon enough whether there are real issues with the approach :-) Leonid > > Linux TCP RX path didn't care about PSH last time I checked. > It should make no difference how PSH is set on RX or if it is > set at all. At least unless Leonid wants to run his driver on > Darwin too, but that would be someone else's problem. > > -Andi > From rick.jones2@hp.com Tue Feb 22 13:20:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:20:09 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MLK51E030217 for ; Tue, 22 Feb 2005 13:20:05 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 5A39C40036F for ; Tue, 22 Feb 2005 13:20:05 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA27735 for ; Tue, 22 Feb 2005 13:20:04 -0800 (PST) Message-ID: <421BA204.704@hp.com> Date: Tue, 22 Feb 2005 13:20:04 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <200502222052.j1MKqaDD022407@guinness.s2io.com> In-Reply-To: <200502222052.j1MKqaDD022407@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 344 Lines: 8 I always thought the biggest issue with "RSO" would be deciding how long to wait for another segment to paste-in with the rest? rick jones all the previous talk about header/data split makes me wax nostalgic for the FDDI adaptors of the late 80's and early 90's that did that - back when MTU's were >= page size and life was good :) :) :) From leonid.grossman@neterion.com Tue Feb 22 13:31:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:31:39 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MLVZYj031339 for ; Tue, 22 Feb 2005 13:31:35 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1MLVIdG002580; Tue, 22 Feb 2005 16:31:18 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1MLVHDD029755; Tue, 22 Feb 2005 16:31:17 -0500 (EST) Message-Id: <200502222131.j1MLVHDD029755@guinness.s2io.com> From: "Leonid Grossman" To: "'Rick Jones'" , Subject: RE: Intel and TOE in the news Date: Tue, 22 Feb 2005 13:30:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZJEu7VEX5UZd5TYabcPLjEhMPogAAPYRA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <421BA204.704@hp.com> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 774 Lines: 26 No wait, "paste in" only packets that are already received when a traffic interrupt comes... At 10GbE, the entire window will likely be sitting there :-) Leonid > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Rick Jones > Sent: Tuesday, February 22, 2005 1:20 PM > To: netdev@oss.sgi.com > Subject: Re: Intel and TOE in the news > > I always thought the biggest issue with "RSO" would be > deciding how long to wait for another segment to paste-in > with the rest? > > rick jones > > all the previous talk about header/data split makes me wax > nostalgic for the FDDI adaptors of the late 80's and early > 90's that did that - back when MTU's were >= page size and > life was good :) :) :) > > From dan@coverfire.com Tue Feb 22 13:41:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:41:24 -0800 (PST) Received: from otis.cyg.net (otis.cyg.net [69.41.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MLfI7k032276 for ; Tue, 22 Feb 2005 13:41:18 -0800 Received: from ganymede.coverfire.com (ganymede.coverfire.com [69.41.199.10]) (authenticated bits=0) by otis.cyg.net (8.12.11/8.12.11) with ESMTP id j1MLeeL1005141; Tue, 22 Feb 2005 16:40:40 -0500 Subject: Re: [RFC] batched tc to improve change throughput From: Dan Siemon To: Thomas Graf Cc: hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20050215204723.GM31837@postel.suug.ch> References: <1106576005.1652.1292.camel@jzny.localdomain> <20050124150634.GT23931@postel.suug.ch> <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> <1108340618.14978.66.camel@ganymede> <20050214142710.GI31837@postel.suug.ch> <1108499294.5465.22.camel@ganymede> <20050215204723.GM31837@postel.suug.ch> Content-Type: text/plain Date: Tue, 22 Feb 2005 16:40:40 -0500 Message-Id: <1109108440.5712.17.camel@ganymede> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 69.41.192.10 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dan@coverfire.com Precedence: bulk X-list: netdev Content-Length: 1405 Lines: 36 Sorry, for the tardy response. On Tue, 2005-15-02 at 21:47 +0100, Thomas Graf wrote: > I see, well I can extend my objects, I'm even willing to change the > architecture if needed. The only requirements from my side is to > keep the generic caching header to allow putting these objects into > generic caches and keep it simple to readd commit/rollback extesions > later on. > > What is exactly required to make it GObject aware? I've never worked > with GOBject so far. Basically a qdisc looks like this at the moment: > > struct rtnl_qdisc > { > NLHDR_COMMON; /* common fields required by cache */ > NL_TCA_GENERIC(q); /* generic tc fields (parent, handle, ifindex ...) */ > void *opts; /* qdisc specific options (e.g. rtnl_sch_fifo) */ > }; > > The NLHDR_COMMON must stay first, the ordering of the others doesn't > matter. That could be a problem. The GObject struct must be at the start so that all sub-classes can be operated on with the g_object_ functions. The only way to make these objects work with your caching scheme would be to make a sub-class of GObject with the caching information. This would have the benefit of adding ref counting etc. The following URL will give you a bit of background on GObject. http://www.le-hacker.org/papers/gobject/ -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 From rick.jones2@hp.com Tue Feb 22 13:42:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:42:30 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MLgQ9W032696 for ; Tue, 22 Feb 2005 13:42:26 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id 3746E1C11CA6 for ; Tue, 22 Feb 2005 13:42:26 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA27911 for ; Tue, 22 Feb 2005 13:42:25 -0800 (PST) Message-ID: <421BA741.4050201@hp.com> Date: Tue, 22 Feb 2005 13:42:25 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: Intel and TOE in the news References: <200502222131.j1MLVHDD029755@guinness.s2io.com> In-Reply-To: <200502222131.j1MLVHDD029755@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 341 Lines: 10 Leonid Grossman wrote: > No wait, "paste in" only packets that are already received when a traffic > interrupt comes... Ah, so it is ass-u-me-ing that there is little or no packet loss? How about when the driver is polling instead of taking interrupts? Will the driver "see" the RSO segment-in-progress or will it be hidden? rick jones From ak@muc.de Tue Feb 22 13:43:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:43:52 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MLhlJE000971 for ; Tue, 22 Feb 2005 13:43:48 -0800 Received: (qmail 52996 invoked by uid 3709); 22 Feb 2005 21:43:45 -0000 Date: 22 Feb 2005 22:43:45 +0100 Date: Tue, 22 Feb 2005 22:43:45 +0100 From: Andi Kleen To: Leonid Grossman Cc: "'Stephen Hemminger'" , hadi@cyberus.ca, "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050222214345.GA51890@muc.de> References: <20050222180711.GA84438@muc.de> <200502222052.j1MKqaDD022407@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502222052.j1MKqaDD022407@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1954 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: 973 Lines: 21 > TSO case is probably different - TSO hardware just sets PSH on the last > fragment only (and only if the flag was set on the original large tx > packet). Receiver doesn't really know if the sender is TSO-capable or not > and will ACK the same way - will it not? > Anyway, with LRO we do change rx packet count so affecting parts of TCP that > depend on packet count is indeed a concern; I guess we'll find out soon > enough whether there are real issues with the approach :-) Linux doesn't depend on packet count; it keeps an estimate called rcv_mss about the biggest seen packet size and acks every 2*rcv_mss worth of data. Your scheme would likely result in acking every two of your large packets as soon as the connection is out of "quickack" mode. So there would be on wire differences. > > Linux TCP RX path didn't care about PSH last time I checked. Actually it does for measuring the rcv_mss for very small MTUs. Shouldn't matter in practice though. -Andi From shemminger@osdl.org Tue Feb 22 13:51:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 13:51:22 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MLpIOr002022 for ; Tue, 22 Feb 2005 13:51:18 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1MLoXqi009984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 13:50:34 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1MLoWJb028724; Tue, 22 Feb 2005 13:50:32 -0800 Date: Tue, 22 Feb 2005 13:50:46 -0800 From: Stephen Hemminger To: Hubert Tonneau , cliff white Cc: Alexey Kuznetsov , netdev@oss.sgi.com, Injong Rhee , "David S. Miller" Subject: [RFT] BIC TCP delayed ack compensation Message-ID: <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> In-Reply-To: <20050209105909.17da40a9@dxpl.pdx.osdl.net> References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1955 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: 2429 Lines: 76 This patch which was extracted from BIC TCP 1.1 compensates for systems (like MaxOSX) that don't ACK every other packet. It has no impact for normal transfers, but might help with problems with Mac like Hubert found. diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2005-02-22 13:44:12 -08:00 +++ b/include/linux/tcp.h 2005-02-22 13:44:12 -08:00 @@ -433,6 +433,7 @@ __u32 last_max_cwnd; /* last maximium snd_cwnd */ __u32 last_cwnd; /* the last snd_cwnd */ __u32 last_stamp; /* time when updated last_cwnd */ + __u32 delayed_ack; /* ratio of packets/ACKs */ } bictcp; }; diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2005-02-22 13:44:12 -08:00 +++ b/include/net/tcp.h 2005-02-22 13:44:12 -08:00 @@ -508,6 +508,8 @@ #define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation * max_cwnd = snd_cwnd * beta */ +#define BICTCP_DELAY_SCALE 1024 /* Scale for delayed_ack ratio */ + #define BICTCP_MAX_INCREMENT 32 /* * Limit on the amount of * increment allowed during diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2005-02-22 13:44:12 -08:00 +++ b/net/ipv4/tcp_input.c 2005-02-22 13:44:12 -08:00 @@ -339,6 +339,7 @@ tp->bictcp.last_max_cwnd = 0; tp->bictcp.last_cwnd = 0; tp->bictcp.last_stamp = 0; + tp->bictcp.delayed_ack = 2 * BICTCP_DELAY_SCALE; } /* 5. Recalculate window clamp after socket hit its memory bounds. */ @@ -2075,6 +2076,13 @@ /* linear increase */ tp->bictcp.cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; } + + /* compensate for delayed ack's */ + tp->bictcp.cnt = (tp->bictcp.cnt * BICTCP_DELAY_SCALE) + / tp->bictcp.delayed_ack; + if (tp->bictcp.cnt == 0) + tp->bictcp.cnt = 1; + return tp->bictcp.cnt; } @@ -2418,6 +2426,7 @@ __u32 now = tcp_time_stamp; int acked = 0; __s32 seq_rtt = -1; + __u32 cnt = 0; while ((skb = skb_peek(&sk->sk_write_queue)) && skb != sk->sk_send_head) { @@ -2472,7 +2481,13 @@ tcp_packets_out_dec(tp, skb); __skb_unlink(skb, skb->list); sk_stream_free_skb(sk, skb); + ++cnt; } + + /* compute average packets per ACK (scaled by 1024) */ + if (cnt > 0 && tcp_is_bic(tp) && tp->ca_state == TCP_CA_Open) + tp->bictcp.delayed_ack = (15 * tp->bictcp.delayed_ack) / 16 + + (BICTCP_DELAY_SCALE/16) * cnt; if (acked&FLAG_ACKED) { tcp_ack_update_rtt(tp, acked, seq_rtt); From tgraf@suug.ch Tue Feb 22 15:15:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:15:51 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNFaO6001032 for ; Tue, 22 Feb 2005 15:15:42 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 64EC682; Wed, 23 Feb 2005 00:15:11 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4CA141C0EA; Wed, 23 Feb 2005 00:15:54 +0100 (CET) Date: Wed, 23 Feb 2005 00:15:54 +0100 From: Thomas Graf To: Dan Siemon Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050222231554.GH31837@postel.suug.ch> References: <1106747313.1107.7.camel@jzny.localdomain> <1108134446.5523.22.camel@ganymede> <1108215923.1126.132.camel@jzny.localdomain> <1108246033.7554.18.camel@ganymede> <20050212223204.GG31837@postel.suug.ch> <1108340618.14978.66.camel@ganymede> <20050214142710.GI31837@postel.suug.ch> <1108499294.5465.22.camel@ganymede> <20050215204723.GM31837@postel.suug.ch> <1109108440.5712.17.camel@ganymede> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109108440.5712.17.camel@ganymede> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 595 Lines: 12 > > The NLHDR_COMMON must stay first, the ordering of the others doesn't > > matter. > > That could be a problem. The GObject struct must be at the start so > that all sub-classes can be operated on with the g_object_ functions. > The only way to make these objects work with your caching scheme would > be to make a sub-class of GObject with the caching information. This > would have the benefit of adding ref counting etc. It's not a problem, as you note we can put the gobject information into NLHDR_COMMON. I'm not focusing on such bindings but if you want to reuse my code, feel free. From leonid.grossman@neterion.com Tue Feb 22 15:21:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:21:42 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNLXEM002253 for ; Tue, 22 Feb 2005 15:21:36 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1MMIWdG002991; Tue, 22 Feb 2005 17:18:33 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1MMIVDD007619; Tue, 22 Feb 2005 17:18:31 -0500 (EST) Message-Id: <200502222218.j1MMIVDD007619@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'Leonid Grossman'" Cc: "'Stephen Hemminger'" , , "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Tue, 22 Feb 2005 14:17:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZJ5aKNY2SnIbbSjKoIMOxEPmFPQABKODQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050222214345.GA51890@muc.de> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1370 Lines: 41 > -----Original Message----- > From: Andi Kleen [mailto:ak@muc.de] > Sent: Tuesday, February 22, 2005 1:44 PM > To: Leonid Grossman > Cc: 'Stephen Hemminger'; hadi@cyberus.ca; 'rick jones'; > netdev@oss.sgi.com; 'Alex Aizman' > Subject: Re: Intel and TOE in the news > > > TSO case is probably different - TSO hardware just sets PSH on the > > last fragment only (and only if the flag was set on the > original large > > tx packet). Receiver doesn't really know if the sender is > TSO-capable > > or not and will ACK the same way - will it not? > > Anyway, with LRO we do change rx packet count so affecting parts of > > TCP that depend on packet count is indeed a concern; I guess we'll > > find out soon enough whether there are real issues with the > approach > > :-) > > Linux doesn't depend on packet count; it keeps an estimate > called rcv_mss about the biggest seen packet size and acks > every 2*rcv_mss worth of data. > > Your scheme would likely result in acking every two of your > large packets as soon as the connection is out of "quickack" > mode. So there would be on wire differences. Sounds good, thanks! We should be OK then. Leonid > > > > Linux TCP RX path didn't care about PSH last time I checked. > > Actually it does for measuring the rcv_mss for very small MTUs. > Shouldn't matter in practice though. > > -Andi > From leonid.grossman@neterion.com Tue Feb 22 15:21:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:21:42 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNLXEK002253 for ; Tue, 22 Feb 2005 15:21:35 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1MMBZdG002946; Tue, 22 Feb 2005 17:11:35 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1MMBWDD006726; Tue, 22 Feb 2005 17:11:33 -0500 (EST) Message-Id: <200502222211.j1MMBWDD006726@guinness.s2io.com> From: "Leonid Grossman" To: "'Rick Jones'" , Subject: RE: Intel and TOE in the news Date: Tue, 22 Feb 2005 14:10:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZJ2ugxaC7+aV6SnqDd3y1LQQiwAAAswUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <421BA741.4050201@hp.com> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1150 Lines: 38 > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Rick Jones > Sent: Tuesday, February 22, 2005 1:42 PM > To: netdev@oss.sgi.com > Subject: Re: Intel and TOE in the news > > Leonid Grossman wrote: > > No wait, "paste in" only packets that are already received when a > > traffic interrupt comes... > > Ah, so it is ass-u-me-ing that there is little or no packet loss? This is a reasonable assumption in a datacenter, isn't it :-)? At any rate, no wait still - if the driver doesn't find the next sequence (no matter if the packet is lost or it is just not received yet at the time the driver is looking at the receive buffer) it will indicate the accumulated RSO right away. > > How about when the driver is polling instead of taking > interrupts? Will the driver "see" the RSO > segment-in-progress or will it be hidden? It doesn't matter what triggered the driver to wake up and look at the receive buffer. It will still see in real time the packets that have been received - no matter if the interrupts for these packets arrived or not. Leonid > > rick jones > > From leonid.grossman@neterion.com Tue Feb 22 15:21:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:21:43 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNLXEG002253 for ; Tue, 22 Feb 2005 15:21:33 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1MMqDdG003210; Tue, 22 Feb 2005 17:52:13 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1MMqBDD012187; Tue, 22 Feb 2005 17:52:12 -0500 (EST) Message-Id: <200502222252.j1MMqBDD012187@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'Leonid Grossman'" Cc: "'Stephen Hemminger'" , , "'rick jones'" , , "'Alex Aizman'" Subject: RE: Intel and TOE in the news Date: Tue, 22 Feb 2005 14:51:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZL88u7zG34AE9TYuaV3221jpuKgAAEnjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050222224237.GB60153@muc.de> X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 2590 Lines: 75 > -----Original Message----- > From: Andi Kleen [mailto:ak@muc.de] > Sent: Tuesday, February 22, 2005 2:43 PM > To: Leonid Grossman > Cc: 'Stephen Hemminger'; hadi@cyberus.ca; 'rick jones'; > netdev@oss.sgi.com; 'Alex Aizman' > Subject: Re: Intel and TOE in the news > > On Tue, Feb 22, 2005 at 02:17:35PM -0800, Leonid Grossman wrote: > > > > > > > -----Original Message----- > > > From: Andi Kleen [mailto:ak@muc.de] > > > Sent: Tuesday, February 22, 2005 1:44 PM > > > To: Leonid Grossman > > > Cc: 'Stephen Hemminger'; hadi@cyberus.ca; 'rick jones'; > > > netdev@oss.sgi.com; 'Alex Aizman' > > > Subject: Re: Intel and TOE in the news > > > > > > > TSO case is probably different - TSO hardware just sets > PSH on the > > > > last fragment only (and only if the flag was set on the > > > original large > > > > tx packet). Receiver doesn't really know if the sender is > > > TSO-capable > > > > or not and will ACK the same way - will it not? > > > > Anyway, with LRO we do change rx packet count so > affecting parts > > > > of TCP that depend on packet count is indeed a concern; I guess > > > > we'll find out soon enough whether there are real > issues with the > > > approach > > > > :-) > > > > > > Linux doesn't depend on packet count; it keeps an estimate called > > > rcv_mss about the biggest seen packet size and acks every > 2*rcv_mss > > > worth of data. > > > > > > Your scheme would likely result in acking every two of your large > > > packets as soon as the connection is out of "quickack" > > > mode. So there would be on wire differences. > > > > Sounds good, thanks! We should be OK then. > > Are you sure? It definitely wouldn't look like a conventional > TCP ack clock on the wire, but you would get an ack only every > (BIGPACKETSIZE/MSS) * 2 packets. > > Quite a stretch ACK. > > I'm not saying it wouldn't work (and maybe Rick et.al. are > right and Acking overhead is the next TCP frontier), but it > would be definitely quite different. It needs careful testing > on how it behaves with packet loss. Sure, but I think the main RSO application will be in a datacenter; this assumes very little packet loss. I agree that corner cases will need to be tested very carefully, and there may be scenarious when the feature will not work well and may need to be turned off. In general, I don't expect RSO benefits to be significant (just because rx processing for 1500 MTU is still one of the biggest bottlenecks for 10GbE, so every bit will help) but certanly not as big or as transparent as TSO benefits. Leonid > > -Andi > From hubert.tonneau@fullpliant.org Tue Feb 22 15:21:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:21:51 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MNLePt002295 for ; Tue, 22 Feb 2005 15:21:41 -0800 From: Hubert Tonneau To: Stephen Hemminger , cliff white Cc: Alexey Kuznetsov , netdev@oss.sgi.com, Injong Rhee , "David S. Miller" Subject: Re: [RFT] BIC TCP delayed ack compensation Date: Tue, 22 Feb 2005 22:22:42 GMT Message-ID: <052Q0TU11@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 614 Lines: 15 Stephen Hemminger wrote: > > This patch which was extracted from BIC TCP 1.1 compensates > for systems (like MaxOSX) that don't ACK every other packet. > It has no impact for normal transfers, but might help with problems > with Mac like Hubert found. No, it's even worse. 2.6.9 to 100 Mbps connected MacOSX: 15 seconds (for roughly 100 MB or data) 2.6.9 to gigabit connected MacOSX: 5 seconds 2.6.10-ac11 to 100 Mbps connected MacOSX: 325 seconds 2.6.10-ac11 to gigabit connected MacOSX: 5 seconds 2.6.10-ac11+BIC to 100 Mbps connected MacOSX: 620 seconds 2.6.10-ac11+BIC to gigabit connected MacOSX: 5 seconds From webmaster@rapidforum.com Tue Feb 22 15:22:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:22:15 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MNM5U2002546 for ; Tue, 22 Feb 2005 15:22:06 -0800 Received: (qmail 31283 invoked by uid 1004); 22 Feb 2005 23:22:02 -0000 Received: from p3ee04891.dip0.t-ipconnect.de (HELO ?62.224.72.145?) (62.224.72.145) by www.rapidforum.com with SMTP; 22 Feb 2005 23:22:02 -0000 Message-ID: <421BBE7B.1050009@rapidforum.com> Date: Wed, 23 Feb 2005 00:21:31 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> In-Reply-To: <20050222115114.0d0e568e.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1914 Lines: 42 Hm can you tell me how to change the limit? It seems the limit is good for 3/1 systems but not for 2/2 systems. To reproduce this, you would have to create a server which is sending data to 4000 non-blocking sockets. It doesnt matter what you send. You should realize a slow-down the more sockets you use. You need Gigabit for this to appear. David S. Miller wrote: > On Tue, 22 Feb 2005 20:17:55 +0100 > Christian Schmid wrote: > > >>No. This is a new thing and this wasnt there before. In 2.6.10-rc2 the kernel aborted programs with >>"Out of memory" when too many buffers are allocated and low memory was full. NOW it just shrinks the >>buffers dynamically. I don't want that. I have a 2/2 system and I want 1600 MB for buffers but you >>only allow around 700 MB for buffers. This is definetly NEW. > > > It always shrinks the TCP socket buffer usage when the total socket > memory used by TCP is over the threshold. This code has been there > for 3 years at least. > > If the behavior has changed, that's interesting and probably due to > some other change. It could even be a MM layer change that is causing > things to behave differently now for you, and because things are > being tweaked in the memory management all the time (particularly > the handling of lowmem vs. highmem) this would not surprise me at > all. > > But the basic framework for shrinking socket buffers when total TCP > memory usage crosses some threshold has been there and has been > enabled for a long time. > > Anyways, we're stalled on figuring out exactly what is wrong due to > lack of information and difficulty in reproducing. The ball is still > in your court. > > Why don't you put together a very simple test case that others can > use to analyze and reproduce your bug? I bet we'll fix it or figure > out what is wrong with your app within 24 hours once you do that. :-) > > From jheffner@psc.edu Tue Feb 22 15:31:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:31:09 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNV5WE005206 for ; Tue, 22 Feb 2005 15:31:05 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id j1MNUxGm014715 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 18:30:59 -0500 (EST) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j1MNUxcv023863; Tue, 22 Feb 2005 18:30:59 -0500 Date: Tue, 22 Feb 2005 18:30:59 -0500 (EST) From: John Heffner To: Stephen Hemminger cc: netdev@oss.sgi.com Subject: Re: [RFT] BIC TCP delayed ack compensation In-Reply-To: <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> Message-ID: References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 1962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 87 Lines: 4 Has there been any discussion of implementing ABC (RFC3465) in Linux? Thanks, -John From AndyLiebman@aol.com Tue Feb 22 15:31:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:31:10 -0800 (PST) Received: from imo-d21.mx.aol.com (imo-d21.mx.aol.com [205.188.144.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNV6OO005197 for ; Tue, 22 Feb 2005 15:31:06 -0800 Received: from AndyLiebman@aol.com by imo-d21.mx.aol.com (mail_out_v37_r3.8.) id 7.68.4ffa26be (3842); Tue, 22 Feb 2005 18:30:14 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <68.4ffa26be.2f4d1a85@aol.com> Date: Tue, 22 Feb 2005 18:30:13 EST Subject: Re: Frequent Oops on Shutdown 2.6.10 To: AndyLiebman@aol.com, herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org CC: terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: netdev Content-Length: 642 Lines: 16 I tested my server today several times. I booted up and shutdown the server eight times while running the 2.6.10 kernel. Six times the sever shut down fine. Two times -- only when I had unplugged the Ethernet connection during my session -- I got the Oops when I shut down Ini both cases, it was about 2 minutes after unplugging the Ethernet cable. So, do you know what this means? Sure, the easy solution would be "don't unplug the Ethernet cable while you're running." I can follow that rule, but out in the field where the servers go, there will be accidents. Should I still try that patch? Regards, Andy Liebman From baruch@ev-en.org Tue Feb 22 15:38:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:39:03 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNcxtt006538 for ; Tue, 22 Feb 2005 15:38:59 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 593A311A648; Wed, 23 Feb 2005 01:38:46 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 03ED311A5D5; Wed, 23 Feb 2005 01:38:34 +0200 (IST) Message-ID: <421BC278.90400@ev-en.org> Date: Tue, 22 Feb 2005 23:38:32 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: Hubert Tonneau , cliff white , Alexey Kuznetsov , netdev@oss.sgi.com, Injong Rhee , "David S. Miller" , Yee-Ting Li , Doug Leith Subject: Re: [RFT] BIC TCP delayed ack compensation References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> In-Reply-To: <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1964 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1016 Lines: 23 Stephen Hemminger wrote: > This patch which was extracted from BIC TCP 1.1 compensates > for systems (like MaxOSX) that don't ACK every other packet. > It has no impact for normal transfers, but might help with problems > with Mac like Hubert found. We have a version of ABC (Appropriate Byte Counting) implementation of RFC 3465, which we hope to submit soon for inclusion in the kernel which should be a more appropriate solution for this. The RFC is a well defined standard whereas this patch has not received any reviewing by the networking community. This solution is just a band-aid for only one congestion control, as opposed to a generic solution. It is also prone to make BIC more aggressive according to our testing. I'll try to post our ABC patch tomorrow, time permitting. One thing to note is that accounting for delayed acking is not an overly important feature, from our testing it only speeds up convergence by a small factor and doesn't change the correctness of the algorithms. Baruch From ak@muc.de Tue Feb 22 15:42:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:42:46 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MNgcqT007262 for ; Tue, 22 Feb 2005 15:42:39 -0800 Received: (qmail 67824 invoked by uid 3709); 22 Feb 2005 22:42:37 -0000 Date: 22 Feb 2005 23:42:37 +0100 Date: Tue, 22 Feb 2005 23:42:37 +0100 From: Andi Kleen To: Leonid Grossman Cc: "'Stephen Hemminger'" , hadi@cyberus.ca, "'rick jones'" , netdev@oss.sgi.com, "'Alex Aizman'" Subject: Re: Intel and TOE in the news Message-ID: <20050222224237.GB60153@muc.de> References: <20050222214345.GA51890@muc.de> <200502222218.j1MMIVDD007619@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502222218.j1MMIVDD007619@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1965 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: 1704 Lines: 45 On Tue, Feb 22, 2005 at 02:17:35PM -0800, Leonid Grossman wrote: > > > > -----Original Message----- > > From: Andi Kleen [mailto:ak@muc.de] > > Sent: Tuesday, February 22, 2005 1:44 PM > > To: Leonid Grossman > > Cc: 'Stephen Hemminger'; hadi@cyberus.ca; 'rick jones'; > > netdev@oss.sgi.com; 'Alex Aizman' > > Subject: Re: Intel and TOE in the news > > > > > TSO case is probably different - TSO hardware just sets PSH on the > > > last fragment only (and only if the flag was set on the > > original large > > > tx packet). Receiver doesn't really know if the sender is > > TSO-capable > > > or not and will ACK the same way - will it not? > > > Anyway, with LRO we do change rx packet count so affecting parts of > > > TCP that depend on packet count is indeed a concern; I guess we'll > > > find out soon enough whether there are real issues with the > > approach > > > :-) > > > > Linux doesn't depend on packet count; it keeps an estimate > > called rcv_mss about the biggest seen packet size and acks > > every 2*rcv_mss worth of data. > > > > Your scheme would likely result in acking every two of your > > large packets as soon as the connection is out of "quickack" > > mode. So there would be on wire differences. > > Sounds good, thanks! We should be OK then. Are you sure? It definitely wouldn't look like a conventional TCP ack clock on the wire, but you would get an ack only every (BIGPACKETSIZE/MSS) * 2 packets. Quite a stretch ACK. I'm not saying it wouldn't work (and maybe Rick et.al. are right and Acking overhead is the next TCP frontier), but it would be definitely quite different. It needs careful testing on how it behaves with packet loss. -Andi From romieu@fr.zoreil.com Tue Feb 22 15:51:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 15:52:02 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MNplJa008122 for ; Tue, 22 Feb 2005 15:51:48 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1MNmRwP017981; Wed, 23 Feb 2005 00:48:27 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1MNmAkP017979; Wed, 23 Feb 2005 00:48:10 +0100 Date: Wed, 23 Feb 2005 00:48:10 +0100 From: Francois Romieu To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Jon Mason , Richard Dawe , Jeff Garzik Subject: [rft/update] r8169 changes in 2.6.x Message-ID: <20050222234810.GA17303@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1966 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: 974 Lines: 29 An update of the r8169 driver is available for the 2.6.11-rc4 kernel. Noticable changes: - better handling of PHY as found on Acer Aspire 1524WLMi (Richard Dawe); - fix a bug triggered when the device is brought down then up again; - avoid a few lost/screaming interrupts; - closed a race when a change of mtu is issued during network activity; - fix VLAN on big-endian hosts (is someone using it apart from me ?); - merge relevant changes from Realtek's 2.2 driver. If it worked for you before, you should not notice anything. Patch against 2.6.10-rc4: - http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch Patch-script directory: - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc4/r8169/ Patch-script tarball: - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc4/r8169-blob.tar.bz2 The 2.4.x backport will be updated later this week. As usual, success/regression reports will be welcome. Thank you for your attention. -- Ueimor From romieu@fr.zoreil.com Tue Feb 22 16:31:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 16:31:58 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N0Voc2014452 for ; Tue, 22 Feb 2005 16:31:51 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1N0V4h8018630; Wed, 23 Feb 2005 01:31:04 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1N0UvdK018629; Wed, 23 Feb 2005 01:30:57 +0100 Date: Wed, 23 Feb 2005 01:30:56 +0100 From: Francois Romieu To: Willy Gardiol Cc: netdev@oss.sgi.com Subject: Re: The 8169 driver: issue with cross cable Message-ID: <20050223003056.GA12696@electric-eye.fr.zoreil.com> References: <200502192011.25428.willy@gardiol.org> <20050219205055.GA2793@electric-eye.fr.zoreil.com> <200502201712.49589.willy@gardiol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502201712.49589.willy@gardiol.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1967 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: 348 Lines: 12 Willy Gardiol : [...] > http://www.gardiol.org/r8169/1000-client.tar.bz2 > http://www.gardiol.org/r8169/1000-server.tar.bz2 > http://www.gardiol.org/r8169/100-client.tar.bz2 > http://www.gardiol.org/r8169/100-server.tar.bz2 Can you add a minimal exports/mount option description so that I try to reproduce it here ? -- Ueimor From shemminger@osdl.org Tue Feb 22 16:58:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 16:58:47 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N0wd28016335 for ; Tue, 22 Feb 2005 16:58:40 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1N0vqqi027846 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 16:57:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1N0vmGi005490; Tue, 22 Feb 2005 16:57:51 -0800 Date: Tue, 22 Feb 2005 16:58:02 -0800 From: Stephen Hemminger To: Hubert Tonneau Cc: cliff white , Alexey Kuznetsov , netdev@oss.sgi.com, Injong Rhee , "David S. Miller" Subject: Re: [RFT] BIC TCP delayed ack compensation Message-ID: <20050222165802.0dc2d333@dxpl.pdx.osdl.net> In-Reply-To: <052Q0TU11@server5.heliogroup.fr> References: <052Q0TU11@server5.heliogroup.fr> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1968 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: 771 Lines: 20 On Tue, 22 Feb 2005 22:22:42 GMT Hubert Tonneau wrote: > Stephen Hemminger wrote: > > > > This patch which was extracted from BIC TCP 1.1 compensates > > for systems (like MaxOSX) that don't ACK every other packet. > > It has no impact for normal transfers, but might help with problems > > with Mac like Hubert found. > > No, it's even worse. > > 2.6.9 to 100 Mbps connected MacOSX: 15 seconds (for roughly 100 MB or data) > 2.6.9 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11 to 100 Mbps connected MacOSX: 325 seconds > 2.6.10-ac11 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11+BIC to 100 Mbps connected MacOSX: 620 seconds > 2.6.10-ac11+BIC to gigabit connected MacOSX: 5 seconds Thanks, that is really interesting... From Yee-Ting.Li@nuim.ie Tue Feb 22 17:04:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 17:05:01 -0800 (PST) Received: from LARCH.MAY.IE (mail.nuim.ie [149.157.1.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N14ro4017112 for ; Tue, 22 Feb 2005 17:04:54 -0800 Received: from [10.220.3.86] ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01LL4J3L6LTA004CHB@NUIM.IE> for netdev@oss.sgi.com; Wed, 23 Feb 2005 01:07:07 +0000 (GMT) Date: Wed, 23 Feb 2005 01:04:50 +0000 From: Yee-Ting Li Subject: Re: [RFT] BIC TCP delayed ack compensation In-reply-to: <421BC278.90400@ev-en.org> To: netdev@oss.sgi.com Cc: Doug Leith , "David S. Miller" , Injong Rhee , Yee-Ting Li , Baruch Even , Hubert Tonneau , cliff white , Alexey Kuznetsov , Stephen Hemminger Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> <421BC278.90400@ev-en.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Yee-Ting.Li@nuim.ie Precedence: bulk X-list: netdev Content-Length: 7966 Lines: 244 On Feb 22, 2005, at 23:38, Baruch Even wrote: > We have a version of ABC (Appropriate Byte Counting) implementation of > RFC 3465, which we hope to submit soon for inclusion in the kernel > which should be a more appropriate solution for this. The RFC is a > well defined standard whereas this patch has not received any > reviewing by the networking community. Please find enclosed a version of our implementation of RFC3465 ABC for Linux 2.6.11-rc4. There is in-built protection, as defined by the RFC, to prevent large bursts of packets should acks arrive acknowledging more than abc_L packets (sysctl_tcp_abc_L). The entire abc patch can be switched on or off using sysctl_tcp_abc={1|0} respectively. As this is also a RFT, it is switched ON by default and has the abc_L value of 2 which MAY be used (according to the RFC). Note that an abc_L of 1 will be more conservative than what is available with normal clocking of delayed acks. Note that there is currently no built in mechanism to prevent abc_L being set to over 2; the RFC defines that abc_L MUST NOT be greater than 2. This patch also has the advantage of working for all protocols currently in the kernel (except vegas which doesn't require it). Signed-off-by: Yee-Ting Li Index: linux-2.6.11-rc4/include/linux/sysctl.h =================================================================== --- linux-2.6.11-rc4.orig/include/linux/sysctl.h Sun Feb 13 03:06:53 2005 +++ linux-2.6.11-rc4/include/linux/sysctl.h Tue Feb 22 23:48:30 2005 @@ -344,6 +344,8 @@ NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, + NET_TCP_ABC=108, + NET_TCP_ABC_L=109, }; enum { Index: linux-2.6.11-rc4/include/linux/tcp.h =================================================================== --- linux-2.6.11-rc4.orig/include/linux/tcp.h Sun Feb 13 03:06:23 2005 +++ linux-2.6.11-rc4/include/linux/tcp.h Tue Feb 22 23:39:41 2005 @@ -366,6 +366,8 @@ __u32 total_retrans; /* Total retransmits for entire connection */ + __u32 bytes_acked; /* Appropiate Byte Counting - RFC3465 */ + /* The syn_wait_lock is necessary only to avoid proc interface having * to grab the main lock sock while browsing the listening hash * (otherwise it's deadlock prone). Index: linux-2.6.11-rc4/include/net/tcp.h =================================================================== --- linux-2.6.11-rc4.orig/include/net/tcp.h Sun Feb 13 03:05:28 2005 +++ linux-2.6.11-rc4/include/net/tcp.h Tue Feb 22 23:47:59 2005 @@ -609,6 +609,10 @@ extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; +/* RFC3465 - ABC */ +extern int sysctl_tcp_abc; +extern int sysctl_tcp_abc_L; + extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; extern int tcp_memory_pressure; @@ -1366,6 +1370,7 @@ static inline void tcp_enter_cwr(struct tcp_sock *tp) { tp->prior_ssthresh = 0; + tp->bytes_acked=0; if (tp->ca_state < TCP_CA_CWR) { __tcp_enter_cwr(tp); tcp_set_ca_state(tp, TCP_CA_CWR); Index: linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/sysctl_net_ipv4.c Sun Feb 13 03:07:01 2005 +++ linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c Tue Feb 22 23:46:18 2005 @@ -682,6 +682,22 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_ABC, + .procname = "tcp_abc", + .data = &sysctl_tcp_abc, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_TCP_ABC_L, + .procname = "tcp_abc_L", + .data = &sysctl_tcp_abc_L, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: linux-2.6.11-rc4/net/ipv4/tcp.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp.c Sun Feb 13 03:05:50 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp.c Tue Feb 22 23:28:28 2005 @@ -1825,6 +1825,7 @@ tp->packets_out = 0; tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_cnt = 0; + tp->bytes_acked = 0; tcp_set_ca_state(tp, TCP_CA_Open); tcp_clear_retrans(tp); tcp_delack_init(tp); Index: linux-2.6.11-rc4/net/ipv4/tcp_input.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c Tue Feb 22 23:27:44 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp_input.c Wed Feb 23 00:25:44 2005 @@ -92,6 +92,11 @@ int sysctl_tcp_moderate_rcvbuf = 1; +/* RFC 3465 - ABC */ +int sysctl_tcp_abc = 1; +int sysctl_tcp_abc_L = 2; /* The RFC definess 1 as being a more conservative value */ + /* that SHOULD be used, however, we use 2 as it MAY be used */ + /* Default values of the Vegas variables, in fixed-point representation * with V_PARAM_SHIFT bits to the right of the binary point. */ @@ -1287,6 +1292,7 @@ tp->snd_cwnd_cnt = 0; tp->snd_cwnd_stamp = tcp_time_stamp; + tp->bytes_acked = 0; tcp_clear_retrans(tp); /* Push undo marker, if it was plain RTO and nothing @@ -1945,6 +1951,8 @@ TCP_ECN_queue_cwr(tp); } + tp->bytes_acked = 0; + tp->snd_cwnd_cnt = 0; tcp_set_ca_state(tp, TCP_CA_Recovery); } @@ -2100,6 +2108,24 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } +/* This is a wrapper function to handle RFC3465 - ABC. As per the RFC, the abc_L + * value defines a burst moderation to prevent sending large bursts of packets + * should an ack acknowledge many packets. abc_L MUST NOT be larger than 2. */ +static __inline__ void reno_cong_avoid_abc( struct tcp_sock *tp, int mss_now ) +{ + int incrs_applied = 0; + + if (sysctl_tcp_abc && !tp->nonagle) + { + while (tp->bytes_acked > mss_now && incrs_applied < sysctl_tcp_abc_L) { + tp->bytes_acked -= mss_now; + reno_cong_avoid( tp ); + } + } else + reno_cong_avoid( tp ); +} + + /* This is based on the congestion detection/avoidance scheme described in * Lawrence S. Brakmo and Larry L. Peterson. * "TCP Vegas: End to end congestion avoidance on a global internet." @@ -2322,12 +2348,15 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } -static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) +static inline void tcp_cong_avoid(struct sock *sk, u32 ack, u32 seq_rtt) { + struct tcp_sock *tp = tcp_sk(sk); + int mss_now = tcp_current_mss(sk,1); + if (tcp_vegas_enabled(tp)) vegas_cong_avoid(tp, ack, seq_rtt); else - reno_cong_avoid(tp); + reno_cong_avoid_abc(tp, mss_now); } /* Restart timer after forward progress on connection. @@ -2890,6 +2919,9 @@ if (before(ack, prior_snd_una)) goto old_ack; + if ( sysctl_tcp_abc && tp->ca_state < TCP_CA_CWR ) + tp->bytes_acked += ack - prior_snd_una; + if (!(flag&FLAG_SLOWPATH) && after(ack, prior_snd_una)) { /* Window is constant, pure forward advance. * No more checks are required. @@ -2940,12 +2972,12 @@ if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd) && tcp_may_raise_cwnd(tp, flag)) - tcp_cong_avoid(tp, ack, seq_rtt); + tcp_cong_avoid(sk, ack, seq_rtt); tcp_fastretrans_alert(sk, prior_snd_una, prior_packets, flag); } else { if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) - tcp_cong_avoid(tp, ack, seq_rtt); + tcp_cong_avoid(sk, ack, seq_rtt); } if ((flag & FLAG_FORWARD_PROGRESS) || !(flag&FLAG_NOT_DUP)) Index: linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp_minisocks.c Sun Feb 13 03:07:01 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c Tue Feb 22 23:28:28 2005 @@ -769,6 +769,8 @@ newtp->snd_cwnd = 2; newtp->snd_cwnd_cnt = 0; + newtp->bytes_acked = 0; + newtp->frto_counter = 0; newtp->frto_highmark = 0; From akpm@osdl.org Tue Feb 22 17:24:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 17:24:53 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N1Of6e018595 for ; Tue, 22 Feb 2005 17:24:42 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1N1OUqi029856 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Feb 2005 17:24:31 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1N1OMur006692; Tue, 22 Feb 2005 17:24:25 -0800 Date: Tue, 22 Feb 2005 17:29:35 -0800 From: Andrew Morton To: Francois Romieu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, jgarzik@pobox.com Subject: Re: [rft/update] r8169 changes in 2.6.x Message-Id: <20050222172935.30e43270.akpm@osdl.org> In-Reply-To: <20050222234810.GA17303@electric-eye.fr.zoreil.com> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1970 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: 2226 Lines: 60 Francois Romieu wrote: > > Patch against 2.6.10-rc4: > - http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch There are already a bunch of r8169 patches in Jeff's tree. The combination isn't pretty: patching file drivers/net/r8169.c Hunk #1 FAILED at 41. Hunk #2 FAILED at 69. Hunk #3 FAILED at 79. Hunk #4 succeeded at 114 (offset 7 lines). Hunk #5 FAILED at 161. Hunk #6 FAILED at 175. Hunk #7 FAILED at 224. Hunk #8 succeeded at 231 (offset 3 lines). Hunk #9 succeeded at 248 (offset 7 lines). Hunk #10 succeeded at 268 (offset 3 lines). Hunk #11 succeeded at 294 (offset 7 lines). Hunk #12 succeeded at 300 (offset 3 lines). Hunk #13 succeeded at 391 (offset 7 lines). Hunk #14 FAILED at 424. Hunk #15 succeeded at 468 (offset 3 lines). Hunk #16 succeeded at 487 (offset 7 lines). Hunk #17 succeeded at 500 with fuzz 1 (offset 10 lines). Hunk #18 FAILED at 732. Hunk #19 FAILED at 767. Hunk #20 FAILED at 1036. Hunk #21 succeeded at 1053 with fuzz 2 (offset 19 lines). Hunk #22 FAILED at 1093. Hunk #23 FAILED at 1128. Hunk #24 FAILED at 1140. Hunk #25 succeeded at 1178 (offset 10 lines). Hunk #26 succeeded at 1198 with fuzz 1 (offset 19 lines). Hunk #27 succeeded at 1213 (offset 10 lines). Hunk #28 succeeded at 1259 (offset 19 lines). Hunk #29 succeeded at 1261 with fuzz 2 (offset 13 lines). Hunk #30 succeeded at 1368 (offset 19 lines). Hunk #31 FAILED at 1576. Hunk #32 succeeded at 1600 (offset 13 lines). Hunk #33 FAILED at 1615. Hunk #34 succeeded at 1683 (offset 26 lines). Hunk #35 succeeded at 1717 (offset 13 lines). Hunk #36 FAILED at 1854. Hunk #37 succeeded at 2042 (offset 24 lines). Hunk #38 FAILED at 2152. Hunk #39 succeeded at 2160 (offset 13 lines). Hunk #40 succeeded at 2187 (offset 24 lines). Hunk #41 succeeded at 2245 (offset 13 lines). Hunk #42 FAILED at 2270. Hunk #43 succeeded at 2293 with fuzz 2 (offset 24 lines). Hunk #44 succeeded at 2314 (offset 13 lines). Hunk #45 FAILED at 2349. Hunk #46 succeeded at 2387 (offset 30 lines). Hunk #47 succeeded at 2378 (offset 13 lines). Hunk #48 FAILED at 2391. Hunk #49 succeeded at 2445 with fuzz 2 (offset 31 lines). 20 out of 49 hunks FAILED -- saving rejects to file drivers/net/r8169.c.rej From garzik@havoc.gtf.org Tue Feb 22 17:27:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 17:27:26 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N1RJds019177 for ; Tue, 22 Feb 2005 17:27:21 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id B6D5BA8830; Tue, 22 Feb 2005 20:22:41 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03865-05; Tue, 22 Feb 2005 20:22:39 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 837F9A882D; Tue, 22 Feb 2005 20:22:33 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 1553A1C0A83F; Tue, 22 Feb 2005 20:26:52 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j1N1QjUf023903; Tue, 22 Feb 2005 20:26:45 -0500 Date: Tue, 22 Feb 2005 20:26:45 -0500 From: Jeff Garzik To: Andrew Morton Cc: Francois Romieu , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk Subject: Re: [rft/update] r8169 changes in 2.6.x Message-ID: <20050223012645.GA23878@havoc.gtf.org> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> <20050222172935.30e43270.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222172935.30e43270.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 1971 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: 418 Lines: 16 On Tue, Feb 22, 2005 at 05:29:35PM -0800, Andrew Morton wrote: > Francois Romieu wrote: > > > > Patch against 2.6.10-rc4: > > - http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch > > There are already a bunch of r8169 patches in Jeff's tree. The combination > isn't pretty: And ~5 more once I run through the 80+ patches left in my pending-patches folder. Jeff From jgarzik@pobox.com Tue Feb 22 17:31:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 17:31:33 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N1VQJl019801 for ; Tue, 22 Feb 2005 17:31:26 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D3lN6-0006ZE-ER; Wed, 23 Feb 2005 01:31:24 +0000 Message-ID: <421BDCD4.3050705@pobox.com> Date: Tue, 22 Feb 2005 20:31:00 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: Re: [patch 2.6.11-rc4-netdev1 5/5] r8169: literate PCI ID References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> <20050221235450.GB31723@electric-eye.fr.zoreil.com> <20050221235611.GC31723@electric-eye.fr.zoreil.com> <20050221235718.GD31723@electric-eye.fr.zoreil.com> <20050221235834.GE31723@electric-eye.fr.zoreil.com> In-Reply-To: <20050221235834.GE31723@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1972 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: 1328 Lines: 37 Francois Romieu wrote: > De-obfuscate supported PCI ID > > Non-hackers happen to read the sources too. > > Signed-off-by: Francois Romieu > > diff -puN drivers/net/r8169.c~r8169-440 drivers/net/r8169.c > --- a/drivers/net/r8169.c~r8169-440 2005-02-21 23:42:21.193570455 +0100 > +++ b/drivers/net/r8169.c 2005-02-21 23:42:21.200569312 +0100 > @@ -174,8 +174,10 @@ const static struct { > #undef _R > > static struct pci_device_id rtl8169_pci_tbl[] = { > - {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, > - {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, > + { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8169, > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, > + { PCI_VENDOR_ID_DLINK, PCI_DEVICE_ID_DLINK_DGE528T, > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, Although I leave it up to you as maintainer, I encourage use of PCI_VENDOR_ID_xxx and discourage use of PCI_DEVICE_ID_xxx. Defining constants for each PCI device (a) endlessly patches pci_ids.h for little value, and (b) means that updates to a single driver are no longer self-contained. For people pulling driver updates into distro kernels particularly, pci_ids PCI_DEVICE_ID_xxx constants are a pain. I'm apply patches 1-4 to netdev right now -- please tell me if I should apply patch #5 as-is, given my comments here. Jeff From davem@davemloft.net Tue Feb 22 19:30:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Feb 2005 19:30:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N3UpjC025673 for ; Tue, 22 Feb 2005 19:30:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D3nDs-0003UU-00; Tue, 22 Feb 2005 19:30:00 -0800 Date: Tue, 22 Feb 2005 19:30:00 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Bug-hunting Message-Id: <20050222193000.404ae6d2.davem@davemloft.net> In-Reply-To: <421BBE7B.1050009@rapidforum.com> References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 534 Lines: 12 On Wed, 23 Feb 2005 00:21:31 +0100 Christian Schmid wrote: > To reproduce this, you would have to create a server which is sending data to 4000 non-blocking > sockets. It doesnt matter what you send. You should realize a slow-down the more sockets you use. > You need Gigabit for this to appear. Please send us the exact test programs to run, not some general description of what "one should do" to reproduce the problem. This is exactly what is stalling this bug getting diagnosed properly and fixed. From romieu@fr.zoreil.com Wed Feb 23 00:27:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 00:27:59 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N8Rl1d012476 for ; Wed, 23 Feb 2005 00:27:48 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1N8Pnj2022264; Wed, 23 Feb 2005 09:25:49 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1N8Pfnl022263; Wed, 23 Feb 2005 09:25:41 +0100 Date: Wed, 23 Feb 2005 09:25:41 +0100 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, jdmason@us.ibm.com Subject: Re: [patch 2.6.11-rc4-netdev1 5/5] r8169: literate PCI ID Message-ID: <20050223082540.GA22191@electric-eye.fr.zoreil.com> References: <20050221235125.GD26248@electric-eye.fr.zoreil.com> <20050221235301.GA31723@electric-eye.fr.zoreil.com> <20050221235450.GB31723@electric-eye.fr.zoreil.com> <20050221235611.GC31723@electric-eye.fr.zoreil.com> <20050221235718.GD31723@electric-eye.fr.zoreil.com> <20050221235834.GE31723@electric-eye.fr.zoreil.com> <421BDCD4.3050705@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421BDCD4.3050705@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1974 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: 218 Lines: 9 Jeff Garzik : [...] > I'm apply patches 1-4 to netdev right now -- please tell me if I should > apply patch #5 as-is, given my comments here. Drop it. I'll put the information on-line. -- Ueimor From romieu@fr.zoreil.com Wed Feb 23 00:59:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 01:00:09 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N8xveP014373 for ; Wed, 23 Feb 2005 00:59:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1N8xTnZ022524; Wed, 23 Feb 2005 09:59:29 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1N8xLMt022523; Wed, 23 Feb 2005 09:59:21 +0100 Date: Wed, 23 Feb 2005 09:59:21 +0100 From: Francois Romieu To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, jgarzik@pobox.com Subject: Re: [rft/update] r8169 changes in 2.6.x Message-ID: <20050223085921.GA22268@electric-eye.fr.zoreil.com> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> <20050222172935.30e43270.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222172935.30e43270.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1975 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: 869 Lines: 23 Andrew Morton : > There are already a bunch of r8169 patches in Jeff's tree. The combination > isn't pretty: [removed by parental advisory] I sent r8169-4{0/1/2/3/4}0 on netdev + Jeff the 22/02/2005. Jeff's netdev (thus your tree) already had the r8169-3xx changes. Jeff has acked r8169-4{0/1/2/3}0 on 23/02/2005. r8169-440 (PCI-ID) won't be applied (there should be no functionnal change nor merge side-effect). r8169-4{5/6}0 have been published only here (so far). So you can: - apply r8169-4{0/1/2/3/5/6}0 if you have not updated to Jeff -netdev beyond what is currently available through plain old patch - apply r8169-4{5/6}0 if you are bk-synced with Jeff -netdev (assuming that Jeff acked after he actually pushed to its bk repo) - do something else until I verify the above and generate a dedicated patchsets for your tree. -- Ueimor From akpm@osdl.org Wed Feb 23 01:10:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 01:10:28 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N9AGeI015268 for ; Wed, 23 Feb 2005 01:10:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1N9A3qi000899 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 01:10:04 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1N9A3UP019543; Wed, 23 Feb 2005 01:10:03 -0800 Date: Wed, 23 Feb 2005 01:09:48 -0800 From: Andrew Morton To: Francois Romieu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, jgarzik@pobox.com Subject: Re: [rft/update] r8169 changes in 2.6.x Message-Id: <20050223010948.6f2aa542.akpm@osdl.org> In-Reply-To: <20050223085921.GA22268@electric-eye.fr.zoreil.com> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> <20050222172935.30e43270.akpm@osdl.org> <20050223085921.GA22268@electric-eye.fr.zoreil.com> 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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1976 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: 236 Lines: 8 Francois Romieu wrote: > > - do something else until I verify the above and generate a dedicated > patchsets for your tree. That sounds great to me ;) 2.6.11-rc4-mm1 should be on kernel.org in an hour or so. From yoshfuji@linux-ipv6.org Wed Feb 23 01:34:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 01:34:45 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N9YbpH016616 for ; Wed, 23 Feb 2005 01:34:38 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2C24A33CC2; Wed, 23 Feb 2005 18:35:58 +0900 (JST) Date: Wed, 23 Feb 2005 18:35:55 +0900 (JST) Message-Id: <20050223.183555.80618945.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: Frequent Oops on Shutdown 2.6.10 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050222101526.GA5814@gondor.apana.org.au> References: <20050221.162949.65179228.yoshfuji@linux-ipv6.org> <20050222101526.GA5814@gondor.apana.org.au> 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1977 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: 4282 Lines: 167 In article <20050222101526.GA5814@gondor.apana.org.au> (at Tue, 22 Feb 2005 21:15:26 +1100), Herbert Xu says: > On Tue, Feb 22, 2005 at 08:57:19PM +1100, Herbert Xu wrote: > > YOSHIFUJI Hideaki / ???? wrote: > > > In article <20050221.162241.24618885.yoshfuji@linux-ipv6.org> (at Mon, 21 Feb 2005 16:22:41 +0900 (JST)), YOSHIFUJI Hideaki / ???? says: > > > > > >> [IPV6] Don't remove dev_snmp6 procfs entry until all users gone. > > > > Sorry, but I don't see how this patch explains the oops the > > people saw. : > I see two solutions: > > 1) Unregister the proc entry earlier. In other words, do it in > addrconf_ifdown. Since this is highly serialised it means that > we can't add the new proc entry before the old proc entry has > been deleted. Okay, it sounds reasonable. What do you think of this? Signed-off-by: Hideaki YOSHIFUJI ===== include/net/ipv6.h 1.42 vs edited ===== --- 1.42/include/net/ipv6.h 2005-01-15 06:30:07 +09:00 +++ edited/include/net/ipv6.h 2005-02-23 17:10:38 +09:00 @@ -149,6 +149,8 @@ int snmp6_register_dev(struct inet6_dev *idev); int snmp6_unregister_dev(struct inet6_dev *idev); +int snmp6_alloc_dev(struct inet6_dev *idev); +int snmp6_free_dev(struct inet6_dev *idev); int snmp6_mib_init(void *ptr[2], size_t mibsize, size_t mibalign); void snmp6_mib_free(void *ptr[2]); ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 06:13:31 +09:00 +++ edited/net/ipv6/addrconf.c 2005-02-23 17:59:56 +09:00 @@ -308,7 +308,7 @@ printk("Freeing alive inet6 device %p\n", idev); return; } - snmp6_unregister_dev(idev); + snmp6_free_dev(idev); kfree(idev); } @@ -339,6 +339,16 @@ /* We refer to the device */ dev_hold(dev); + if (snmp6_alloc_dev(ndev) < 0) { + ADBG((KERN_WARNING + "%s(): cannot allocate memory for statistics; dev=%s.\n", + __FUNCTION__, dev->name)); + neigh_parms_release(&nd_tbl, ndev->nd_parms); + ndev->dead = 1; + in6_dev_finish_destroy(ndev); + return NULL; + } + if (snmp6_register_dev(ndev) < 0) { ADBG((KERN_WARNING "%s(): cannot create /proc/net/dev_snmp6/%s\n", @@ -2013,6 +2023,10 @@ dev->ip6_ptr = NULL; idev->dead = 1; write_unlock_bh(&addrconf_lock); + + /* Step 1.5: remove snmp6 entry */ + snmp6_unregister_dev(idev); + } /* Step 2: clear hash table */ ===== net/ipv6/proc.c 1.25 vs edited ===== --- 1.25/net/ipv6/proc.c 2004-07-08 07:17:29 +09:00 +++ edited/net/ipv6/proc.c 2005-02-23 18:05:27 +09:00 @@ -201,33 +201,23 @@ int snmp6_register_dev(struct inet6_dev *idev) { - int err = -ENOMEM; struct proc_dir_entry *p; if (!idev || !idev->dev) return -EINVAL; - if (snmp6_mib_init((void **)idev->stats.icmpv6, sizeof(struct icmpv6_mib), - __alignof__(struct icmpv6_mib)) < 0) - goto err_icmp; + if (!proc_net_devsnmp6) + return -ENOENT; - if (!proc_net_devsnmp6) { - err = -ENOENT; - goto err_proc; - } p = create_proc_entry(idev->dev->name, S_IRUGO, proc_net_devsnmp6); if (!p) - goto err_proc; + return -ENOMEM; + p->data = idev; p->proc_fops = &snmp6_seq_fops; idev->stats.proc_dir_entry = p; return 0; - -err_proc: - snmp6_mib_free((void **)idev->stats.icmpv6); -err_icmp: - return err; } int snmp6_unregister_dev(struct inet6_dev *idev) @@ -238,8 +228,6 @@ return -EINVAL; remove_proc_entry(idev->stats.proc_dir_entry->name, proc_net_devsnmp6); - snmp6_mib_free((void **)idev->stats.icmpv6); - return 0; } @@ -274,12 +262,21 @@ proc_net_remove("dev_snmp6"); proc_net_remove("snmp6"); } - #else /* CONFIG_PROC_FS */ - int snmp6_register_dev(struct inet6_dev *idev) { + return 0; +} + +int snmp6_unregister_dev(struct inet6_dev *idev) +{ + return 0; +} +#endif /* CONFIG_PROC_FS */ + +int snmp6_alloc_dev(struct inet6_dev *idev) +{ int err = -ENOMEM; if (!idev || !idev->dev) @@ -295,11 +292,10 @@ return err; } -int snmp6_unregister_dev(struct inet6_dev *idev) +int snmp6_free_dev(struct inet6_dev *idev) { snmp6_mib_free((void **)idev->stats.icmpv6); return 0; } -#endif -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Wed Feb 23 01:52:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 01:52:54 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1N9qjH7017813 for ; Wed, 23 Feb 2005 01:52:46 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D3tBu-0001tE-00; Wed, 23 Feb 2005 20:52:22 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D3tBI-0004QG-00; Wed, 23 Feb 2005 20:51:44 +1100 Date: Wed, 23 Feb 2005 20:51:44 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org Subject: Re: Frequent Oops on Shutdown 2.6.10 Message-ID: <20050223095144.GB16820@gondor.apana.org.au> References: <20050221.162949.65179228.yoshfuji@linux-ipv6.org> <20050222101526.GA5814@gondor.apana.org.au> <20050223.183555.80618945.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050223.183555.80618945.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 771 Lines: 24 On Wed, Feb 23, 2005 at 06:35:55PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > What do you think of this? Thanks, this looks great. There is just one technical detail to patch up. > -int snmp6_unregister_dev(struct inet6_dev *idev) > +int snmp6_free_dev(struct inet6_dev *idev) > { > snmp6_mib_free((void **)idev->stats.icmpv6); > return 0; > } You need to check whether icmpv6[0] is NULL either here or in snmp6_mib_free. Otherwise when snmp6_alloc_dev fails we'll wind up here and then call free_percpu on a pair of NULL pointers. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From webmaster@rapidforum.com Wed Feb 23 02:28:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 02:29:04 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NASvUn021270 for ; Wed, 23 Feb 2005 02:28:58 -0800 Received: (qmail 19061 invoked by uid 1004); 23 Feb 2005 10:28:57 -0000 Received: from p3ee04291.dip0.t-ipconnect.de (HELO ?62.224.66.145?) (62.224.66.145) by www.rapidforum.com with SMTP; 23 Feb 2005 10:28:57 -0000 Message-ID: <421C5AC8.70601@rapidforum.com> Date: Wed, 23 Feb 2005 11:28:24 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> In-Reply-To: <20050222193000.404ae6d2.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 776 Lines: 20 I would have to write a test-program first. This needs time. Before I spend hours into coding this, first just tell me how I can raise the global-limit from around 600-700 MB to 1500 MB. David S. Miller wrote: > On Wed, 23 Feb 2005 00:21:31 +0100 > Christian Schmid wrote: > > >>To reproduce this, you would have to create a server which is sending data to 4000 non-blocking >>sockets. It doesnt matter what you send. You should realize a slow-down the more sockets you use. >>You need Gigabit for this to appear. > > > Please send us the exact test programs to run, not some general > description of what "one should do" to reproduce the problem. > > This is exactly what is stalling this bug getting diagnosed properly > and fixed. > > From chas@cmf.nrl.navy.mil Wed Feb 23 06:17:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 06:17:32 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NEHPbd009176 for ; Wed, 23 Feb 2005 06:17:26 -0800 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 j1NEHIZ2012625; Wed, 23 Feb 2005 09:17:18 -0500 (EST) Message-Id: <200502231417.j1NEHIZ2012625@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH] [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support Date: Wed, 23 Feb 2005 09:17:18 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1980 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: 7201 Lines: 255 this patch correctly removes the pci_find_device() used by the fore200e driver. the __init/__exit remains a bit clunky since we need to preserve sbus support. please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/22 16:14:44-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # # drivers/atm/fore200e.h # 2005/02/22 16:14:25-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # # drivers/atm/fore200e.c # 2005/02/22 16:14:25-05:00 chas@relax.cmf.nrl.navy.mil +107 -47 # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c 2005-02-23 09:08:38 -05:00 +++ b/drivers/atm/fore200e.c 2005-02-23 09:08:38 -05:00 @@ -114,7 +114,7 @@ static const struct atmdev_ops fore200e_ops; static const struct fore200e_bus fore200e_bus[]; -static struct fore200e* fore200e_boards = NULL; +static LIST_HEAD(fore200e_boards); MODULE_AUTHOR("Christophe Lizzi - credits to Uwe Dannowski and Heikki Vatiainen"); @@ -637,39 +637,6 @@ } -static struct fore200e* __init -fore200e_pca_detect(const struct fore200e_bus* bus, int index) -{ - struct fore200e* fore200e; - struct pci_dev* pci_dev = NULL; - int count = index; - - do { - pci_dev = pci_find_device(PCI_VENDOR_ID_FORE, PCI_DEVICE_ID_FORE_PCA200E, pci_dev); - if (pci_dev == NULL) - return NULL; - } while (count--); - - if (pci_enable_device(pci_dev)) - return NULL; - - fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); - if (fore200e == NULL) - return NULL; - - fore200e->bus = bus; - fore200e->bus_dev = pci_dev; - fore200e->irq = pci_dev->irq; - fore200e->phys_base = pci_resource_start(pci_dev, 0); - - sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); - - pci_set_master(pci_dev); - - return fore200e; -} - - static int __init fore200e_pca_prom_read(struct fore200e* fore200e, struct prom_data* prom) { @@ -2768,20 +2735,107 @@ return 0; } + +static int __devinit +fore200e_pca_detect(struct pci_dev *pci_dev, const struct pci_device_id *pci_ent) +{ + const struct fore200e_bus* bus = (struct fore200e_bus*) pci_ent->driver_data; + struct fore200e* fore200e; + int err = 0; + static int index = 0; + + if (pci_enable_device(pci_dev)) { + err = -EINVAL; + goto out; + } + + fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); + if (fore200e == NULL) { + err = -ENOMEM; + goto out_disable; + } + + fore200e->bus = bus; + fore200e->bus_dev = pci_dev; + fore200e->irq = pci_dev->irq; + fore200e->phys_base = pci_resource_start(pci_dev, 0); + + sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); + + pci_set_master(pci_dev); + + printk(FORE200E "device %s found at 0x%lx, IRQ %s\n", + fore200e->bus->model_name, + fore200e->phys_base, fore200e_irq_itoa(fore200e->irq)); + + sprintf(fore200e->name, "%s-%d", bus->model_name, index); + + err = fore200e_init(fore200e); + if (err < 0) { + fore200e_shutdown(fore200e); + goto out_free; + } + + ++index; + pci_set_drvdata(pci_dev, fore200e); + +out: + return err; + +out_free: + kfree(fore200e); +out_disable: + pci_disable_device(pci_dev); + goto out; +} + + +static void __devexit fore200e_pca_remove_one(struct pci_dev *pci_dev) +{ + struct fore200e *fore200e; + + fore200e = pci_get_drvdata(pci_dev); + + list_del(&fore200e->entry); + + fore200e_shutdown(fore200e); + kfree(fore200e); + pci_disable_device(pci_dev); +} + + +#ifdef CONFIG_ATM_FORE200E_PCA +static struct pci_device_id fore200e_pca_tbl[] = { + { PCI_VENDOR_ID_FORE, PCI_DEVICE_ID_FORE_PCA200E, PCI_ANY_ID, PCI_ANY_ID, + 0, 0, (unsigned long) &fore200e_bus[0] }, + { 0, } +}; + +MODULE_DEVICE_TABLE(pci, fore200e_pca_tbl); + +static struct pci_driver fore200e_pca_driver = { + .name = "fore_200e", + .probe = fore200e_pca_detect, + .remove = __devexit_p(fore200e_pca_remove_one), + .id_table = fore200e_pca_tbl, +}; +#endif + + static int __init fore200e_module_init(void) { const struct fore200e_bus* bus; struct fore200e* fore200e; - int index, link; + int index; printk(FORE200E "FORE Systems 200E-series ATM driver - version " FORE200E_VERSION "\n"); /* for each configured bus interface */ - for (link = 0, bus = fore200e_bus; bus->model_name; bus++) { + for (bus = fore200e_bus; bus->model_name; bus++) { /* detect all boards present on that bus */ - for (index = 0; (fore200e = bus->detect(bus, index)); index++) { + for (index = 0; bus->detect && (fore200e = bus->detect(bus, index)); index++) { printk(FORE200E "device %s found at 0x%lx, IRQ %s\n", fore200e->bus->model_name, @@ -2795,15 +2849,18 @@ break; } - link++; - - fore200e->next = fore200e_boards; - fore200e_boards = fore200e; + list_add(&fore200e->entry, &fore200e_boards); } } - if (link) - return 0; +#ifdef CONFIG_ATM_FORE200E_PCA + if (!pci_module_init(&fore200e_pca_driver)) + return 0; +#endif + + if (!list_empty(&fore200e_boards)) + return 0; + return -ENODEV; } @@ -2811,11 +2868,14 @@ static void __exit fore200e_module_cleanup(void) { - while (fore200e_boards) { - struct fore200e* fore200e = fore200e_boards; + struct fore200e *fore200e, *next; + +#ifdef CONFIG_ATM_FORE200E_PCA + pci_unregister_driver(&fore200e_pca_driver); +#endif + list_for_each_entry_safe(fore200e, next, &fore200e_boards, entry) { fore200e_shutdown(fore200e); - fore200e_boards = fore200e->next; kfree(fore200e); } DPRINTK(1, "module being removed\n"); @@ -3150,7 +3210,7 @@ fore200e_pca_dma_sync_for_device, fore200e_pca_dma_chunk_alloc, fore200e_pca_dma_chunk_free, - fore200e_pca_detect, + NULL, fore200e_pca_configure, fore200e_pca_map, fore200e_pca_reset, diff -Nru a/drivers/atm/fore200e.h b/drivers/atm/fore200e.h --- a/drivers/atm/fore200e.h 2005-02-23 09:08:38 -05:00 +++ b/drivers/atm/fore200e.h 2005-02-23 09:08:38 -05:00 @@ -841,7 +841,7 @@ /* per-device data */ typedef struct fore200e { - struct fore200e* next; /* next device */ + struct list_head entry; /* next device */ const struct fore200e_bus* bus; /* bus-dependent code and data */ union fore200e_regs regs; /* bus-dependent registers */ struct atm_dev* atm_dev; /* ATM device */ From AndyLiebman@aol.com Wed Feb 23 06:52:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 06:53:04 -0800 (PST) Received: from imo-m16.mx.aol.com (imo-m16.mx.aol.com [64.12.138.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NEqp5P011129 for ; Wed, 23 Feb 2005 06:52:52 -0800 Received: from AndyLiebman@aol.com by imo-m16.mx.aol.com (mail_out_v37_r3.8.) id 7.b9.522b6602 (3310); Wed, 23 Feb 2005 09:51:44 -0500 (EST) From: AndyLiebman@aol.com Message-ID: Date: Wed, 23 Feb 2005 09:51:44 EST Subject: Re: Frequent Oops on Shutdown 2.6.10 To: herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org CC: terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org, AndyLiebman@aol.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1109170304" X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: netdev Content-Length: 3412 Lines: 99 -------------------------------1109170304 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, Yoshi Should I bother to apply this patch, or should I wait for you to make this last change? What did you think about my comment that the Oops only occurred when the Ethernet cable had been unplugged during operation? Regards, Andy Liebman On Wed, Feb 23, 2005 at 06:35:55PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > What do you think of this? Thanks, this looks great. There is just one technical detail to patch up. > -int snmp6_unregister_dev(struct inet6_dev *idev) > +int snmp6_free_dev(struct inet6_dev *idev) > { > snmp6_mib_free((void **)idev->stats.icmpv6); > return 0; > } You need to check whether icmpv6[0] is NULL either here or in snmp6_mib_free. Otherwise when snmp6_alloc_dev fails we'll wind up here and then call free_percpu on a pair of NULL pointers. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -------------------------------1109170304 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello, Yoshi
 
Should I bother to apply this patch, or should I wait for you to make t= his=20 last change? What did you think about my comment that the Oops only occurred= =20 when the Ethernet cable had been unplugged during operation?
 
Regards,
Andy Liebman
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Wed,=20 Feb 23, 2005 at 06:35:55PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@=20 wrote:
>
> What do you think of this?

Thanks, this loo= ks=20 great.  There is just one technical detail
to patch up.

>= ;=20 -int snmp6_unregister_dev(struct inet6_dev *idev)
> +int=20 snmp6_free_dev(struct inet6_dev *idev)
>  {
>   = ;=20   snmp6_mib_free((void **)idev->stats.icmpv6);
>   = ;=20   return 0;
>  }

You need to check whether icmpv6[0= ] is=20 NULL either here or in
snmp6_mib_free.  Otherwise when snmp6_alloc= _dev=20 fails we'll
wind up here and then call free_percpu on a pair of NULL=20 pointers.

Cheers,
--
Visit Openswan at=20 http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}=20 <herbert@gondor.apana.org.au>
Home Page:=20 http://gondor.apana.org.au/~herbert/
PGP Key:=20 http://gondor.apana.org.au/~herbert/pubkey.txt
 
-------------------------------1109170304-- From AndyLiebman@aol.com Wed Feb 23 06:54:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 06:54:14 -0800 (PST) Received: from imo-m26.mx.aol.com (imo-m26.mx.aol.com [64.12.137.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NEs9Ql011499 for ; Wed, 23 Feb 2005 06:54:09 -0800 Received: from AndyLiebman@aol.com by imo-m26.mx.aol.com (mail_out_v37_r3.8.) id 7.6.3f715fba (3310); Wed, 23 Feb 2005 09:53:14 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <6.3f715fba.2f4df2da@aol.com> Date: Wed, 23 Feb 2005 09:53:14 EST Subject: Re: Frequent Oops on Shutdown 2.6.10 To: herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org CC: terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: netdev Content-Length: 1157 Lines: 38 Hello, Yoshi Should I bother to apply this patch, or should I wait for you to make this last change? What did you think about my comment that the Oops only occurred when the Ethernet cable had been unplugged during operation? Regards, Andy Liebman In a message dated 2/23/2005 4:52:59 A.M. Eastern Standard Time, herbert@gondor.apana.org.au writes: On Wed, Feb 23, 2005 at 06:35:55PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > What do you think of this? Thanks, this looks great. There is just one technical detail to patch up. > -int snmp6_unregister_dev(struct inet6_dev *idev) > +int snmp6_free_dev(struct inet6_dev *idev) > { > snmp6_mib_free((void **)idev->stats.icmpv6); > return 0; > } You need to check whether icmpv6[0] is NULL either here or in snmp6_mib_free. Otherwise when snmp6_alloc_dev fails we'll wind up here and then call free_percpu on a pair of NULL pointers. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Yee-Ting.Li@nuim.ie Wed Feb 23 07:28:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 07:28:19 -0800 (PST) Received: from LARCH.MAY.IE (mail.nuim.ie [149.157.1.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NFSD9u013339 for ; Wed, 23 Feb 2005 07:28:14 -0800 Received: from [10.220.3.86] ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01LL5D907S66004WBR@NUIM.IE> for netdev@oss.sgi.com; Wed, 23 Feb 2005 15:30:29 +0000 (GMT) Date: Wed, 23 Feb 2005 15:28:11 +0000 From: Yee-Ting Li Subject: Re: [RFT] BIC TCP delayed ack compensation In-reply-to: To: netdev@oss.sgi.com Cc: "David S. Miller" , Stephen Hemminger , Yee-Ting Li , Baruch Even , Doug Leith Message-id: <30e5e2bfd9abecff57302b43f46d0aef@may.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <050QTJA12@server5.heliogroup.fr> <20050209105909.17da40a9@dxpl.pdx.osdl.net> <20050222135046.23f7ec7d@dxpl.pdx.osdl.net> <421BC278.90400@ev-en.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Yee-Ting.Li@nuim.ie Precedence: bulk X-list: netdev Content-Length: 8589 Lines: 263 Opps! checking through the code, i've realised that i forgot to increment the incrs_applied counter to account for burst moderation. Please find enclosed the correct (full) implementation of RFC3465 (the only change from the previous is the addition of incrs_applied++ in the while loop). From our tests with Linux receivers, this burst moderation will make a difference at very high speeds (>200Mbit/sec) as they do not always acknowledge for every other packet. Apologies for any inconvenience. Yee. On Feb 23, 2005, at 01:04, Yee-Ting Li wrote: > On Feb 22, 2005, at 23:38, Baruch Even wrote: >> We have a version of ABC (Appropriate Byte Counting) implementation >> of RFC 3465, which we hope to submit soon for inclusion in the kernel >> which should be a more appropriate solution for this. The RFC is a >> well defined standard whereas this patch has not received any >> reviewing by the networking community. > > Please find enclosed a version of our implementation of RFC3465 ABC > for Linux 2.6.11-rc4. > > There is in-built protection, as defined by the RFC, to prevent large > bursts of packets should acks arrive acknowledging more than abc_L > packets (sysctl_tcp_abc_L). The entire abc patch can be switched on or > off using sysctl_tcp_abc={1|0} respectively. As this is also a RFT, it > is switched ON by default and has the abc_L value of 2 which MAY be > used (according to the RFC). > > Note that an abc_L of 1 will be more conservative than what is > available with normal clocking of delayed acks. Note that there is > currently no built in mechanism to prevent abc_L being set to over 2; > the RFC defines that abc_L MUST NOT be greater than 2. > > This patch also has the advantage of working for all protocols > currently in the kernel (except vegas which doesn't require it). > Signed-off-by: Yee-Ting Li Index: linux-2.6.11-rc4/include/linux/sysctl.h =================================================================== --- linux-2.6.11-rc4.orig/include/linux/sysctl.h Sun Feb 13 03:06:53 2005 +++ linux-2.6.11-rc4/include/linux/sysctl.h Tue Feb 22 23:48:30 2005 @@ -344,6 +344,8 @@ NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, + NET_TCP_ABC=108, + NET_TCP_ABC_L=109, }; enum { Index: linux-2.6.11-rc4/include/linux/tcp.h =================================================================== --- linux-2.6.11-rc4.orig/include/linux/tcp.h Sun Feb 13 03:06:23 2005 +++ linux-2.6.11-rc4/include/linux/tcp.h Tue Feb 22 23:39:41 2005 @@ -366,6 +366,8 @@ __u32 total_retrans; /* Total retransmits for entire connection */ + __u32 bytes_acked; /* Appropiate Byte Counting - RFC3465 */ + /* The syn_wait_lock is necessary only to avoid proc interface having * to grab the main lock sock while browsing the listening hash * (otherwise it's deadlock prone). Index: linux-2.6.11-rc4/include/net/tcp.h =================================================================== --- linux-2.6.11-rc4.orig/include/net/tcp.h Sun Feb 13 03:05:28 2005 +++ linux-2.6.11-rc4/include/net/tcp.h Tue Feb 22 23:47:59 2005 @@ -609,6 +609,10 @@ extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; +/* RFC3465 - ABC */ +extern int sysctl_tcp_abc; +extern int sysctl_tcp_abc_L; + extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; extern int tcp_memory_pressure; @@ -1366,6 +1370,7 @@ static inline void tcp_enter_cwr(struct tcp_sock *tp) { tp->prior_ssthresh = 0; + tp->bytes_acked=0; if (tp->ca_state < TCP_CA_CWR) { __tcp_enter_cwr(tp); tcp_set_ca_state(tp, TCP_CA_CWR); Index: linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/sysctl_net_ipv4.c Sun Feb 13 03:07:01 2005 +++ linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c Tue Feb 22 23:46:18 2005 @@ -682,6 +682,22 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_ABC, + .procname = "tcp_abc", + .data = &sysctl_tcp_abc, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_TCP_ABC_L, + .procname = "tcp_abc_L", + .data = &sysctl_tcp_abc_L, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: linux-2.6.11-rc4/net/ipv4/tcp.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp.c Sun Feb 13 03:05:50 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp.c Tue Feb 22 23:28:28 2005 @@ -1825,6 +1825,7 @@ tp->packets_out = 0; tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_cnt = 0; + tp->bytes_acked = 0; tcp_set_ca_state(tp, TCP_CA_Open); tcp_clear_retrans(tp); tcp_delack_init(tp); Index: linux-2.6.11-rc4/net/ipv4/tcp_input.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c Tue Feb 22 23:27:44 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp_input.c Wed Feb 23 15:18:57 2005 @@ -92,6 +92,11 @@ int sysctl_tcp_moderate_rcvbuf = 1; +/* RFC 3465 - ABC */ +int sysctl_tcp_abc = 1; +int sysctl_tcp_abc_L = 2; /* The RFC definess 1 as being a more conservative value */ + /* that SHOULD be used, however, we use 2 as it MAY be used */ + /* Default values of the Vegas variables, in fixed-point representation * with V_PARAM_SHIFT bits to the right of the binary point. */ @@ -1287,6 +1292,7 @@ tp->snd_cwnd_cnt = 0; tp->snd_cwnd_stamp = tcp_time_stamp; + tp->bytes_acked = 0; tcp_clear_retrans(tp); /* Push undo marker, if it was plain RTO and nothing @@ -1945,6 +1951,8 @@ TCP_ECN_queue_cwr(tp); } + tp->bytes_acked = 0; + tp->snd_cwnd_cnt = 0; tcp_set_ca_state(tp, TCP_CA_Recovery); } @@ -2100,6 +2108,25 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } +/* This is a wrapper function to handle RFC3465 - ABC. As per the RFC, the abc_L + * value defines a burst moderation to prevent sending large bursts of packets + * should an ack acknowledge many packets. abc_L MUST NOT be larger than 2. */ +static __inline__ void reno_cong_avoid_abc( struct tcp_sock *tp, int mss_now ) +{ + int incrs_applied = 0; + + if (sysctl_tcp_abc && !tp->nonagle) + { + while (tp->bytes_acked > mss_now && incrs_applied < sysctl_tcp_abc_L) { + tp->bytes_acked -= mss_now; + reno_cong_avoid( tp ); + incrs_applied++; + } + } else + reno_cong_avoid( tp ); +} + + /* This is based on the congestion detection/avoidance scheme described in * Lawrence S. Brakmo and Larry L. Peterson. * "TCP Vegas: End to end congestion avoidance on a global internet." @@ -2322,12 +2349,15 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } -static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) +static inline void tcp_cong_avoid(struct sock *sk, u32 ack, u32 seq_rtt) { + struct tcp_sock *tp = tcp_sk(sk); + int mss_now = tcp_current_mss(sk,1); + if (tcp_vegas_enabled(tp)) vegas_cong_avoid(tp, ack, seq_rtt); else - reno_cong_avoid(tp); + reno_cong_avoid_abc(tp, mss_now); } /* Restart timer after forward progress on connection. @@ -2890,6 +2920,9 @@ if (before(ack, prior_snd_una)) goto old_ack; + if ( sysctl_tcp_abc && tp->ca_state < TCP_CA_CWR ) + tp->bytes_acked += ack - prior_snd_una; + if (!(flag&FLAG_SLOWPATH) && after(ack, prior_snd_una)) { /* Window is constant, pure forward advance. * No more checks are required. @@ -2940,12 +2973,12 @@ if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd) && tcp_may_raise_cwnd(tp, flag)) - tcp_cong_avoid(tp, ack, seq_rtt); + tcp_cong_avoid(sk, ack, seq_rtt); tcp_fastretrans_alert(sk, prior_snd_una, prior_packets, flag); } else { if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) - tcp_cong_avoid(tp, ack, seq_rtt); + tcp_cong_avoid(sk, ack, seq_rtt); } if ((flag & FLAG_FORWARD_PROGRESS) || !(flag&FLAG_NOT_DUP)) Index: linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c =================================================================== --- linux-2.6.11-rc4.orig/net/ipv4/tcp_minisocks.c Sun Feb 13 03:07:01 2005 +++ linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c Tue Feb 22 23:28:28 2005 @@ -769,6 +769,8 @@ newtp->snd_cwnd = 2; newtp->snd_cwnd_cnt = 0; + newtp->bytes_acked = 0; + newtp->frto_counter = 0; newtp->frto_highmark = 0; From yoshfuji@linux-ipv6.org Wed Feb 23 08:40:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 08:40:35 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NGeSaB021460 for ; Wed, 23 Feb 2005 08:40:29 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EFCCB33CC2; Thu, 24 Feb 2005 01:41:49 +0900 (JST) Date: Thu, 24 Feb 2005 01:41:48 +0900 (JST) Message-Id: <20050224.014148.47626020.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, AndyLiebman@aol.com, terryg@axian.com Cc: netdev@oss.sgi.com, akpm@osdl.org, herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org Subject: Re: Frequent Oops on Shutdown 2.6.10 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050223095144.GB16820@gondor.apana.org.au> References: <20050222101526.GA5814@gondor.apana.org.au> <20050223.183555.80618945.yoshfuji@linux-ipv6.org> <20050223095144.GB16820@gondor.apana.org.au> 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1984 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: 4046 Lines: 167 In article <20050223095144.GB16820@gondor.apana.org.au> (at Wed, 23 Feb 2005 20:51:44 +1100), Herbert Xu says: > You need to check whether icmpv6[0] is NULL either here or in > snmp6_mib_free. Otherwise when snmp6_alloc_dev fails we'll > wind up here and then call free_percpu on a pair of NULL pointers. Ok, right... Here's the (hopefuly) final one. Signed-off-by: Hideaki YOSHIFUJI ===== include/net/ipv6.h 1.42 vs edited ===== --- 1.42/include/net/ipv6.h 2005-01-15 06:30:07 +09:00 +++ edited/include/net/ipv6.h 2005-02-23 17:10:38 +09:00 @@ -149,6 +149,8 @@ int snmp6_register_dev(struct inet6_dev *idev); int snmp6_unregister_dev(struct inet6_dev *idev); +int snmp6_alloc_dev(struct inet6_dev *idev); +int snmp6_free_dev(struct inet6_dev *idev); int snmp6_mib_init(void *ptr[2], size_t mibsize, size_t mibalign); void snmp6_mib_free(void *ptr[2]); ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 06:13:31 +09:00 +++ edited/net/ipv6/addrconf.c 2005-02-23 17:59:56 +09:00 @@ -308,7 +308,7 @@ printk("Freeing alive inet6 device %p\n", idev); return; } - snmp6_unregister_dev(idev); + snmp6_free_dev(idev); kfree(idev); } @@ -339,6 +339,16 @@ /* We refer to the device */ dev_hold(dev); + if (snmp6_alloc_dev(ndev) < 0) { + ADBG((KERN_WARNING + "%s(): cannot allocate memory for statistics; dev=%s.\n", + __FUNCTION__, dev->name)); + neigh_parms_release(&nd_tbl, ndev->nd_parms); + ndev->dead = 1; + in6_dev_finish_destroy(ndev); + return NULL; + } + if (snmp6_register_dev(ndev) < 0) { ADBG((KERN_WARNING "%s(): cannot create /proc/net/dev_snmp6/%s\n", @@ -2013,6 +2023,10 @@ dev->ip6_ptr = NULL; idev->dead = 1; write_unlock_bh(&addrconf_lock); + + /* Step 1.5: remove snmp6 entry */ + snmp6_unregister_dev(idev); + } /* Step 2: clear hash table */ ===== net/ipv6/af_inet6.c 1.88 vs edited ===== --- 1.88/net/ipv6/af_inet6.c 2005-01-14 13:41:05 +09:00 +++ edited/net/ipv6/af_inet6.c 2005-02-24 00:58:11 +09:00 @@ -652,8 +652,10 @@ { if (ptr == NULL) return; - free_percpu(ptr[0]); - free_percpu(ptr[1]); + if (ptr[0]) + free_percpu(ptr[0]); + if (ptr[1]) + free_percpu(ptr[1]); ptr[0] = ptr[1] = NULL; } ===== net/ipv6/proc.c 1.25 vs edited ===== --- 1.25/net/ipv6/proc.c 2004-07-08 07:17:29 +09:00 +++ edited/net/ipv6/proc.c 2005-02-24 01:00:44 +09:00 @@ -201,33 +201,23 @@ int snmp6_register_dev(struct inet6_dev *idev) { - int err = -ENOMEM; struct proc_dir_entry *p; if (!idev || !idev->dev) return -EINVAL; - if (snmp6_mib_init((void **)idev->stats.icmpv6, sizeof(struct icmpv6_mib), - __alignof__(struct icmpv6_mib)) < 0) - goto err_icmp; + if (!proc_net_devsnmp6) + return -ENOENT; - if (!proc_net_devsnmp6) { - err = -ENOENT; - goto err_proc; - } p = create_proc_entry(idev->dev->name, S_IRUGO, proc_net_devsnmp6); if (!p) - goto err_proc; + return -ENOMEM; + p->data = idev; p->proc_fops = &snmp6_seq_fops; idev->stats.proc_dir_entry = p; return 0; - -err_proc: - snmp6_mib_free((void **)idev->stats.icmpv6); -err_icmp: - return err; } int snmp6_unregister_dev(struct inet6_dev *idev) @@ -238,8 +228,6 @@ return -EINVAL; remove_proc_entry(idev->stats.proc_dir_entry->name, proc_net_devsnmp6); - snmp6_mib_free((void **)idev->stats.icmpv6); - return 0; } @@ -280,6 +268,17 @@ int snmp6_register_dev(struct inet6_dev *idev) { + return 0; +} + +int snmp6_unregister_dev(struct inet6_dev *idev) +{ + return 0; +} +#endif /* CONFIG_PROC_FS */ + +int snmp6_alloc_dev(struct inet6_dev *idev) +{ int err = -ENOMEM; if (!idev || !idev->dev) @@ -295,11 +294,10 @@ return err; } -int snmp6_unregister_dev(struct inet6_dev *idev) +int snmp6_free_dev(struct inet6_dev *idev) { snmp6_mib_free((void **)idev->stats.icmpv6); return 0; } -#endif -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Wed Feb 23 08:42:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 08:42:39 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NGgZeI021963 for ; Wed, 23 Feb 2005 08:42:35 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4F4CF33CC2; Thu, 24 Feb 2005 01:43:56 +0900 (JST) Date: Thu, 24 Feb 2005 01:43:55 +0900 (JST) Message-Id: <20050224.014355.00064571.yoshfuji@linux-ipv6.org> To: AndyLiebman@aol.com Cc: herbert@gondor.apana.org.au, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org Subject: Re: Frequent Oops on Shutdown 2.6.10 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1985 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: 399 Lines: 11 In article (at Wed, 23 Feb 2005 09:51:44 EST), AndyLiebman@aol.com says: > Should I bother to apply this patch, or should I wait for you to make this > last change? What did you think about my comment that the Oops only occurred > when the Ethernet cable had been unplugged during operation? Well, not sure, but I think it is worth trying. Thanks. --yoshfuji From willy@gardiol.org Wed Feb 23 10:05:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 10:06:00 -0800 (PST) Received: from smtpa1.aruba.it (smtpa1.aruba.it [62.149.128.206] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NI5nvr026411 for ; Wed, 23 Feb 2005 10:05:50 -0800 Received: (qmail 20461 invoked by uid 511); 23 Feb 2005 18:04:48 -0000 Received: from willy@gardiol.org by smtpa1.aruba.it by uid 503 with qmail-scanner-1.20 (avp(2004-04-15). Clear:RC:0(213.140.6.110):. Processed in 0.038832 secs); 23 Feb 2005 18:04:48 -0000 Received: from unknown (HELO ?41.5.1.42?) (willy@gardiol.org@213.140.6.110) by smtpa1.aruba.it with SMTP; 23 Feb 2005 18:04:48 -0000 From: Willy Gardiol Reply-To: willy@gardiol.org To: Francois Romieu Subject: Re: The 8169 driver: issue with cross cable Date: Wed, 23 Feb 2005 19:05:00 +0100 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200502192011.25428.willy@gardiol.org> <200502201712.49589.willy@gardiol.org> <20050223003056.GA12696@electric-eye.fr.zoreil.com> In-Reply-To: <20050223003056.GA12696@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1207170.ZnF2qGF01C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502231905.02656.willy@gardiol.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@gardiol.org Precedence: bulk X-list: netdev Content-Length: 3035 Lines: 100 --nextPart1207170.ZnF2qGF01C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On the client fstab is: /dev/sda1 /boot ext2 noatime,noauto = =20 0 0 192.168.0.1:/shimitar / nfs =20 noatime,rsize=3D8192,wsize=3D8192 0 0 192.168.0.1:/shimitar/home /home nfs =20 noatime,rsize=3D8192,wsize=3D8192 0 0 192.168.0.1:/shimitar/deposito /deposito nfs =20 noatime,rsize=3D16384,wsize=3D16384 0 0 192.168.0.1:/shimitar/deposito2 /deposito2 nfs =20 noatime,rsize=3D16384,wsize=3D16384 0 0 (sda1 is a USB key, not mounted by default) On the server fstab is: /dev/hdc1 /shimitar ext3 noatime = =20 0 0 /dev/hdc2 /shimitar/home ext3 noatime = =20 0 0 /dev/hda4 /shimitar/deposito2 ext3 noatime = =20 0 0 /dev/hdc4 /shimitar/deposito ext3 noatime = =20 0 0 And exports is: /shimitar 192.168.0.2(rw,no_root_squash,async,no_subtree_check) /shimitar/home 192.168.0.2(rw,no_root_squash,async,no_subtree_check) /shimitar/deposito 192.168.0.2(rw,no_root_squash,async,no_subtree_check) /shimitar/deposito2 192.168.0.2(rw,no_root_squash,async,no_subtree_check) /mnt/tmp 192.168.0.2(rw,no_root_squash,async,no_subtree_chec= k) (mnt/tmp is not mounted on the client). Something i did not emphatized: both boxes are connected to the internet vi= a=20 another eth device.=20 The network configuration is: =2D a switch 100mbit connected to the internet, each box has a direct cable= to=20 the switch (via 8139too eth device on both boxes). Dhcp. =2D a cross cable between the two boxes connecting the r8169 eth device.=20 192.168.0.0/24. Alle Wednesday 23 February 2005 01:30, Francois Romieu ha scritto: > Willy Gardiol : > [...] > > > http://www.gardiol.org/r8169/1000-client.tar.bz2 > > http://www.gardiol.org/r8169/1000-server.tar.bz2 > > http://www.gardiol.org/r8169/100-client.tar.bz2 > > http://www.gardiol.org/r8169/100-server.tar.bz2 > > Can you add a minimal exports/mount option description so that > I try to reproduce it here ? > > -- > Ueimor =2D-=20 !=20 Willy Gardiol - willy@gardiol.org www.gardiol.org +39 3492800983 Use linux for MY freedom.=20 Your freedom may come as a side effect. "L'altrove =E8 uno specchio in negativo.=20 Il viaggiatore riconosce il poco che =E8 suo,=20 scoprendo il molto che non ha avuto e non avr=E0" Italo Calvino - Le citt=E0 invisibili --nextPart1207170.ZnF2qGF01C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCHMXOvgbSPju7wvkRAr6XAJ9YNArolHldzPvdhuTcjRyrpNHIDwCgvWU1 jpPgb1pfXaJ0Ui0D0z0RfLM= =n5M+ -----END PGP SIGNATURE----- --nextPart1207170.ZnF2qGF01C-- From rhee@eos.ncsu.edu Wed Feb 23 10:31:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 10:31:09 -0800 (PST) Received: from uni07mr.unity.ncsu.edu (uni07mr.unity.ncsu.edu [152.1.1.170]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NIV3Al027612 for ; Wed, 23 Feb 2005 10:31:04 -0800 Received: from VALUED66329DCC (bakdu.csc.ncsu.edu [152.14.51.150]) by uni07mr.unity.ncsu.edu (8.12.10/8.12.10/N.20040817.03) with ESMTP id j1NIUC2T019474; Wed, 23 Feb 2005 13:30:13 -0500 (EST) Message-Id: <200502231830.j1NIUC2T019474@uni07mr.unity.ncsu.edu> From: "Injong Rhee" To: "'Hubert Tonneau'" , "'Stephen Hemminger'" , "'cliff white'" Cc: "'Alexey Kuznetsov'" , , "'David S. Miller'" Subject: RE: [RFT] BIC TCP delayed ack compensation Date: Wed, 23 Feb 2005 13:32:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZMgHZZJ600QnDQLu2Rlc7tK+91QAo69yg In-Reply-To: <052Q0TU11@server5.heliogroup.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.2.23.9 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 735 Lines: 19 > -----Original Message----- > From: Hubert Tonneau [mailto:hubert.tonneau@fullpliant.org] > Sent: Tuesday, February 22, 2005 5:23 PM > 2.6.9 to 100 Mbps connected MacOSX: 15 seconds (for roughly 100 MB > or data) > 2.6.9 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11 to 100 Mbps connected MacOSX: 325 seconds It seems that there are other problems with this version of Linux. Is there any way we can find out what the problems are. Is this with BIC? If not, there are some parts not working. If it is with BIC, we would like to look into this problem. > 2.6.10-ac11 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11+BIC to 100 Mbps connected MacOSX: 620 seconds > 2.6.10-ac11+BIC to gigabit connected MacOSX: 5 seconds From rhee@eos.ncsu.edu Wed Feb 23 10:36:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 10:36:09 -0800 (PST) Received: from uni07mr.unity.ncsu.edu (uni07mr.unity.ncsu.edu [152.1.1.170]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NIa5Q7028296 for ; Wed, 23 Feb 2005 10:36:06 -0800 Received: from VALUED66329DCC (bakdu.csc.ncsu.edu [152.14.51.150]) by uni07mr.unity.ncsu.edu (8.12.10/8.12.10/N.20040817.03) with ESMTP id j1NIZX2T020606; Wed, 23 Feb 2005 13:35:34 -0500 (EST) Message-Id: <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> From: "Injong Rhee" To: "'Hubert Tonneau'" , "'Stephen Hemminger'" , "'cliff white'" Cc: "'Alexey Kuznetsov'" , , "'David S. Miller'" Subject: RE: [RFT] BIC TCP delayed ack compensation Date: Wed, 23 Feb 2005 13:37:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUZMgHZZJ600QnDQLu2Rlc7tK+91QApGn8w In-Reply-To: <052Q0TU11@server5.heliogroup.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.2.23.9 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 739 Lines: 18 > -----Original Message----- > From: Hubert Tonneau [mailto:hubert.tonneau@fullpliant.org] > Sent: Tuesday, February 22, 2005 5:23 PM > 2.6.9 to 100 Mbps connected MacOSX: 15 seconds (for roughly 100 MB > or data) > 2.6.9 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11 to 100 Mbps connected MacOSX: 325 seconds > 2.6.10-ac11 to gigabit connected MacOSX: 5 seconds > 2.6.10-ac11+BIC to 100 Mbps connected MacOSX: 620 seconds > 2.6.10-ac11+BIC to gigabit connected MacOSX: 5 seconds Another way to test whether this is related to the os or bic implementation is to test it with our bic patch 1.1. + Linux 2.4. It will tell whether the original implementation of BIC has something to do with the performance with respect to MacOS. From davem@davemloft.net Wed Feb 23 11:27:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:28:04 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NJRwqX031105 for ; Wed, 23 Feb 2005 11:27:58 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D429D-0007h1-00; Wed, 23 Feb 2005 11:26:11 -0800 Date: Wed, 23 Feb 2005 11:26:11 -0800 From: "David S. Miller" To: "Injong Rhee" Cc: hubert.tonneau@fullpliant.org, shemminger@osdl.org, cliffw@osdl.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [RFT] BIC TCP delayed ack compensation Message-Id: <20050223112611.60561121.davem@davemloft.net> In-Reply-To: <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> References: <052Q0TU11@server5.heliogroup.fr> <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1006 Lines: 24 On Wed, 23 Feb 2005 13:37:35 -0500 "Injong Rhee" wrote: > > > > -----Original Message----- > > From: Hubert Tonneau [mailto:hubert.tonneau@fullpliant.org] > > Sent: Tuesday, February 22, 2005 5:23 PM > > 2.6.9 to 100 Mbps connected MacOSX: 15 seconds (for roughly 100 MB > > or data) > > 2.6.9 to gigabit connected MacOSX: 5 seconds > > 2.6.10-ac11 to 100 Mbps connected MacOSX: 325 seconds > > 2.6.10-ac11 to gigabit connected MacOSX: 5 seconds > > 2.6.10-ac11+BIC to 100 Mbps connected MacOSX: 620 seconds > > 2.6.10-ac11+BIC to gigabit connected MacOSX: 5 seconds > > Another way to test whether this is related to the os or bic > implementation is to test it with our bic patch 1.1. + Linux 2.4. It > will tell whether the original implementation of BIC has something to > do with the performance with respect to MacOS. I don't think BIC has much to do with this problem. MacOS-X does delayed ACKs until a PSH is seen and this kills performance if we don't PSH often enough. From davem@davemloft.net Wed Feb 23 11:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:30:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NJUVBC031661 for ; Wed, 23 Feb 2005 11:30:32 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D42CO-0007i2-00; Wed, 23 Feb 2005 11:29:28 -0800 Date: Wed, 23 Feb 2005 11:29:27 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Bug-hunting Message-Id: <20050223112927.349550d0.davem@davemloft.net> In-Reply-To: <421C5AC8.70601@rapidforum.com> References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 351 Lines: 8 On Wed, 23 Feb 2005 11:28:24 +0100 Christian Schmid wrote: > I would have to write a test-program first. This needs time. Before I spend hours into coding this, > first just tell me how I can raise the global-limit from around 600-700 MB to 1500 MB. The limit is in the tcp_mem sysctl, I believe we told you this before. From shemminger@osdl.org Wed Feb 23 11:36:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:37:00 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NJatxa032293 for ; Wed, 23 Feb 2005 11:36:56 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1NJaSqi027318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 11:36:28 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1NJaR11010164; Wed, 23 Feb 2005 11:36:28 -0800 Date: Wed, 23 Feb 2005 11:36:41 -0800 From: Stephen Hemminger To: "Injong Rhee" Cc: "'Hubert Tonneau'" , "'cliff white'" , "'Alexey Kuznetsov'" , , "'David S. Miller'" Subject: Re: [RFT] BIC TCP delayed ack compensation Message-ID: <20050223113641.3f9404ef@dxpl.pdx.osdl.net> In-Reply-To: <200502231830.j1NIUC2T019474@uni07mr.unity.ncsu.edu> References: <052Q0TU11@server5.heliogroup.fr> <200502231830.j1NIUC2T019474@uni07mr.unity.ncsu.edu> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1991 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: 230 Lines: 8 An interesting test would be to repeat the slow case: 2.6.10-ac11 over 100Mbps With first TCP Reno (old default). sysctl -w net.ipv4.tcp_bic=0 then TCP Westwood. sysctl -w net.ipv4.tcp_bic=0 sysctl -w net.ipv4.tcp_westwood=1 From webmaster@rapidforum.com Wed Feb 23 11:42:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:42:17 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NJgBLG000455 for ; Wed, 23 Feb 2005 11:42:12 -0800 Received: (qmail 23197 invoked by uid 1004); 23 Feb 2005 19:42:11 -0000 Received: from p3ee04291.dip0.t-ipconnect.de (HELO ?62.224.66.145?) (62.224.66.145) by www.rapidforum.com with SMTP; 23 Feb 2005 19:42:11 -0000 Message-ID: <421CDC73.9080006@rapidforum.com> Date: Wed, 23 Feb 2005 20:41:39 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> <20050223112927.349550d0.davem@davemloft.net> In-Reply-To: <20050223112927.349550d0.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 585 Lines: 20 /proc/sys/net/ipv4/tcp_mem? Its set to 98304 131072 196608 I have changed this to 1024000 1025000 1026000 It didnt change anything. The send-buffer still keeps being shrinked down. David S. Miller wrote: > On Wed, 23 Feb 2005 11:28:24 +0100 > Christian Schmid wrote: > > >>I would have to write a test-program first. This needs time. Before I spend hours into coding this, >>first just tell me how I can raise the global-limit from around 600-700 MB to 1500 MB. > > > The limit is in the tcp_mem sysctl, I believe we told you this > before. > > From webmaster@rapidforum.com Wed Feb 23 11:47:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:47:09 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NJl2K4001104 for ; Wed, 23 Feb 2005 11:47:02 -0800 Received: (qmail 23685 invoked by uid 1004); 23 Feb 2005 19:47:02 -0000 Received: from p3ee04291.dip0.t-ipconnect.de (HELO ?62.224.66.145?) (62.224.66.145) by www.rapidforum.com with SMTP; 23 Feb 2005 19:47:02 -0000 Message-ID: <421CDD95.2020108@rapidforum.com> Date: Wed, 23 Feb 2005 20:46:29 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> <20050223112927.349550d0.davem@davemloft.net> In-Reply-To: <20050223112927.349550d0.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 600 Lines: 16 Can I see somewhere how much memory tcp needs right now so to see if that changes effect something? Maybe the error is somewhere else so I need to check if memory-usage raises if I change the values. David S. Miller wrote: > On Wed, 23 Feb 2005 11:28:24 +0100 > Christian Schmid wrote: > > >>I would have to write a test-program first. This needs time. Before I spend hours into coding this, >>first just tell me how I can raise the global-limit from around 600-700 MB to 1500 MB. > > > The limit is in the tcp_mem sysctl, I believe we told you this > before. > > From davem@davemloft.net Wed Feb 23 11:54:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 11:54:54 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NJsoqb002047 for ; Wed, 23 Feb 2005 11:54:50 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D42Zv-0007rN-00; Wed, 23 Feb 2005 11:53:47 -0800 Date: Wed, 23 Feb 2005 11:53:46 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Bug-hunting Message-Id: <20050223115346.2f08866b.davem@davemloft.net> In-Reply-To: <421CDC73.9080006@rapidforum.com> References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> <20050223112927.349550d0.davem@davemloft.net> <421CDC73.9080006@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 399 Lines: 14 On Wed, 23 Feb 2005 20:41:39 +0100 Christian Schmid wrote: > /proc/sys/net/ipv4/tcp_mem? > > Its set to 98304 131072 196608 > I have changed this to 1024000 1025000 1026000 > > It didnt change anything. The send-buffer still keeps being shrinked down. That's why I felt silly telling you again where the limit is configured. Please write the test program already. From jheffner@psc.edu Wed Feb 23 12:00:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 12:00:33 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NK0R9Q002888 for ; Wed, 23 Feb 2005 12:00:28 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id j1NK0ALu009187 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 15:00:10 -0500 (EST) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j1NK0AlT028590; Wed, 23 Feb 2005 15:00:10 -0500 Date: Wed, 23 Feb 2005 15:00:10 -0500 (EST) From: John Heffner To: Christian Schmid cc: netdev@oss.sgi.com Subject: Re: Bug-hunting In-Reply-To: <421CDD95.2020108@rapidforum.com> Message-ID: References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> <20050223112927.349550d0.davem@davemloft.net> <421CDD95.2020108@rapidforum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 1995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 201 Lines: 7 Christian, Try looking at /proc/net/netstat while running. If TCPMemoryPressures is increasing, you are running out of TCP memory, and you would expect to see your socket buffers shrinking. -John From romieu@fr.zoreil.com Wed Feb 23 13:00:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 13:00:07 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NL00gV008746 for ; Wed, 23 Feb 2005 13:00:01 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1NKwx12031623; Wed, 23 Feb 2005 21:58:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1NKwrjp031622; Wed, 23 Feb 2005 21:58:53 +0100 Date: Wed, 23 Feb 2005 21:58:53 +0100 From: Francois Romieu To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, jgarzik@pobox.com Subject: [patch 2.6.11-rc4-mm1 1/2] r8169: IRQ races during change of mtu Message-ID: <20050223205853.GA30109@electric-eye.fr.zoreil.com> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> <20050222172935.30e43270.akpm@osdl.org> <20050223085921.GA22268@electric-eye.fr.zoreil.com> <20050223010948.6f2aa542.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050223010948.6f2aa542.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1996 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: 2026 Lines: 74 IRQ races during change of mtu - NAPI poll must be enabled prior to IRQ activation or the IRQ handler will not know what to do with an incoming packet; - rtl8169_down() needs to try twice to sync with the IRQ handler when it is not issued under !netif_running() protection. Both changes make it safe to request a change of mtu on a live device. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-450 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-450 2005-02-23 21:35:21.112521942 +0100 +++ b/drivers/net/r8169.c 2005-02-23 21:35:21.117521120 +0100 @@ -1648,10 +1648,10 @@ static int rtl8169_change_mtu(struct net if (ret < 0) goto out; - rtl8169_hw_start(dev); - netif_poll_enable(dev); + rtl8169_hw_start(dev); + rtl8169_request_timer(dev); out: @@ -2352,6 +2352,7 @@ static void rtl8169_down(struct net_devi { struct rtl8169_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->mmio_addr; + unsigned int poll_locked = 0; rtl8169_delete_timer(dev); @@ -2359,6 +2360,7 @@ static void rtl8169_down(struct net_devi flush_scheduled_work(); +core_down: spin_lock_irq(&tp->lock); /* Stop the chip's Tx and Rx DMA processes. */ @@ -2375,11 +2377,28 @@ static void rtl8169_down(struct net_devi synchronize_irq(dev->irq); - netif_poll_disable(dev); + if (!poll_locked) { + netif_poll_disable(dev); + poll_locked++; + } /* Give a racing hard_start_xmit a few cycles to complete. */ synchronize_kernel(); + /* + * And now for the 50k$ question: are IRQ disabled or not ? + * + * Two paths lead here: + * 1) dev->close + * -> netif_running() is available to sync the current code and the + * IRQ handler. See rtl8169_interrupt for details. + * 2) dev->change_mtu + * -> rtl8169_poll can not be issued again and re-enable the + * interruptions. Let's simply issue the IRQ down sequence again. + */ + if (RTL_R16(IntrMask)) + goto core_down; + rtl8169_tx_clear(tp); rtl8169_rx_clear(tp); _ From romieu@fr.zoreil.com Wed Feb 23 13:07:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 13:08:02 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NL7vRx009931 for ; Wed, 23 Feb 2005 13:07:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1NL3uJI031826; Wed, 23 Feb 2005 22:03:56 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1NL3oZo031812; Wed, 23 Feb 2005 22:03:50 +0100 Date: Wed, 23 Feb 2005 22:03:50 +0100 From: Francois Romieu To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jdmason@us.ibm.com, rich@phekda.gotadsl.co.uk, jgarzik@pobox.com Subject: [patch 2.6.11-rc4-mm1 2/2] r8169: factor out some code. Message-ID: <20050223210350.GA31312@electric-eye.fr.zoreil.com> References: <20050222234810.GA17303@electric-eye.fr.zoreil.com> <20050222172935.30e43270.akpm@osdl.org> <20050223085921.GA22268@electric-eye.fr.zoreil.com> <20050223010948.6f2aa542.akpm@osdl.org> <20050223205853.GA30109@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050223205853.GA30109@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1997 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: 1545 Lines: 62 Factor out some code Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-460 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-460 2005-02-23 21:35:28.715271999 +0100 +++ b/drivers/net/r8169.c 2005-02-23 21:35:28.720271177 +0100 @@ -495,6 +495,13 @@ static void rtl8169_irq_mask_and_ack(voi RTL_W16(IntrStatus, 0xffff); } +static void rtl8169_asic_down(void __iomem *ioaddr) +{ + RTL_W8(ChipCmd, 0x00); + rtl8169_irq_mask_and_ack(ioaddr); + RTL_R16(CPlusCmd); +} + static unsigned int rtl8169_tbi_reset_pending(void __iomem *ioaddr) { return RTL_R32(TBICSR) & TBIReset; @@ -2260,8 +2267,10 @@ rtl8169_interrupt(int irq, void *dev_ins handled = 1; - if (unlikely(!netif_running(dev))) - goto out_asic_stop; + if (unlikely(!netif_running(dev))) { + rtl8169_asic_down(ioaddr); + goto out; + } status &= tp->intr_mask; RTL_W16(IntrStatus, @@ -2310,12 +2319,6 @@ rtl8169_interrupt(int irq, void *dev_ins } out: return IRQ_RETVAL(handled); - -out_asic_stop: - RTL_W8(ChipCmd, 0x00); - rtl8169_irq_mask_and_ack(ioaddr); - RTL_R16(CPlusCmd); - goto out; } #ifdef CONFIG_R8169_NAPI @@ -2363,11 +2366,7 @@ static void rtl8169_down(struct net_devi core_down: spin_lock_irq(&tp->lock); - /* Stop the chip's Tx and Rx DMA processes. */ - RTL_W8(ChipCmd, 0x00); - - /* Disable interrupts by clearing the interrupt mask. */ - RTL_W16(IntrMask, 0x0000); + rtl8169_asic_down(ioaddr); /* Update the error counts. */ tp->stats.rx_missed_errors += RTL_R32(RxMissed); _ From greearb@candelatech.com Wed Feb 23 13:08:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 13:08:16 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NL8AU3010006 for ; Wed, 23 Feb 2005 13:08:11 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1NLTjLH031474; Wed, 23 Feb 2005 13:29:45 -0800 Message-ID: <421CF0BA.1020100@candelatech.com> Date: Wed, 23 Feb 2005 13:08:10 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: linux-kernel Subject: Tulip (DFE-570tx) & keyboard lockup in 2.6.9 and other 2.6 kernels. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1998 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: 3659 Lines: 91 I finally had some time to debug this one a little more thoroughly. On two different machines (Shuttle SB61G1) I get the same results, so I do not believe it is bad hardware... The bug is as follows: I have 1 4-port tulip NIC in the machine. If I generate traffic between two interfaces, it runs fine. But, if I start running traffic on all 4 interfaces, the keyboard quits taking input, and ethernet traffic stops on at least a few of the interfaces. I can still ssh into the machine (via the rtl8139 interface), so at least one of the processors (I'm using SMP on an P4 HT processor) is working. I also enabled NMI and that does not trigger. I ran the tulip-diag tool, and the third interface seems to be in a bad way: [root@lf61g2-blk root]# tulip-diag tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc000. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc100. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #3: Found a Digital DS21143 Tulip adapter at 0xc200. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #4: Found a Digital DS21143 Tulip adapter at 0xc300. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. The interrupt count for eth3 is not increasing. I tried to bring down the interface with 'ifconfig eth3 down' and that command hung as well. I tried getting sysrq to print out the stack for ifconfig, but I'm not sure it worked: ifconfig R running 6128 3692 3631 (NOTLB) sshd S D9717E6C 6488 3693 2193 3695 3629 (NOTLB) d9717eac 00000082 d9721954 d9717e6c 00000000 c0356580 c0335d00 c0335c80 00000286 b04a5e80 000f44f5 00000019 de056890 00000008 00000000 c1402980 c1402020 00000001 00000000 b04a5e80 000f44f5 de056df0 de056f58 00000001 Call Trace: [] schedule_timeout+0xc3/0xc5 [] normal_poll+0x0/0x134 [] tty_ldisc_deref+0x63/0x7d [] tty_poll+0x90/0xb2 [] do_select+0x193/0x2b9 [] __pollwait+0x0/0xc1 [] sys_select+0x29b/0x50c [] sysenter_past_esp+0x52/0x71 bash R running 6620 3695 3693 (NOTLB) I tried this same hardware running RH9 with the 2.4.27 kernel and it works like a charm. This is easily repeatable, so please let me know what information I can offer to help debug this. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From baruch@ev-en.org Wed Feb 23 13:30:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 13:30:38 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NLUT1p012445 for ; Wed, 23 Feb 2005 13:30:30 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 0665211A5E9; Wed, 23 Feb 2005 23:30:21 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id C14BC11A5D5; Wed, 23 Feb 2005 23:30:14 +0200 (IST) Message-ID: <421CF5E5.1060606@ev-en.org> Date: Wed, 23 Feb 2005 21:30:13 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, Yee-Ting Li , Doug Leith Subject: [PATCH] select congestion control with one sysctl X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------010108020005060401030407" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 11017 Lines: 374 This is a multi-part message in MIME format. --------------010108020005060401030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This patch makes selection of congestion control algorithm simpler by using a single sysctl for that purpose, rather than a cascade of sysctls. The patch also does some minor cleanups to avoid cascade actions between algorithms so that flow control is cleaner. Possible improvements: - Use a string when reading/writing from sysctl to make it more friendly to humans. - And/Or, provide a list of all available congestion control algorithms. The patch is against 2.6.11-rc4-bk9. Signed-Off-By: Yee-Ting Li Signed-Off-By: Baruch Even --------------010108020005060401030407 Content-Type: text/x-patch; name="cong_control_change.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cong_control_change.patch" This patch makes selection of congestion control algorithm simpler by using a single sysctl for that purpose, rather than a cascade of sysctls. The patch also does some minor cleanups to avoid cascade actions between algorithms so that flow control is cleaner. Possible improvements: - Use a string when reading/writing from sysctl to make it more friendly to humans - And/Or, provide a list of all available congestion control algorithms The patch is against 2.6.11-rc4-bk9. Signed-Off-By: Yee-Ting Li Signed-Off-By: Baruch Even Index: 2.6.11-select/include/linux/sysctl.h =================================================================== --- 2.6.11-select.orig/include/linux/sysctl.h +++ 2.6.11-select/include/linux/sysctl.h @@ -344,6 +344,7 @@ enum NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, + NET_TCP_ADV_CONG=108, }; enum { Index: 2.6.11-select/include/net/tcp.h =================================================================== --- 2.6.11-select.orig/include/net/tcp.h +++ 2.6.11-select/include/net/tcp.h @@ -597,13 +597,11 @@ extern int sysctl_tcp_adv_win_scale; extern int sysctl_tcp_tw_reuse; extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; -extern int sysctl_tcp_westwood; -extern int sysctl_tcp_vegas_cong_avoid; extern int sysctl_tcp_vegas_alpha; extern int sysctl_tcp_vegas_beta; extern int sysctl_tcp_vegas_gamma; extern int sysctl_tcp_nometrics_save; -extern int sysctl_tcp_bic; +extern int sysctl_tcp_adv_cong; extern int sysctl_tcp_bic_fast_convergence; extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_moderate_rcvbuf; @@ -1241,7 +1239,8 @@ static __inline__ unsigned int tcp_packe */ static inline __u32 tcp_recalc_ssthresh(struct tcp_sock *tp) { - if (tcp_is_bic(tp)) { + switch (tp->adv_cong) { + case TCP_BIC: if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) tp->bictcp.last_max_cwnd @@ -1253,9 +1252,11 @@ static inline __u32 tcp_recalc_ssthresh( if (tp->snd_cwnd > sysctl_tcp_bic_low_window) return max(tp->snd_cwnd - (tp->snd_cwnd/BICTCP_1_OVER_BETA), 2U); - } + break; - return max(tp->snd_cwnd >> 1U, 2U); + default: + return max(tp->snd_cwnd >> 1U, 2U); + } } /* Stop taking Vegas samples for now. */ @@ -1980,24 +1981,19 @@ static inline void tcp_westwood_update_r tp->westwood.rtt = rtt_seq; } -static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) +static inline __u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / (__u32) (tp->mss_cache_std), 2U); } -static inline __u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) -{ - return tcp_is_westwood(tp) ? __tcp_westwood_bw_rttmin(tp) : 0; -} - static inline int tcp_westwood_ssthresh(struct tcp_sock *tp) { __u32 ssthresh = 0; if (tcp_is_westwood(tp)) { - ssthresh = __tcp_westwood_bw_rttmin(tp); + ssthresh = tcp_westwood_bw_rttmin(tp); if (ssthresh) tp->snd_ssthresh = ssthresh; } @@ -2010,7 +2006,7 @@ static inline int tcp_westwood_cwnd(stru __u32 cwnd = 0; if (tcp_is_westwood(tp)) { - cwnd = __tcp_westwood_bw_rttmin(tp); + cwnd = tcp_westwood_bw_rttmin(tp); if (cwnd) tp->snd_cwnd = cwnd; } Index: 2.6.11-select/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.11-select.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.11-select/net/ipv4/sysctl_net_ipv4.c @@ -602,22 +602,14 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec, }, - { - .ctl_name = NET_TCP_WESTWOOD, - .procname = "tcp_westwood", - .data = &sysctl_tcp_westwood, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS, - .procname = "tcp_vegas_cong_avoid", - .data = &sysctl_tcp_vegas_cong_avoid, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, + { + .ctl_name = NET_TCP_ADV_CONG, + .procname = "tcp_adv_cong", + .data = &sysctl_tcp_adv_cong, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = NET_TCP_VEGAS_ALPHA, .procname = "tcp_vegas_alpha", @@ -643,14 +635,6 @@ ctl_table ipv4_table[] = { .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_BIC, - .procname = "tcp_bic", - .data = &sysctl_tcp_bic, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { .ctl_name = NET_TCP_BIC_FAST_CONVERGENCE, .procname = "tcp_bic_fast_convergence", .data = &sysctl_tcp_bic_fast_convergence, Index: 2.6.11-select/net/ipv4/tcp_input.c =================================================================== --- 2.6.11-select.orig/net/ipv4/tcp_input.c +++ 2.6.11-select/net/ipv4/tcp_input.c @@ -87,8 +87,6 @@ int sysctl_tcp_rfc1337; int sysctl_tcp_max_orphans = NR_FILE; int sysctl_tcp_frto; int sysctl_tcp_nometrics_save; -int sysctl_tcp_westwood; -int sysctl_tcp_vegas_cong_avoid; int sysctl_tcp_moderate_rcvbuf = 1; @@ -99,10 +97,11 @@ int sysctl_tcp_moderate_rcvbuf = 1; int sysctl_tcp_vegas_alpha = 1<adv_cong = TCP_WESTWOOD; - else if (sysctl_tcp_bic) - tp->adv_cong = TCP_BIC; - else if (sysctl_tcp_vegas_cong_avoid) { - tp->adv_cong = TCP_VEGAS; - tp->vegas.baseRTT = 0x7fffffff; - tcp_vegas_enable(tp); - } + switch (sysctl_tcp_adv_cong) { + case TCP_VEGAS: + tp->vegas.baseRTT = 0x7fffffff; + tcp_vegas_enable(tp); + /* Fallthrough */ + case TCP_BIC: + case TCP_WESTWOOD: + tp->adv_cong = sysctl_tcp_adv_cong; + break; + default: + tp->adv_cong = TCP_RENO; + } } /* Do RTT sampling needed for Vegas. @@ -1600,18 +1602,25 @@ static void tcp_cwnd_down(struct tcp_soc int decr = tp->snd_cwnd_cnt + 1; __u32 limit; - /* - * TCP Westwood - * Here limit is evaluated as BWestimation*RTTmin (for obtaining it - * in packets we use mss_cache). If sysctl_tcp_westwood is off - * tcp_westwood_bw_rttmin() returns 0. In such case snd_ssthresh is - * still used as usual. It prevents other strange cases in which - * BWE*RTTmin could assume value 0. It should not happen but... - */ + switch (tp->adv_cong) { + case TCP_WESTWOOD: + /* + * TCP Westwood + * Here limit is evaluated as BWestimation*RTTmin (for obtaining it + * in packets we use mss_cache). The guard is against + * strange cases in which BWE*RTTmin could assume value + * 0. It should not happen but... + */ - if (!(limit = tcp_westwood_bw_rttmin(tp))) - limit = tp->snd_ssthresh/2; + if (!(limit = tcp_westwood_bw_rttmin(tp))) + limit = tp->snd_ssthresh/2; + break; + default: + limit = tp->snd_ssthresh/2; + break; + } + tp->snd_cwnd_cnt = decr&1; decr >>= 1; @@ -2014,6 +2023,27 @@ static inline void tcp_ack_update_rtt(st tcp_ack_no_tstamp(tp, seq_rtt, flag); } +static inline void tcp_slow_start(struct tcp_sock *tp) +{ + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; +} + +static inline void tcp_increase_cwnd(struct tcp_sock *tp, __u32 window) +{ + /* In dangerous area, increase slowly. + * In theory, for standard tcp, this is tp->snd_cwnd += 1 / window + * (snd_cwnd for Reno) + */ + if (tp->snd_cwnd_cnt >= window) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } else + tp->snd_cwnd_cnt++; +} + /* * Compute congestion window to use. * @@ -2029,10 +2059,6 @@ static inline void tcp_ack_update_rtt(st */ static inline __u32 bictcp_cwnd(struct tcp_sock *tp) { - /* orignal Reno behaviour */ - if (!tcp_is_bic(tp)) - return tp->snd_cwnd; - if (tp->bictcp.last_cwnd == tp->snd_cwnd && (s32)(tcp_time_stamp - tp->bictcp.last_stamp) <= (HZ>>5)) return tp->bictcp.cnt; @@ -2080,23 +2106,13 @@ static inline __u32 bictcp_cwnd(struct t /* This is Jacobson's slow start and congestion avoidance. * SIGCOMM '88, p. 328. */ -static inline void reno_cong_avoid(struct tcp_sock *tp) +static inline void reno_cong_avoid(struct tcp_sock *tp, u32 snd_cwnd) { - if (tp->snd_cwnd <= tp->snd_ssthresh) { - /* In "safe" area, increase. */ - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - } else { - /* In dangerous area, increase slowly. - * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd - */ - if (tp->snd_cwnd_cnt >= bictcp_cwnd(tp)) { - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - tp->snd_cwnd_cnt=0; - } else - tp->snd_cwnd_cnt++; - } + if (tp->snd_cwnd <= tp->snd_ssthresh) + tcp_slow_start(tp); + else + tcp_increase_cwnd(tp, snd_cwnd); + tp->snd_cwnd_stamp = tcp_time_stamp; } @@ -2324,10 +2340,22 @@ static void vegas_cong_avoid(struct tcp_ static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) { - if (tcp_vegas_enabled(tp)) - vegas_cong_avoid(tp, ack, seq_rtt); - else - reno_cong_avoid(tp); + if (tp->snd_cwnd >= tp->snd_cwnd_clamp) + return; + + switch (sysctl_tcp_adv_cong) { + case TCP_VEGAS: + vegas_cong_avoid(tp, ack, seq_rtt); + break; + + case TCP_BIC: + reno_cong_avoid(tp, bictcp_cwnd(tp)); + break; + + default: + reno_cong_avoid(tp, tp->snd_cwnd); + break; + } } /* Restart timer after forward progress on connection. --------------010108020005060401030407-- From davem@davemloft.net Wed Feb 23 13:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 13:58:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NLwm68014195 for ; Wed, 23 Feb 2005 13:58:48 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D44Vg-00008g-00; Wed, 23 Feb 2005 13:57:32 -0800 Date: Wed, 23 Feb 2005 13:57:32 -0800 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, yee-ting.li@nuim.ie, doug.leith@nuim.ie Subject: Re: [PATCH] select congestion control with one sysctl Message-Id: <20050223135732.39e62c6c.davem@davemloft.net> In-Reply-To: <421CF5E5.1060606@ev-en.org> References: <421CF5E5.1060606@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 306 Lines: 9 For the millionth time, you can't just delete the existing sysctls. That is a user visisble interface. Instead, you have to make them at least appear to select a single congestion control algorithm as I stated in the following posting: http://marc.theaimsgroup.com/?l=linux-kernel&m=110909973530321&w=2 From jheffner@psc.edu Wed Feb 23 14:04:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 14:04:29 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NM4PeU014870 for ; Wed, 23 Feb 2005 14:04:25 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id j1NM4BLu012275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 17:04:11 -0500 (EST) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j1NM48ve029253; Wed, 23 Feb 2005 17:04:08 -0500 Date: Wed, 23 Feb 2005 17:04:08 -0500 (EST) From: John Heffner To: "David S. Miller" cc: hubert.tonneau@fullpliant.org, netdev@oss.sgi.com Subject: Re: [RFT] BIC TCP delayed ack compensation In-Reply-To: <20050223112611.60561121.davem@davemloft.net> Message-ID: References: <052Q0TU11@server5.heliogroup.fr> <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> <20050223112611.60561121.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 2001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 3439 Lines: 36 On Wed, 23 Feb 2005, David S. Miller wrote: > I don't think BIC has much to do with this problem. MacOS-X does delayed > ACKs until a PSH is seen and this kills performance if we don't PSH often > enough. I looked at the trace last night and I wonder if PSH is a red herring. For example: 16:42:21.837931 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 37545601 win 57184 16:42:21.837937 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37545601:37547049(1448) ack 122802 win 1460 NBT Packet 16:42:21.837940 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37547049:37548497(1448) ack 122802 win 1460 NBT Packet 16:42:21.837941 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37548497:37549945(1448) ack 122802 win 1460 NBT Packet 16:42:21.837943 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37549945:37551393(1448) ack 122802 win 1460 NBT Packet 16:42:21.837945 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37551393:37552841(1448) ack 122802 win 1460 NBT Packet 16:42:21.837947 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37552841:37554289(1448) ack 122802 win 1460 NBT Packet 16:42:21.837949 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37554289:37555737(1448) ack 122802 win 1460 NBT Packet 16:42:21.838979 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 37552841 win 65535 16:42:21.838985 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37555737:37557185(1448) ack 122802 win 1460 NBT Packet 16:42:21.838987 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37557185:37558633(1448) ack 122802 win 1460 NBT Packet 16:42:21.838989 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37558633:37560081(1448) ack 122802 win 1460 NBT Packet 16:42:21.838991 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37560081:37561529(1448) ack 122802 win 1460 NBT Packet 16:42:21.838992 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37561529:37562977(1448) ack 122802 win 1460 NBT Packet 16:42:21.838994 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: . 37562977:37564425(1448) ack 122802 win 1460 NBT Packet 16:42:21.839172 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: P 122802:122853(51) ack 37554289 win 65128 NBT Packet 16:42:21.839178 IP 10.107.96.7.32801 > 10.107.96.230.netbios-ssn: P 37564425:37565873(1448) ack 122853 win 1460 NBT Packet 16:42:22.037976 IP 10.107.96.230.netbios-ssn > 10.107.96.7.32801: . ack 37565873 win 53548 Maybe this has something to do with the bi-directional nature of the flow? Mac OS delaying ACK to try to piggyback on data or something like that. One signature I noticed is that it seems the last packet sent by the Mac before the long delack timeout is always a small data packet. (I didn't rigorously verify this but it seems true.) -John From davem@davemloft.net Wed Feb 23 14:11:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 14:11:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NMBiUC016233 for ; Wed, 23 Feb 2005 14:11:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D44iG-0000AX-00; Wed, 23 Feb 2005 14:10:32 -0800 Date: Wed, 23 Feb 2005 14:10:32 -0800 From: "David S. Miller" To: John Heffner Cc: hubert.tonneau@fullpliant.org, netdev@oss.sgi.com Subject: Re: [RFT] BIC TCP delayed ack compensation Message-Id: <20050223141032.56793f88.davem@davemloft.net> In-Reply-To: References: <052Q0TU11@server5.heliogroup.fr> <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> <20050223112611.60561121.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1140 Lines: 24 On Wed, 23 Feb 2005 17:04:08 -0500 (EST) John Heffner wrote: > Maybe this has something to do with the bi-directional nature of the flow? > Mac OS delaying ACK to try to piggyback on data or something like that. > One signature I noticed is that it seems the last packet sent by the Mac > before the long delack timeout is always a small data packet. (I didn't > rigorously verify this but it seems true.) I should be more specific when I say "PSH". Mac OS-X's algorithm is basically that it always delays ACKs to the delayed ACK timeout when the header prediction fast path is hit. One way to "miss" the header prediction fast path is to set PSH (this is actually a bug, Linux fixed this long ago, PSH should be ignored for header prediction fast path checking). When the fast path is missed, it does the usual "every 2 full sized frames" ACK'ing. Out of order data can cause the missing of the fast path as well. That can only be determined if we had dumps from the Mac's perspective however. Anyways, this Mac OS-X behavior has pretty much been universally agreed to as a severe bug, at least on this list :-) From jheffner@psc.edu Wed Feb 23 14:19:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 14:19:26 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NMJKAR016986 for ; Wed, 23 Feb 2005 14:19:21 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id j1NMJ6Lu012602 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 17:19:06 -0500 (EST) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j1NMJ6Zj029339; Wed, 23 Feb 2005 17:19:06 -0500 Date: Wed, 23 Feb 2005 17:19:06 -0500 (EST) From: John Heffner To: "David S. Miller" cc: hubert.tonneau@fullpliant.org, netdev@oss.sgi.com Subject: Re: [RFT] BIC TCP delayed ack compensation In-Reply-To: <20050223141032.56793f88.davem@davemloft.net> Message-ID: References: <052Q0TU11@server5.heliogroup.fr> <200502231835.j1NIZX2T020606@uni07mr.unity.ncsu.edu> <20050223112611.60561121.davem@davemloft.net> <20050223141032.56793f88.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 2003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1105 Lines: 26 On Wed, 23 Feb 2005, David S. Miller wrote: > On Wed, 23 Feb 2005 17:04:08 -0500 (EST) > John Heffner wrote: > > > Maybe this has something to do with the bi-directional nature of the flow? > > Mac OS delaying ACK to try to piggyback on data or something like that. > > One signature I noticed is that it seems the last packet sent by the Mac > > before the long delack timeout is always a small data packet. (I didn't > > rigorously verify this but it seems true.) > > I should be more specific when I say "PSH". Mac OS-X's algorithm is basically > that it always delays ACKs to the delayed ACK timeout when the header prediction > fast path is hit. One way to "miss" the header prediction fast path is to > set PSH (this is actually a bug, Linux fixed this long ago, PSH should be ignored > for header prediction fast path checking). The point is it appears to be delaying ack even when PSH is set. > Anyways, this Mac OS-X behavior has pretty much been universally agreed > to as a severe bug, at least on this list :-) Yep. The Mac behavior is clearly bizarre. :) -John From hubert.tonneau@fullpliant.org Wed Feb 23 14:22:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 14:22:58 -0800 (PST) Received: from server5.heliogroup.fr (eurogra4543-2.clients.easynet.fr [212.180.52.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NMMkoB017553 for ; Wed, 23 Feb 2005 14:22:48 -0800 From: Hubert Tonneau To: Stephen Hemminger , "Injong Rhee" Cc: "'cliff white'" , "'Alexey Kuznetsov'" , , "'David S. Miller'" Subject: Re: [RFT] BIC TCP delayed ack compensation Date: Wed, 23 Feb 2005 21:54:47 GMT Message-ID: <052RU7B12@server5.heliogroup.fr> X-Mailer: Pliant 93 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hubert.tonneau@fullpliant.org Precedence: bulk X-list: netdev Content-Length: 554 Lines: 24 Stephen Hemminger wrote: > > An interesting test would be to repeat the slow case: 2.6.10-ac11 over 100Mbps > > With first TCP Reno (old default). > sysctl -w net.ipv4.tcp_bic=0 No change. > then TCP Westwood. > sysctl -w net.ipv4.tcp_bic=0 > sysctl -w net.ipv4.tcp_westwood=1 No change. Now Linux 2.6.11-rc4 with Injong Rhee abc patch: No change. Looks like David S. Miller is right. Now, what I still don't understand is, if it's PSH/ACK related, why does the gigabit connected Mac works nicely whereas the 100 Mbps connected one does not ? From herbert@gondor.apana.org.au Wed Feb 23 14:50:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 14:50:07 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NMnwOR019264 for ; Wed, 23 Feb 2005 14:49:59 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D45Jk-00089s-00; Thu, 24 Feb 2005 09:49:16 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D45Ix-0001vv-00; Thu, 24 Feb 2005 09:48:27 +1100 Date: Thu, 24 Feb 2005 09:48:27 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: Frequent Oops on Shutdown 2.6.10 Message-ID: <20050223224827.GA7418@gondor.apana.org.au> References: <20050222101526.GA5814@gondor.apana.org.au> <20050223.183555.80618945.yoshfuji@linux-ipv6.org> <20050223095144.GB16820@gondor.apana.org.au> <20050224.014148.47626020.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224.014148.47626020.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 476 Lines: 16 On Thu, Feb 24, 2005 at 01:41:48AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Here's the (hopefuly) final one. Looks good to me. > Signed-off-by: Hideaki YOSHIFUJI Signed-off-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jgarzik@pobox.com Wed Feb 23 15:39:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 15:39:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NNdQkK000918 for ; Wed, 23 Feb 2005 15:39:27 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D466G-0000qR-Di; Wed, 23 Feb 2005 23:39:25 +0000 Message-ID: <421D141C.4030602@pobox.com> Date: Wed, 23 Feb 2005 18:39:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Francois Romieu , Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x r8169 update Content-Type: multipart/mixed; boundary="------------090502080105020908050300" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2006 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: 18948 Lines: 723 This is a multi-part message in MIME format. --------------090502080105020908050300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Any chance to convince the alien who took control of Jeff's libata queue to > push: > > r8169: synchronization and balancing when the device is closed > > (1.1982.1.58 ?) > > Test case on current 2.6.11-rc4: > - ifconfig ethX 10.0.0.1 up > - ifconfig ethX down > - ifconfig ethX 10.0.0.1 up > -> Rx does not work any more > - ifconfig ethX down > -> command hangs Agree it needs fixing, but I actually think the rx-offset stuff is more urgent than this. For the future, it would be useful for both of us to have separate r8169-fixes and r8169-cleanups queues. Anyway, here it is: [see attached] --------------090502080105020908050300 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/r8169.c | 218 ++++++++++++++++++++++++++++++++-------------------- 1 files changed, 138 insertions(+), 80 deletions(-) through these ChangeSets: François Romieu: o r8169: factor out some code o r8169: IRQ races during change of mtu o r8169: uniformize comments o r8169: removal of unused #define o r8169: skb alignment nitpicking o r8169: fix rx skb allocation error logging o r8169: synchronization and balancing when the device is closed o r8169: screaming irq when the device is closed o r8169: typo in debugging code o r8169: merge of Realtek's code o r8169: endianness fixes --------------090502080105020908050300 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-02-23 18:33:11 -05:00 +++ b/drivers/net/r8169.c 2005-02-23 18:33:11 -05:00 @@ -41,7 +41,14 @@ - Suspend/resume - Endianness - Misc Rx/Tx bugs -*/ + +VERSION 2.2LK <2005/01/25> + + - RX csum, TX csum/SG, TSO + - VLAN + - baby (< 7200) Jumbo frames support + - Merge of Realtek's version 2.2 (new phy) + */ #include #include @@ -62,7 +69,7 @@ #include #include -#define RTL8169_VERSION "1.6LK" +#define RTL8169_VERSION "2.2LK" #define MODULENAME "r8169" #define PFX MODULENAME ": " @@ -72,7 +79,7 @@ printk( "Assertion failed! %s,%s,%s,line=%d\n", \ #expr,__FILE__,__FUNCTION__,__LINE__); \ } -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args) } while (0) +#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0) #else #define assert(expr) do {} while (0) #define dprintk(fmt, args...) do {} while (0) @@ -100,15 +107,13 @@ static int max_interrupt_work = 20; /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast). - The RTL chips use a 64 element hash table based on the Ethernet CRC. */ + The RTL chips use a 64 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 32; -/* MAC address length*/ +/* MAC address length */ #define MAC_ADDR_LEN 6 -#define TX_FIFO_THRESH 256 /* In bytes */ - -#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ +#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ @@ -149,6 +154,7 @@ RTL_GIGA_PHY_VER_E = 0x05, /* PHY Reg 0x03 bit0-3 == 0x0000 */ RTL_GIGA_PHY_VER_F = 0x06, /* PHY Reg 0x03 bit0-3 == 0x0001 */ RTL_GIGA_PHY_VER_G = 0x07, /* PHY Reg 0x03 bit0-3 == 0x0002 */ + RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */ }; @@ -162,7 +168,8 @@ } rtl_chip_info[] = { _R("RTL8169", RTL_GIGA_MAC_VER_B, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_D, 0xff7e1880), - _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880) + _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880), + _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_X, 0xff7e1880), }; #undef _R @@ -208,6 +215,7 @@ PHYstatus = 0x6C, RxMaxSize = 0xDA, CPlusCmd = 0xE0, + IntrMitigate = 0xE2, RxDescAddrLow = 0xE4, RxDescAddrHigh = 0xE8, EarlyTxThres = 0xEC, @@ -218,7 +226,7 @@ }; enum RTL8169_register_content { - /*InterruptStatusBits */ + /* InterruptStatusBits */ SYSErr = 0x8000, PCSTimeout = 0x4000, SWInt = 0x0100, @@ -231,23 +239,23 @@ RxErr = 0x02, RxOK = 0x01, - /*RxStatusDesc */ + /* RxStatusDesc */ RxRES = 0x00200000, RxCRC = 0x00080000, RxRUNT = 0x00100000, RxRWT = 0x00400000, - /*ChipCmdBits */ + /* ChipCmdBits */ CmdReset = 0x10, CmdRxEnb = 0x08, CmdTxEnb = 0x04, RxBufEmpty = 0x01, - /*Cfg9346Bits */ + /* Cfg9346Bits */ Cfg9346_Lock = 0x00, Cfg9346_Unlock = 0xC0, - /*rx_mode_bits */ + /* rx_mode_bits */ AcceptErr = 0x20, AcceptRunt = 0x10, AcceptBroadcast = 0x08, @@ -255,11 +263,11 @@ AcceptMyPhys = 0x02, AcceptAllPhys = 0x01, - /*RxConfigBits */ + /* RxConfigBits */ RxCfgFIFOShift = 13, RxCfgDMAShift = 8, - /*TxConfigBits */ + /* TxConfigBits */ TxInterFrameGapShift = 24, TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ @@ -277,7 +285,7 @@ PCIDAC = (1 << 4), PCIMulRW = (1 << 3), - /*rtl8169_PHYstatus */ + /* rtl8169_PHYstatus */ TBI_Enable = 0x80, TxFlowCtrl = 0x40, RxFlowCtrl = 0x20, @@ -287,38 +295,38 @@ LinkStatus = 0x02, FullDup = 0x01, - /*GIGABIT_PHY_registers */ + /* GIGABIT_PHY_registers */ PHY_CTRL_REG = 0, PHY_STAT_REG = 1, PHY_AUTO_NEGO_REG = 4, PHY_1000_CTRL_REG = 9, - /*GIGABIT_PHY_REG_BIT */ + /* GIGABIT_PHY_REG_BIT */ PHY_Restart_Auto_Nego = 0x0200, PHY_Enable_Auto_Nego = 0x1000, - //PHY_STAT_REG = 1; + /* PHY_STAT_REG = 1 */ PHY_Auto_Neco_Comp = 0x0020, - //PHY_AUTO_NEGO_REG = 4; + /* PHY_AUTO_NEGO_REG = 4 */ PHY_Cap_10_Half = 0x0020, PHY_Cap_10_Full = 0x0040, PHY_Cap_100_Half = 0x0080, PHY_Cap_100_Full = 0x0100, - //PHY_1000_CTRL_REG = 9; + /* PHY_1000_CTRL_REG = 9 */ PHY_Cap_1000_Full = 0x0200, PHY_Cap_Null = 0x0, - /*_MediaType*/ + /* _MediaType */ _10_Half = 0x01, _10_Full = 0x02, _100_Half = 0x04, _100_Full = 0x08, _1000_Full = 0x10, - /*_TBICSRBit*/ + /* _TBICSRBit */ TBILinkOK = 0x02000000, }; @@ -374,7 +382,7 @@ struct rtl8169_private { void __iomem *mmio_addr; /* memory map physical address */ - struct pci_dev *pci_dev; /* Index of PCI device */ + struct pci_dev *pci_dev; /* Index of PCI device */ struct net_device_stats stats; /* statistics of net device */ spinlock_t lock; /* spin lock flag */ int chipset; @@ -407,7 +415,7 @@ struct work_struct task; }; -MODULE_AUTHOR("Realtek"); +MODULE_AUTHOR("Realtek and the Linux r8169 crew "); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); module_param_array(media, int, &num_media, 0); module_param(rx_copybreak, int, 0); @@ -455,7 +463,7 @@ udelay(1000); for (i = 2000; i > 0; i--) { - // Check if the RTL8169 has completed writing to the specified MII register + /* Check if the RTL8169 has completed writing to the specified MII register */ if (!(RTL_R32(PHYAR) & 0x80000000)) break; udelay(100); @@ -470,7 +478,7 @@ udelay(1000); for (i = 2000; i > 0; i--) { - // Check if the RTL8169 has completed retrieving data from the specified MII register + /* Check if the RTL8169 has completed retrieving data from the specified MII register */ if (RTL_R32(PHYAR) & 0x80000000) { value = (int) (RTL_R32(PHYAR) & 0xFFFF); break; @@ -480,6 +488,20 @@ return value; } +static void rtl8169_irq_mask_and_ack(void __iomem *ioaddr) +{ + RTL_W16(IntrMask, 0x0000); + + RTL_W16(IntrStatus, 0xffff); +} + +static void rtl8169_asic_down(void __iomem *ioaddr) +{ + RTL_W8(ChipCmd, 0x00); + rtl8169_irq_mask_and_ack(ioaddr); + RTL_R16(CPlusCmd); +} + static unsigned int rtl8169_tbi_reset_pending(void __iomem *ioaddr) { return RTL_R32(TBICSR) & TBIReset; @@ -698,7 +720,7 @@ struct sk_buff *skb) { return (tp->vlgrp && vlan_tx_tag_present(skb)) ? - TxVlanTag | cpu_to_be16(vlan_tx_tag_get(skb)) : 0x00; + TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00; } static void rtl8169_vlan_rx_register(struct net_device *dev, @@ -733,12 +755,12 @@ static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc, struct sk_buff *skb) { - u32 opts2 = desc->opts2; + u32 opts2 = le32_to_cpu(desc->opts2); int ret; if (tp->vlgrp && (opts2 & RxVlanTag)) { rtl8169_rx_hwaccel_skb(skb, tp->vlgrp, - be16_to_cpu(opts2 & 0xffff)); + swab16(opts2 & 0xffff)); ret = 0; } else ret = -1; @@ -1002,7 +1024,7 @@ if (tp->mac_version <= RTL_GIGA_MAC_VER_B) return; - if (tp->phy_version >= RTL_GIGA_PHY_VER_F) + if (tp->phy_version >= RTL_GIGA_PHY_VER_H) return; dprintk("MAC version != 0 && PHY version == 0 or 1\n"); @@ -1010,7 +1032,19 @@ /* Shazam ! */ - // phy config for RTL8169s mac_version C chip + if (tp->mac_version == RTL_GIGA_MAC_VER_X) { + mdio_write(ioaddr, 31, 0x0001); + mdio_write(ioaddr, 9, 0x273a); + mdio_write(ioaddr, 14, 0x7bfb); + mdio_write(ioaddr, 27, 0x841e); + + mdio_write(ioaddr, 31, 0x0002); + mdio_write(ioaddr, 1, 0x90d0); + mdio_write(ioaddr, 31, 0x0000); + return; + } + + /* phy config for RTL8169s mac_version C chip */ mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1 mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000 mdio_write(ioaddr, 24, 0x65c7); //w 24 15 0 65c7 @@ -1038,7 +1072,7 @@ unsigned long timeout = RTL8169_PHY_TIMEOUT; assert(tp->mac_version > RTL_GIGA_MAC_VER_B); - assert(tp->phy_version < RTL_GIGA_PHY_VER_G); + assert(tp->phy_version < RTL_GIGA_PHY_VER_H); if (!(tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) return; @@ -1073,7 +1107,7 @@ struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) + (tp->phy_version >= RTL_GIGA_PHY_VER_H)) return; del_timer_sync(timer); @@ -1085,7 +1119,7 @@ struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) + (tp->phy_version >= RTL_GIGA_PHY_VER_H)) return; init_timer(timer); @@ -1132,7 +1166,7 @@ assert(ioaddr_out != NULL); - // dev zeroed in alloc_etherdev + /* dev zeroed in alloc_etherdev */ dev = alloc_etherdev(sizeof (*tp)); if (dev == NULL) { printk(KERN_ERR PFX "unable to alloc new ethernet\n"); @@ -1143,7 +1177,7 @@ SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); - // enable device (incl. PCI PM wakeup and hotplug setup) + /* enable device (incl. PCI PM wakeup and hotplug setup) */ rc = pci_enable_device(pdev); if (rc) { printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); @@ -1167,14 +1201,14 @@ goto err_out_mwi; } - // make sure PCI base addr 1 is MMIO + /* make sure PCI base addr 1 is MMIO */ if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) { printk(KERN_ERR PFX "region #1 not an MMIO resource, aborting\n"); rc = -ENODEV; goto err_out_mwi; } - // check for weird/broken PCI region reporting + /* check for weird/broken PCI region reporting */ if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) { printk(KERN_ERR PFX "Invalid PCI region size(s), aborting\n"); rc = -ENODEV; @@ -1204,7 +1238,7 @@ pci_set_master(pdev); - // ioremap MMIO region + /* ioremap MMIO region */ ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE); if (ioaddr == NULL) { printk(KERN_ERR PFX "cannot remap MMIO, aborting\n"); @@ -1212,17 +1246,20 @@ goto err_out_free_res; } - // Soft reset the chip. + /* Unneeded ? Don't mess with Mrs. Murphy. */ + rtl8169_irq_mask_and_ack(ioaddr); + + /* Soft reset the chip. */ RTL_W8(ChipCmd, CmdReset); - // Check that the chip has finished the reset. + /* Check that the chip has finished the reset. */ for (i = 1000; i > 0; i--) { if ((RTL_R8(ChipCmd) & CmdReset) == 0) break; udelay(10); } - // Identify chip attached to board + /* Identify chip attached to board */ rtl8169_get_mac_version(tp, ioaddr); rtl8169_get_phy_version(tp, ioaddr); @@ -1310,7 +1347,7 @@ tp->link_ok = rtl8169_xmii_link_ok; } - // Get MAC address. FIXME: read EEPROM + /* Get MAC address. FIXME: read EEPROM */ for (i = 0; i < MAC_ADDR_LEN; i++) dev->dev_addr[i] = RTL_R8(MAC0 + i); @@ -1518,7 +1555,7 @@ static void rtl8169_hw_reset(void __iomem *ioaddr) { /* Disable interrupts */ - RTL_W16(IntrMask, 0x0000); + rtl8169_irq_mask_and_ack(ioaddr); /* Reset the chipset */ RTL_W8(ChipCmd, CmdReset); @@ -1548,10 +1585,10 @@ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); - // For gigabit rtl8169, MTU + header + CRC + VLAN + /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); - // Set Rx Config register + /* Set Rx Config register */ i = rtl8169_rx_config | (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); RTL_W32(RxConfig, i); @@ -1563,13 +1600,20 @@ tp->cp_cmd |= RTL_R16(CPlusCmd); RTL_W16(CPlusCmd, tp->cp_cmd); - if (tp->mac_version == RTL_GIGA_MAC_VER_D) { + if ((tp->mac_version == RTL_GIGA_MAC_VER_D) || + (tp->mac_version == RTL_GIGA_MAC_VER_E)) { dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " "Bit-3 and bit-14 MUST be 1\n"); tp->cp_cmd |= (1 << 14) | PCIMulRW; RTL_W16(CPlusCmd, tp->cp_cmd); } + /* + * Undocumented corner. Supposedly: + * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets + */ + RTL_W16(IntrMitigate, 0x0000); + 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)); @@ -1611,10 +1655,10 @@ if (ret < 0) goto out; - rtl8169_hw_start(dev); - netif_poll_enable(dev); + rtl8169_hw_start(dev); + rtl8169_request_timer(dev); out: @@ -1658,11 +1702,11 @@ dma_addr_t mapping; int ret = 0; - skb = dev_alloc_skb(rx_buf_sz); + skb = dev_alloc_skb(rx_buf_sz + NET_IP_ALIGN); if (!skb) goto err_out; - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); *sk_buff = skb; mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, @@ -1795,9 +1839,7 @@ /* Wait for any pending NAPI task to complete */ netif_poll_disable(dev); - RTL_W16(IntrMask, 0x0000); - - RTL_W16(IntrStatus, 0xffff); + rtl8169_irq_mask_and_ack(ioaddr); netif_poll_enable(dev); } @@ -1974,7 +2016,7 @@ smp_wmb(); - RTL_W8(TxPoll, 0x40); //set polling bit + RTL_W8(TxPoll, 0x40); /* set polling bit */ if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) { netif_stop_queue(dev); @@ -2084,7 +2126,7 @@ static inline void rtl8169_rx_csum(struct sk_buff *skb, struct RxDesc *desc) { - u32 opts1 = desc->opts1; + u32 opts1 = le32_to_cpu(desc->opts1); u32 status = opts1 & RxProtoMask; if (((status == RxProtoTCP) && !(opts1 & TCPFail)) || @@ -2103,9 +2145,9 @@ if (pkt_size < rx_copybreak) { struct sk_buff *skb; - skb = dev_alloc_skb(pkt_size + 2); + skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN); if (skb) { - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); *sk_buff = skb; rtl8169_return_to_asic(desc, rx_buf_sz); @@ -2119,8 +2161,8 @@ rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void __iomem *ioaddr) { - unsigned int cur_rx, rx_left, count; - int delta; + unsigned int cur_rx, rx_left; + unsigned int delta, count; assert(dev != NULL); assert(tp != NULL); @@ -2188,10 +2230,8 @@ tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta < 0) { + if (!delta && count) printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); - delta = 0; - } tp->dirty_rx += delta; /* @@ -2215,12 +2255,9 @@ struct rtl8169_private *tp = netdev_priv(dev); int boguscnt = max_interrupt_work; void __iomem *ioaddr = tp->mmio_addr; - int status = 0; + int status; int handled = 0; - if (unlikely(!netif_running(dev))) - goto out; - do { status = RTL_R16(IntrStatus); @@ -2230,6 +2267,11 @@ handled = 1; + if (unlikely(!netif_running(dev))) { + rtl8169_asic_down(ioaddr); + goto out; + } + status &= tp->intr_mask; RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); @@ -2257,11 +2299,11 @@ } break; #else - // Rx interrupt + /* Rx interrupt */ if (status & (RxOK | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } - // Tx interrupt + /* Tx interrupt */ if (status & (TxOK | TxErr)) rtl8169_tx_interrupt(dev, tp, ioaddr); #endif @@ -2292,7 +2334,7 @@ *budget -= work_done; dev->quota -= work_done; - if ((work_done < work_to_do) || !netif_running(dev)) { + if (work_done < work_to_do) { netif_rx_complete(dev); tp->intr_mask = 0xffff; /* @@ -2313,6 +2355,7 @@ { struct rtl8169_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->mmio_addr; + unsigned int poll_locked = 0; rtl8169_delete_timer(dev); @@ -2320,13 +2363,10 @@ flush_scheduled_work(); +core_down: spin_lock_irq(&tp->lock); - /* Stop the chip's Tx and Rx DMA processes. */ - RTL_W8(ChipCmd, 0x00); - - /* Disable interrupts by clearing the interrupt mask. */ - RTL_W16(IntrMask, 0x0000); + rtl8169_asic_down(ioaddr); /* Update the error counts. */ tp->stats.rx_missed_errors += RTL_R32(RxMissed); @@ -2336,11 +2376,27 @@ synchronize_irq(dev->irq); - netif_poll_disable(dev); + if (!poll_locked) { + netif_poll_disable(dev); + poll_locked++; + } /* Give a racing hard_start_xmit a few cycles to complete. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(1); + synchronize_kernel(); + + /* + * And now for the 50k$ question: are IRQ disabled or not ? + * + * Two paths lead here: + * 1) dev->close + * -> netif_running() is available to sync the current code and the + * IRQ handler. See rtl8169_interrupt for details. + * 2) dev->change_mtu + * -> rtl8169_poll can not be issued again and re-enable the + * interruptions. Let's simply issue the IRQ down sequence again. + */ + if (RTL_R16(IntrMask)) + goto core_down; rtl8169_tx_clear(tp); @@ -2355,6 +2411,8 @@ rtl8169_down(dev); free_irq(dev->irq, dev); + + netif_poll_enable(dev); pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, tp->RxPhyAddr); --------------090502080105020908050300-- From shemminger@osdl.org Wed Feb 23 16:23:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 16:23:37 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O0NU9O006597 for ; Wed, 23 Feb 2005 16:23:31 -0800 Received: from [192.168.0.106] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1O0N3qh023354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 23 Feb 2005 16:23:19 -0800 Message-ID: <421D1E66.5090301@osdl.org> Date: Wed, 23 Feb 2005 16:23:02 -0800 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Baruch Even , netdev@oss.sgi.com, linux-net@vger.kernel.org, yee-ting.li@nuim.ie, doug.leith@nuim.ie Subject: Re: [PATCH] select congestion control with one sysctl References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> In-Reply-To: <20050223135732.39e62c6c.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 556 Lines: 17 David S. Miller wrote: >For the millionth time, you can't just delete the existing sysctls. >That is a user visisble interface. > >Instead, you have to make them at least appear to select a >single congestion control algorithm as I stated in the >following posting: > >http://marc.theaimsgroup.com/?l=linux-kernel&m=110909973530321&w=2 > > I am heading in a different direction with making the TCP congestion protocols a real infrastructure. After the initial version gets done, then I will go back and add compatiablity interface hooks as required. From davem@davemloft.net Wed Feb 23 16:34:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 16:34:21 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O0YDhB007846 for ; Wed, 23 Feb 2005 16:34:16 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D46wC-0000vr-00; Wed, 23 Feb 2005 16:33:04 -0800 Date: Wed, 23 Feb 2005 16:33:04 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: baruch@ev-en.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, yee-ting.li@nuim.ie, doug.leith@nuim.ie Subject: Re: [PATCH] select congestion control with one sysctl Message-Id: <20050223163304.1afc24cf.davem@davemloft.net> In-Reply-To: <421D1E66.5090301@osdl.org> References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 371 Lines: 10 On Wed, 23 Feb 2005 16:23:02 -0800 Stephen Hemminger wrote: > I am heading in a different direction with making the TCP congestion > protocols > a real infrastructure. After the initial version gets done, then I will > go back > and add compatiablity interface hooks as required. Ok, if you want some patch review you know where to send it :-) From romieu@fr.zoreil.com Wed Feb 23 16:56:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 16:56:06 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O0txwq009253 for ; Wed, 23 Feb 2005 16:56:00 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1O0qis8003504; Thu, 24 Feb 2005 01:52:44 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1O0qdgj003503; Thu, 24 Feb 2005 01:52:39 +0100 Date: Thu, 24 Feb 2005 01:52:39 +0100 From: Francois Romieu To: Jeff Garzik Cc: Andrew Morton , Linus Torvalds , Netdev , Linux Kernel Subject: Re: [BK PATCHES] 2.6.x r8169 update Message-ID: <20050224005239.GA2599@electric-eye.fr.zoreil.com> References: <421D141C.4030602@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421D141C.4030602@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2009 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: 486 Lines: 14 Jeff Garzik : [...] > Agree it needs fixing, but I actually think the rx-offset stuff is more > urgent than this. For the future, it would be useful for both of us to > have separate r8169-fixes and r8169-cleanups queues. Do you have a synonym/pointer for the rx-offset stuff ? It will help me to rework the flow if you can describe in a few words what you expect wrt fixes/cleanups issue. Don't be shy, I won't use it as a contract set in stone :o) -- Ueimor From mlists@danielinux.net Wed Feb 23 17:06:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 17:06:23 -0800 (PST) Received: from ms001msg.fastwebnet.it (ms001msg.fastwebnet.it [213.140.2.51]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O16Fbq009994 for ; Wed, 23 Feb 2005 17:06:16 -0800 Received: from [192.168.1.66] (37.10.150.65) by ms001msg.fastwebnet.it (7.2.052.3) id 41FFB4A20058A77F; Thu, 24 Feb 2005 02:05:24 +0100 From: Daniele Lacamera Reply-To: mlists@danielinux.net To: "David S. Miller" Subject: Re: [PATCH] select congestion control with one sysctl Date: Thu, 24 Feb 2005 02:05:22 +0100 User-Agent: KMail/1.7.1 Cc: Baruch Even , shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, yee-ting.li@nuim.ie, doug.leith@nuim.ie References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> In-Reply-To: <20050223135732.39e62c6c.davem@davemloft.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ShSHCpsn9pKjOO8" Message-Id: <200502240205.22972.mlists@danielinux.net> X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlists@danielinux.net Precedence: bulk X-list: netdev Content-Length: 15960 Lines: 519 --Boundary-00=_ShSHCpsn9pKjOO8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 23 February 2005 22:57, David S. Miller wrote: > > For the millionth time, you can't just delete the existing sysctls. > That is a user visisble interface. > > Instead, you have to make them at least appear to select a > single congestion control algorithm [..] Maybe this could be a starting point. This version of hybla patch makes our sysctls mutually exclusive by switching all off just before performing a "write" operation on one of them. However, there should be more than one cleaner way to do it ... -- Daniele Lacamera root at danielinux.net --Boundary-00=_ShSHCpsn9pKjOO8 Content-Type: text/x-diff; charset="iso-8859-1"; name="tcp_hybla_exclusive-sysctl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_hybla_exclusive-sysctl.patch" diff -ruN linux-2.6.11-rc4/Documentation/networking/ip-sysctl.txt hybla-2.6.11-rc4/Documentation/networking/ip-sysctl.txt --- linux-2.6.11-rc4/Documentation/networking/ip-sysctl.txt 2005-02-13 04:06:20.000000000 +0100 +++ hybla-2.6.11-rc4/Documentation/networking/ip-sysctl.txt 2005-02-22 13:50:38.000000000 +0100 @@ -349,6 +349,18 @@ window. Allows two flows sharing the same connection to converge more rapidly. Default: 1 + +tcp_hybla - BOOLEAN + Enable TCP-Hybla congestion control algorithm. + TCP-Hybla is a sender-side only change that eliminates penalization of + long-RTT, large-bandwidth connections, like when satellite legs are + involved, expecially when sharing a common bottleneck with normal + terrestrial connections. + Default: 0 + +tcp_hybla_rtt0 - INTEGER + Divisor to set up rtt0 value for hybla congestion control. + Default: 40 (= 1/40 sec == 25ms) tcp_default_win_scale - INTEGER Sets the minimum window scale TCP will negotiate for on all diff -ruN linux-2.6.11-rc4/include/linux/sysctl.h hybla-2.6.11-rc4/include/linux/sysctl.h --- linux-2.6.11-rc4/include/linux/sysctl.h 2005-02-13 04:06:53.000000000 +0100 +++ hybla-2.6.11-rc4/include/linux/sysctl.h 2005-02-24 01:41:45.000000000 +0100 @@ -344,6 +344,8 @@ NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, + NET_TCP_HYBLA=108, + NET_TCP_HYBLA_RTT0=109, }; enum { @@ -788,6 +790,8 @@ void __user *, size_t *, loff_t *); extern int proc_dointvec(ctl_table *, int, struct file *, void __user *, size_t *, loff_t *); +extern int proc_switch_congctl(ctl_table *, int, struct file *, + void __user *, size_t *, loff_t *); extern int proc_dointvec_bset(ctl_table *, int, struct file *, void __user *, size_t *, loff_t *); extern int proc_dointvec_minmax(ctl_table *, int, struct file *, diff -ruN linux-2.6.11-rc4/include/linux/tcp.h hybla-2.6.11-rc4/include/linux/tcp.h --- linux-2.6.11-rc4/include/linux/tcp.h 2005-02-13 04:06:23.000000000 +0100 +++ hybla-2.6.11-rc4/include/linux/tcp.h 2005-02-22 13:04:53.000000000 +0100 @@ -434,6 +434,16 @@ __u32 last_cwnd; /* the last snd_cwnd */ __u32 last_stamp; /* time when updated last_cwnd */ } bictcp; + + /* Tcp Hybla structure. */ + struct{ + __u32 snd_cwnd_cents; /* Keeps increment values when it is <1, <<7 */ + __u32 rho; /* Rho parameter, integer part */ + __u32 rho2; /* Rho * Rho, integer part */ + __u32 rho_3ls; /* Rho parameter, <<3 */ + __u32 rho2_7ls; /* Rho^2, <<7 */ + __u32 minrtt; /* Minimum smoothed round trip time value seen */ + } hybla; }; static inline struct tcp_sock *tcp_sk(const struct sock *sk) diff -ruN linux-2.6.11-rc4/include/net/tcp.h hybla-2.6.11-rc4/include/net/tcp.h --- linux-2.6.11-rc4/include/net/tcp.h 2005-02-13 04:05:28.000000000 +0100 +++ hybla-2.6.11-rc4/include/net/tcp.h 2005-02-22 16:30:05.000000000 +0100 @@ -608,6 +608,8 @@ extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; +extern int sysctl_tcp_hybla; +extern int sysctl_tcp_hybla_rtt0; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; @@ -2017,4 +2019,37 @@ return (cwnd != 0); } + +/* + * TCP HYBLA Functions and constants + */ +/* Hybla reference round trip time (default= 1/40 sec = 25 ms), expressed in jiffies */ +#define RTT0 (__u32) ((HZ/sysctl_tcp_hybla_rtt0)) +/* + * This is called in tcp_ipv4.c and + * tcp_minisocks.c when connection starts + */ +static inline void init_hybla(struct tcp_sock *tp) +{ + tp->hybla.rho = 0; + tp->hybla.rho2 = 0; + tp->hybla.rho_3ls = 0; + tp->hybla.rho2_7ls = 0; + tp->hybla.snd_cwnd_cents = 0; +} +/* This is called to refresh values for hybla parameters */ +static inline void hybla_recalc_param (struct tcp_sock *tp) +{ + + tp->hybla.rho_3ls = (tp->srtt / RTT0); + if(tp->hybla.rho_3ls < 8) + tp->hybla.rho_3ls =8; + + tp->hybla.rho=(tp->hybla.rho_3ls >> 3); + tp->hybla.rho2_7ls = ((tp->hybla.rho_3ls * tp->hybla.rho_3ls)<<1); + tp->hybla.rho2=(tp->hybla.rho2_7ls >>7); + + if (sysctl_tcp_hybla) + tp->snd_cwnd_clamp = min_t (__u32, tp->snd_cwnd_clamp, tp->hybla.rho<<16); +} #endif /* _TCP_H */ diff -ruN linux-2.6.11-rc4/kernel/sysctl.c hybla-2.6.11-rc4/kernel/sysctl.c --- linux-2.6.11-rc4/kernel/sysctl.c 2005-02-13 04:05:27.000000000 +0100 +++ hybla-2.6.11-rc4/kernel/sysctl.c 2005-02-24 01:41:16.000000000 +0100 @@ -66,6 +66,11 @@ extern int printk_ratelimit_burst; extern int pid_max_min, pid_max_max; +extern int sysctl_tcp_vegas_cong_avoid; +extern int sysctl_tcp_bic; +extern int sysctl_tcp_westwood; +extern int sysctl_tcp_hybla; + #if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86) int unknown_nmi_panic; extern int proc_unknown_nmi_panic(ctl_table *, int, struct file *, @@ -1595,6 +1600,23 @@ NULL,NULL); } +/** + * Used by tcp engine to realize a multi-switch for congestion + * control algorithm selection. + */ +int proc_switch_congctl(ctl_table *table, int write, struct file *filp, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + if(write){ + sysctl_tcp_vegas_cong_avoid=0; + sysctl_tcp_westwood=0; + sysctl_tcp_bic=0; + sysctl_tcp_hybla=0; + } + return do_proc_dointvec(table,write,filp,buffer,lenp,ppos, + NULL,NULL); +} + #define OP_SET 0 #define OP_AND 1 #define OP_OR 2 @@ -2216,6 +2238,7 @@ * exception granted :-) */ EXPORT_SYMBOL(proc_dointvec); +EXPORT_SYMBOL(proc_switch_congctl); EXPORT_SYMBOL(proc_dointvec_jiffies); EXPORT_SYMBOL(proc_dointvec_minmax); EXPORT_SYMBOL(proc_dointvec_userhz_jiffies); diff -ruN linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c hybla-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c --- linux-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c 2005-02-13 04:07:01.000000000 +0100 +++ hybla-2.6.11-rc4/net/ipv4/sysctl_net_ipv4.c 2005-02-24 01:40:49.000000000 +0100 @@ -608,7 +608,7 @@ .data = &sysctl_tcp_westwood, .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_switch_congctl, }, { .ctl_name = NET_TCP_VEGAS, @@ -616,7 +616,7 @@ .data = &sysctl_tcp_vegas_cong_avoid, .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_switch_congctl, }, { .ctl_name = NET_TCP_VEGAS_ALPHA, @@ -648,7 +648,7 @@ .data = &sysctl_tcp_bic, .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_switch_congctl, }, { .ctl_name = NET_TCP_BIC_FAST_CONVERGENCE, @@ -682,6 +682,22 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_HYBLA, + .procname = "tcp_hybla", + .data = &sysctl_tcp_hybla, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_switch_congctl, + }, + { + .ctl_name = NET_TCP_HYBLA_RTT0, + .procname = "tcp_hybla_rtt0", + .data = &sysctl_tcp_hybla_rtt0, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -ruN linux-2.6.11-rc4/net/ipv4/tcp.c hybla-2.6.11-rc4/net/ipv4/tcp.c --- linux-2.6.11-rc4/net/ipv4/tcp.c 2005-02-13 04:05:50.000000000 +0100 +++ hybla-2.6.11-rc4/net/ipv4/tcp.c 2005-02-22 16:30:41.000000000 +0100 @@ -1813,6 +1813,10 @@ if (!(sk->sk_userlocks & SOCK_BINDADDR_LOCK)) inet_reset_saddr(sk); + + /* [TCP HYBLA] Reset values on disconnect */ + if (sysctl_tcp_hybla) + init_hybla(tp); sk->sk_shutdown = 0; sock_reset_flag(sk, SOCK_DONE); diff -ruN linux-2.6.11-rc4/net/ipv4/tcp_input.c hybla-2.6.11-rc4/net/ipv4/tcp_input.c --- linux-2.6.11-rc4/net/ipv4/tcp_input.c 2005-02-13 04:07:01.000000000 +0100 +++ hybla-2.6.11-rc4/net/ipv4/tcp_input.c 2005-02-22 13:58:49.000000000 +0100 @@ -62,6 +62,7 @@ * engine. Lots of bugs are found. * Pasi Sarolahti: F-RTO for dealing with spurious RTOs * Angelo Dell'Aera: TCP Westwood+ support + * Daniele Lacamera: TCP Hybla Congestion control support */ #include @@ -89,6 +90,8 @@ int sysctl_tcp_nometrics_save; int sysctl_tcp_westwood; int sysctl_tcp_vegas_cong_avoid; +int sysctl_tcp_hybla=0; +int sysctl_tcp_hybla_rtt0=40; int sysctl_tcp_moderate_rcvbuf = 1; @@ -595,6 +598,29 @@ tp->vegas.cntRTT++; } +/* + * [TCP HYBLA] Update Values, if necessary, when a new + * smoothed RTT Estimation becomes available + */ +static void hybla_update_rtt(struct tcp_sock *tp, long m) +{ + /* This sets rho to the smallest RTT received. */ + if (tp->srtt!=0){ + /* Recalculate rho only if this srtt is the lowest */ + if (tp->srtt < tp->hybla.minrtt){ + hybla_recalc_param(tp); + /* update minimum rtt */ + tp->hybla.minrtt = tp->srtt; + } + } else { + /* 1st Rho measurement */ + hybla_recalc_param(tp); + /* set minimum rtt as this is the 1st ever seen */ + tp->hybla.minrtt = tp->srtt; + tp->snd_cwnd=tp->hybla.rho; + } +} + /* Called to compute a smoothed rtt estimate. The data fed to this * routine either comes from timestamps, or from segments that were * known _not_ to have been retransmitted [see Karn/Partridge @@ -669,6 +695,8 @@ } tcp_westwood_update_rtt(tp, tp->srtt >> 3); + if(sysctl_tcp_hybla) + hybla_update_rtt(tp,mrtt); } /* Calculate rto without backoff. This is the second half of Van Jacobson's @@ -808,6 +836,11 @@ else cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; } + /* Hybla initial Window value set. */ + if (sysctl_tcp_hybla){ + hybla_recalc_param(tp); + cwnd=max_t(__u32, 2U, tp->hybla.rho); + } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ -2322,12 +2355,153 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } +/*** + ** TCP-HYBLA Congestion control algorithm, based on: + ** C.Caini, R.Firrincieli, "TCP-Hybla: A TCP Enhancement + ** for Heterogeneous Networks", + ** International Journal on satellite Communications, + ** September 2004 + ***/ +static __inline__ __u32 hybla_slowstart_fraction_increment(__u32 odds){ + switch (odds) { + case 0: + return 128; + case 1: + return 139; + case 2: + return 152; + case 3: + return 165; + case 4: + return 181; + case 5: + return 197; + case 6: + return 215; + case 7: + return 234; + default: + return 128; + + } +} +static __inline__ void hybla_fractions_cong_avoid(struct tcp_sock *tp) +{ + __u32 increment; + __u32 odd; + __u32 rho_fractions; + //__u8 is_slowstart=0; + __u32 window, ssthresh; + + if (tp->hybla.rho==0) + hybla_recalc_param(tp); + + ssthresh = tp->snd_ssthresh; + window=tp->snd_cwnd; + rho_fractions=tp->hybla.rho_3ls - (tp->hybla.rho << 3); + + if (window < ssthresh){ + return; + } else { + /*** congestion avoidance + *** INC = RHO^2 / W + *** as long as increment is estimated as (rho<<7)/window + *** it already is <<7 and we can easily count its fractions. + ***/ + increment =(tp->hybla.rho2_7ls/window); + odd = increment % 128; + tp->snd_cwnd_cnt++; + } + tp->hybla.snd_cwnd_cents += odd; + +} + + /* TCP Hybla main routine. + * This is the algorithm behavior: + * o Recalc Hybla parameters if min_rtt has changed + * o Give cwnd a new value based on the model proposed + * o remember increments <1 + */ +static __inline__ void tcp_hybla_cong_avoid(struct tcp_sock *tp) +{ + __u32 increment; + __u32 odd; + __u32 rho_fractions; + __u32 window,clamp, ssthresh; + __u8 is_slowstart=0; + + if (tp->hybla.rho==0) + hybla_recalc_param(tp); + + clamp = tp->snd_cwnd_clamp ; + window = tp->snd_cwnd; + ssthresh = tp->snd_ssthresh; + rho_fractions=tp->hybla.rho_3ls - (tp->hybla.rho << 3); + + if (window < ssthresh){ + /*** slow start + *** INC = 2^RHO - 1 + *** This is done by splitting the rho parameter + *** into 2 parts: an integer part and a fraction part. + *** Inrement<<7 is estimated by doing: + *** [2^(int+fract)]<<7 + *** that is equal to: + *** (2^int) * [(2^fract) <<7] + *** 2^int is straightly computed as 1<hybla.rho) * hybla_slowstart_fraction_increment(rho_fractions) ) - 128; + odd = increment % 128; + window += (increment >> 7); + } else { + /*** congestion avoidance + *** INC = RHO^2 / W + *** as long as increment is estimated as (rho<<7)/window + *** it already is <<7 and we can easily count its fractions. + ***/ + increment =(tp->hybla.rho2_7ls/window); + odd = increment % 128; + window += (increment >> 7); + + if (increment < 128) + tp->snd_cwnd_cnt++; + } + tp->hybla.snd_cwnd_cents += odd; + + /*** + *** check when fractions goes >=128 + *** and increase cwnd by 1. + ***/ + while( tp->hybla.snd_cwnd_cents >= 128){ + window++; + tp->hybla.snd_cwnd_cents -= 128; + tp->snd_cwnd_cnt = 0; + } + /*** + *** clamp down slowstart cwnd to ssthresh value. + ***/ + if (is_slowstart) + window = min_t(__u32, window, ssthresh); + + tp->snd_cwnd = min_t (__u32, window, clamp); + + tp->snd_cwnd_stamp=tcp_time_stamp; + +} + static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) { - if (tcp_vegas_enabled(tp)) + if (tcp_vegas_enabled(tp)){ vegas_cong_avoid(tp, ack, seq_rtt); - else - reno_cong_avoid(tp); + return; + } + if (sysctl_tcp_hybla){ + tcp_hybla_cong_avoid(tp); + return; + } + reno_cong_avoid(tp); } /* Restart timer after forward progress on connection. diff -ruN linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c hybla-2.6.11-rc4/net/ipv4/tcp_ipv4.c --- linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c 2005-02-13 04:05:51.000000000 +0100 +++ hybla-2.6.11-rc4/net/ipv4/tcp_ipv4.c 2005-02-22 13:19:02.000000000 +0100 @@ -2055,6 +2055,9 @@ * efficiently to them. -DaveM */ tp->snd_cwnd = 2; + + /* Reset hybla parameters on socket initialization. */ + init_hybla(tp); /* See draft-stevens-tcpca-spec-01 for discussion of the * initialization of these values. diff -ruN linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c hybla-2.6.11-rc4/net/ipv4/tcp_minisocks.c --- linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c 2005-02-13 04:07:01.000000000 +0100 +++ hybla-2.6.11-rc4/net/ipv4/tcp_minisocks.c 2005-02-22 13:17:07.000000000 +0100 @@ -784,6 +784,9 @@ newtp->dsack = 0; newtp->eff_sacks = 0; + + /* Reset hybla parameters on socket initialization. */ + init_hybla(newtp); newtp->probes_out = 0; newtp->num_sacks = 0; --Boundary-00=_ShSHCpsn9pKjOO8-- From davem@davemloft.net Wed Feb 23 19:51:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 19:51:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O3p6IM001243 for ; Wed, 23 Feb 2005 19:51:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D4A0v-0001Ji-00; Wed, 23 Feb 2005 19:50:09 -0800 Date: Wed, 23 Feb 2005 19:50:09 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [1/2] [NET] Add skb_header_release and use it in net/ipv4/tcp Message-Id: <20050223195009.62e3c955.davem@davemloft.net> In-Reply-To: <20050129031740.GA6130@gondor.apana.org.au> References: <20050121204024.6f94fc26.davem@davemloft.net> <20050122054346.GA1635@gondor.apana.org.au> <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2011 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 590 Lines: 14 On Sat, 29 Jan 2005 14:17:40 +1100 Herbert Xu wrote: > This patch adds skb_header_release which can be called when the owner > of an skb no longer needs to access the header at all. What constitutes > the header is left up to the users of the skb to define. > > For instance, for outbound TCP packets we define the header to be > anything in front of the TCP payload. Therefore we add skb_header_release > calls to all the paths where outound TCP packets are produced. > > Signed-off-by: Herbert Xu Queued to 2.6.12-pending From davem@davemloft.net Wed Feb 23 19:52:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 19:52:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O3q3oq001379 for ; Wed, 23 Feb 2005 19:52:03 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D4A2L-0001K2-00; Wed, 23 Feb 2005 19:51:37 -0800 Date: Wed, 23 Feb 2005 19:51:37 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [2/2] [NET] Add skb_header_cloned and use it in e1000/tg3 Message-Id: <20050223195137.1e769c77.davem@davemloft.net> In-Reply-To: <20050215202453.GA4355@gondor.apana.org.au> References: <20050122170533.GB11499@yakov.inr.ac.ru> <20050123071027.GA20296@gondor.apana.org.au> <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> <20050215103312.6178385f.davem@davemloft.net> <20050215202453.GA4355@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 967 Lines: 23 On Wed, 16 Feb 2005 07:24:53 +1100 Herbert Xu wrote: > On Tue, Feb 15, 2005 at 10:33:12AM -0800, David S. Miller wrote: > > > > The tg3 version creates an SKB leak. If pskb_expand_head() fails, we just > > unlock and return NETDEV_TX_OK. The upper layer assumes the driver took > > ownership of the SKB in such a case. I would recommend just kfree_skb()'ing > > the thing when this happens. > > Indeed. Here is the corrected version. > > This patch adds skb_header_cloned which tells us whether we need to > copy the data before we can modify the header part of the skb. Again, > what constitutes the header is left up to the users of the skb to define. > > This patch then uses this function in e1000/tg3 to copy the data before > the TCP/IP header is modified. > > Signed-off-by: Herbert Xu Also queued to 2.6.12, thanks. Someone should cook up the versions for other drivers supporting TSO. From dgibson@ozlabs.org Wed Feb 23 20:13:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:13:48 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DQEC006403 for ; Wed, 23 Feb 2005 20:13:27 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 69C1067A71; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:53:55 +1100 From: David Gibson To: Jeff Garzik Cc: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [0/14] Orinoco driver updates Message-ID: <20050224035355.GA32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1928 Lines: 66 Jeff, please apply: Here's a big stack of patches that make a significant step forward on the long overdue orinoco driver merge. Still quite a long way to go, but it's something. This patch stack is againt Linus' vanilla + Viro's big iomap cleanup patch, as requested. The first 9 patches make only trivial or cosmetic behavioural changes: 1/14 orinoco-carrier Use netif_carrier_*() macros instead of homegrown 'connected' variable. 2/14 orinoco-printks Update various printk()s and other cosmetic strings 3/14 orinoco-delays Use mdelay() and ssleep() instead of outdated ways of delaying. 4/14 orinoco-free-orinocodev Introduce free_orinocodev() function, to reduce noise in future diffs. 5/14 orinoco-cleanup-hermes Assorted cleanups to low-level hardware access code 6/14 orinoco-pci-updates Cleanup to initialization code for the PCI based orinoco devices. 7/14 orinoco-modparm Use modern module_parm macros for orinoco module. 8/14 orinoco-pccard-cleanups Cleanup to PCMCIA initialization code 9/14 orinoco-void-ethersnap Trivial change to is_ethersnap() function to reduce future diff noise. The next 4 patches start to intoduce real new functionality and bug fixes: 10/14 orinoco-no-ibss-any Disallow IBSS mode if no ESSID is set (too many firmwares break, otherwise) 11/14 orinoco-late-tx-wake Delay waking the Tx queue, fixes problems on a number of firwmares 12/14 orinoco-wep-updates Various updates to WEP setup code 13/14 orinoco-update-firmware-detection Updates and bugfixes to firmware detection logic And the final one, is another trivial one: 14/14 orinoco-is-now-0.14alpha2 Update version and changelog to reflect the above patches. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:13:49 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DQgA006402 for ; Wed, 23 Feb 2005 20:13:27 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 7C77767A75; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:54:45 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [1/14] Orinoco driver updates - use netif_carrier_*() Message-ID: <20050224035445.GB32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035355.GA32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 3125 Lines: 99 Removes the orinoco driver's custom and dodgy "connected" variable used to track whether or not we're associated with an AP. Replaces it instead with netif_carrier_ok() settings. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-01-13 09:48:55.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-10 14:22:32.179826024 +1100 @@ -784,7 +784,7 @@ return 1; } - if (! priv->connected) { + if (! netif_carrier_ok(dev)) { /* Oops, the firmware hasn't established a connection, silently drop the packet (this seems to be the safest approach). */ @@ -1269,6 +1269,7 @@ case HERMES_INQ_LINKSTATUS: { struct hermes_linkstatus linkstatus; u16 newstatus; + int connected; if (len != sizeof(linkstatus)) { printk(KERN_WARNING "%s: Unexpected size for linkstatus frame (%d bytes)\n", @@ -1280,15 +1281,14 @@ len / 2); newstatus = le16_to_cpu(linkstatus.linkstatus); - if ( (newstatus == HERMES_LINKSTATUS_CONNECTED) - || (newstatus == HERMES_LINKSTATUS_AP_CHANGE) - || (newstatus == HERMES_LINKSTATUS_AP_IN_RANGE) ) - priv->connected = 1; - else if ( (newstatus == HERMES_LINKSTATUS_NOT_CONNECTED) - || (newstatus == HERMES_LINKSTATUS_DISCONNECTED) - || (newstatus == HERMES_LINKSTATUS_AP_OUT_OF_RANGE) - || (newstatus == HERMES_LINKSTATUS_ASSOC_FAILED) ) - priv->connected = 0; + connected = (newstatus == HERMES_LINKSTATUS_CONNECTED) + || (newstatus == HERMES_LINKSTATUS_AP_CHANGE) + || (newstatus == HERMES_LINKSTATUS_AP_IN_RANGE); + + if (connected) + netif_carrier_on(dev); + else + netif_carrier_off(dev); if (newstatus != priv->last_linkstatus) print_linkstatus(dev, newstatus); @@ -1366,8 +1366,8 @@ } /* firmware will have to reassociate */ + netif_carrier_off(dev); priv->last_linkstatus = 0xffff; - priv->connected = 0; return 0; } @@ -1878,7 +1878,7 @@ priv->hw_unavailable++; priv->last_linkstatus = 0xffff; /* firmware will have to reassociate */ - priv->connected = 0; + netif_carrier_off(dev); orinoco_unlock(priv, &flags); @@ -2388,8 +2388,8 @@ * hardware */ INIT_WORK(&priv->reset_work, (void (*)(void *))orinoco_reset, dev); + netif_carrier_off(dev); priv->last_linkstatus = 0xffff; - priv->connected = 0; return dev; Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2004-10-29 13:16:58.000000000 +1000 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-10 14:22:32.179826024 +1100 @@ -42,7 +42,6 @@ /* driver state */ int open; u16 last_linkstatus; - int connected; /* Net device stuff */ struct net_device *ndev; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:13:48 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DQtW006406 for ; Wed, 23 Feb 2005 20:13:27 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 9A74067A7A; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:57:18 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [4/14] Orinoco driver updates - add free_orinocodev() Message-ID: <20050224035718.GE32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035650.GD32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 5021 Lines: 152 Introduce a free_orinocodev() function into the orinoco driver, used by the hardware type/initialization modules to free the device structure in preference to directly calling free_netdev(). At the moment free_orinocodev() just calls free_netdev(). Future merges will make it clean up internal scanning state, so merging this now will reduce the diff noise. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-18 12:04:03.000000000 +1100 @@ -107,6 +107,7 @@ extern struct net_device *alloc_orinocodev(int sizeof_card, int (*hard_reset)(struct orinoco_private *)); +extern void free_orinocodev(struct net_device *dev); extern int __orinoco_up(struct net_device *dev); extern int __orinoco_down(struct net_device *dev); extern int orinoco_stop(struct net_device *dev); Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-18 13:03:51.846593520 +1100 @@ -2398,6 +2398,11 @@ } +void free_orinocodev(struct net_device *dev) +{ + free_netdev(dev); +} + /********************************************************************/ /* Wireless extensions */ /********************************************************************/ @@ -4131,6 +4136,7 @@ /********************************************************************/ EXPORT_SYMBOL(alloc_orinocodev); +EXPORT_SYMBOL(free_orinocodev); EXPORT_SYMBOL(__orinoco_up); EXPORT_SYMBOL(__orinoco_down); Index: working-2.6/drivers/net/wireless/orinoco_cs.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_cs.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco_cs.c 2005-02-18 12:04:03.000000000 +1100 @@ -235,7 +235,7 @@ dev); unregister_netdev(dev); } - free_netdev(dev); + free_orinocodev(dev); } /* orinoco_cs_detach */ /* Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-02-18 12:04:03.000000000 +1100 @@ -254,7 +254,7 @@ if (dev->irq) free_irq(dev->irq, dev); - free_netdev(dev); + free_orinocodev(dev); } if (pci_ioaddr) @@ -279,7 +279,7 @@ iounmap(priv->hw.iobase); pci_set_drvdata(pdev, NULL); - free_netdev(dev); + free_orinocodev(dev); pci_disable_device(pdev); } Index: working-2.6/drivers/net/wireless/orinoco_plx.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_plx.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco_plx.c 2005-02-18 12:04:03.000000000 +1100 @@ -279,7 +279,7 @@ fail: free_irq(dev->irq, dev); fail_irq: - free_netdev(dev); + free_orinocodev(dev); fail_alloc: pci_iounmap(pdev, mem); fail_map: @@ -304,7 +304,7 @@ pci_set_drvdata(pdev, NULL); - free_netdev(dev); + free_orinocodev(dev); release_region(pci_resource_start(pdev, 3), pci_resource_len(pdev, 3)); Index: working-2.6/drivers/net/wireless/orinoco_tmd.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_tmd.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco_tmd.c 2005-02-18 12:04:03.000000000 +1100 @@ -164,7 +164,7 @@ out4: pci_iounmap(pdev, mem); out3: - free_netdev(dev); + free_orinocodev(dev); out2: release_region(pccard_ioaddr, pccard_iolen); out: @@ -188,7 +188,7 @@ pci_set_drvdata(pdev, NULL); - free_netdev(dev); + free_orinocodev(dev); release_region(pci_resource_start(pdev, 2), pci_resource_len(pdev, 2)); Index: working-2.6/drivers/net/wireless/airport.c =================================================================== --- working-2.6.orig/drivers/net/wireless/airport.c 2005-02-18 12:04:03.000000000 +1100 +++ working-2.6/drivers/net/wireless/airport.c 2005-02-18 12:04:03.000000000 +1100 @@ -149,7 +149,7 @@ ssleep(1); macio_set_drvdata(mdev, NULL); - free_netdev(dev); + free_orinocodev(dev); return 0; } @@ -211,7 +211,7 @@ if (macio_request_resource(mdev, 0, "airport")) { printk(KERN_ERR PFX "can't request IO resource !\n"); - free_netdev(dev); + free_orinocodev(dev); return -EBUSY; } -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:13:48 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DQxt006405 for ; Wed, 23 Feb 2005 20:13:27 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 8F7C367A76; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:56:50 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [3/14] Orinoco driver updates - use mdelay()/ssleep() more Message-ID: <20050224035650.GD32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035524.GC32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 2413 Lines: 66 Use mdelay() or ssleep() instead of various silly more complicated ways of delaying in the orinoco driver. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-01-12 15:13:18.819073992 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-01-12 15:15:33.137654464 +1100 @@ -151,19 +151,11 @@ /* Assert the reset until the card notice */ hermes_write_regn(hw, PCI_COR, HERMES_PCI_COR_MASK); - timeout = jiffies + (HERMES_PCI_COR_ONT * HZ / 1000); - while(time_before(jiffies, timeout)) { - mdelay(1); - } - //mdelay(HERMES_PCI_COR_ONT); + mdelay(HERMES_PCI_COR_ONT); /* Give time for the card to recover from this hard effort */ hermes_write_regn(hw, PCI_COR, 0x0000); - timeout = jiffies + (HERMES_PCI_COR_OFFT * HZ / 1000); - while(time_before(jiffies, timeout)) { - mdelay(1); - } - //mdelay(HERMES_PCI_COR_OFFT); + mdelay(HERMES_PCI_COR_OFFT); /* The card is ready when it's no longer busy */ timeout = jiffies + (HERMES_PCI_COR_BUSYT * HZ / 1000); Index: working-2.6/drivers/net/wireless/orinoco_plx.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_plx.c 2005-01-12 15:13:18.821073688 +1100 +++ working-2.6/drivers/net/wireless/orinoco_plx.c 2005-01-12 15:15:33.138654312 +1100 @@ -356,8 +356,7 @@ static void __exit orinoco_plx_exit(void) { pci_unregister_driver(&orinoco_plx_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_plx_init); Index: working-2.6/drivers/net/wireless/orinoco_tmd.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_tmd.c 2005-01-12 15:13:18.820073840 +1100 +++ working-2.6/drivers/net/wireless/orinoco_tmd.c 2005-01-12 15:16:05.897674184 +1100 @@ -225,8 +225,7 @@ static void __exit orinoco_tmd_exit(void) { pci_unregister_driver(&orinoco_tmd_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_tmd_init); -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXS0006433 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id C38B467A81; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:01:53 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [9/14] Orinoco driver updates - update is_ethersnap() Message-ID: <20050224040153.GK32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040052.GJ32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1554 Lines: 37 Make the is_ethersnap() function take a void * rather than a pointer to the internal header structure. This makes more logical sense and reduces dependencies between different parts of the code. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-24 14:50:48.426788064 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-24 14:50:50.125529816 +1100 @@ -966,15 +966,17 @@ /* Does the frame have a SNAP header indicating it should be * de-encapsulated to Ethernet-II? */ -static inline int is_ethersnap(struct header_struct *hdr) +static inline int is_ethersnap(void *_hdr) { + u8 *hdr = _hdr; + /* We de-encapsulate all packets which, a) have SNAP headers * (i.e. SSAP=DSAP=0xaa and CTRL=0x3 in the 802.2 LLC header * and where b) the OUI of the SNAP header is 00:00:00 or * 00:00:f8 - we need both because different APs appear to use * different OUIs for some reason */ - return (memcmp(&hdr->dsap, &encaps_hdr, 5) == 0) - && ( (hdr->oui[2] == 0x00) || (hdr->oui[2] == 0xf8) ); + return (memcmp(hdr, &encaps_hdr, 5) == 0) + && ( (hdr[5] == 0x00) || (hdr[5] == 0xf8) ); } static inline void orinoco_spy_gather(struct net_device *dev, u_char *mac, -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:02 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DQGt006404 for ; Wed, 23 Feb 2005 20:13:27 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 8408867A6E; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:55:24 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2/14] Orinoco driver updates - update printk()s Message-ID: <20050224035524.GC32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035445.GB32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 18685 Lines: 581 Reformats printk()s, comments, labels and other cosmetic strings in the orinoco driver. Also moves, removes, and adds ratelimiting in some places. Behavioural changes are trivial/cosmetic only. This reduces the cosmetic/trivial differences between the current kernel version, and the CVS version of the driver; one small step towards full merge. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/hermes.c =================================================================== --- working-2.6.orig/drivers/net/wireless/hermes.c 2005-02-10 14:47:39.572667480 +1100 +++ working-2.6/drivers/net/wireless/hermes.c 2005-02-10 14:47:41.293405888 +1100 @@ -48,6 +48,7 @@ #include #include #include +#include #include #include "hermes.h" @@ -232,13 +233,16 @@ err = hermes_issue_cmd(hw, cmd, parm0); if (err) { if (! hermes_present(hw)) { - printk(KERN_WARNING "hermes @ %p: " - "Card removed while issuing command.\n", - hw->iobase); + if (net_ratelimit()) + printk(KERN_WARNING "hermes @ %p: " + "Card removed while issuing command " + "0x%04x.\n", hw->iobase, cmd); err = -ENODEV; } else - printk(KERN_ERR "hermes @ %p: Error %d issuing command.\n", - hw->iobase, err); + if (net_ratelimit()) + printk(KERN_ERR "hermes @ %p: " + "Error %d issuing command 0x%04x.\n", + hw->iobase, err, cmd); goto out; } @@ -251,17 +255,16 @@ } if (! hermes_present(hw)) { - printk(KERN_WARNING "hermes @ %p: " - "Card removed while waiting for command completion.\n", - hw->iobase); + printk(KERN_WARNING "hermes @ %p: Card removed " + "while waiting for command 0x%04x completion.\n", + hw->iobase, cmd); err = -ENODEV; goto out; } if (! (reg & HERMES_EV_CMD)) { - printk(KERN_ERR "hermes @ %p: " - "Timeout waiting for command completion.\n", - hw->iobase); + printk(KERN_ERR "hermes @ %p: Timeout waiting for " + "command 0x%04x completion.\n", hw->iobase, cmd); err = -ETIMEDOUT; goto out; } @@ -481,14 +484,13 @@ *length = rlength; if (rtype != rid) - printk(KERN_WARNING "hermes @ %p: " - "hermes_read_ltv(): rid (0x%04x) does not match type (0x%04x)\n", - hw->iobase, rid, rtype); + printk(KERN_WARNING "hermes @ %p: %s(): " + "rid (0x%04x) does not match type (0x%04x)\n", + hw->iobase, __FUNCTION__, rid, rtype); if (HERMES_RECLEN_TO_BYTES(rlength) > bufsize) printk(KERN_WARNING "hermes @ %p: " "Truncating LTV record from %d to %d bytes. " - "(rid=0x%04x, len=0x%04x)\n", - hw->iobase, + "(rid=0x%04x, len=0x%04x)\n", hw->iobase, HERMES_RECLEN_TO_BYTES(rlength), bufsize, rid, rlength); nwords = min((unsigned)rlength - 1, bufsize / 2); Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-02-10 14:47:39.573667328 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-02-10 14:47:41.294405736 +1100 @@ -151,24 +151,18 @@ /* Assert the reset until the card notice */ hermes_write_regn(hw, PCI_COR, HERMES_PCI_COR_MASK); - printk(KERN_NOTICE "Reset done"); timeout = jiffies + (HERMES_PCI_COR_ONT * HZ / 1000); while(time_before(jiffies, timeout)) { - printk("."); mdelay(1); } - printk(";\n"); //mdelay(HERMES_PCI_COR_ONT); /* Give time for the card to recover from this hard effort */ hermes_write_regn(hw, PCI_COR, 0x0000); - printk(KERN_NOTICE "Clear Reset"); timeout = jiffies + (HERMES_PCI_COR_OFFT * HZ / 1000); while(time_before(jiffies, timeout)) { - printk("."); mdelay(1); } - printk(";\n"); //mdelay(HERMES_PCI_COR_OFFT); /* The card is ready when it's no longer busy */ @@ -183,7 +177,6 @@ printk(KERN_ERR PFX "Busy timeout\n"); return -ETIMEDOUT; } - printk(KERN_NOTICE "pci_cor : reg = 0x%X - %lX - %lX\n", reg, timeout, jiffies); return 0; } @@ -202,15 +195,19 @@ struct net_device *dev = NULL; err = pci_enable_device(pdev); - if (err) - return -EIO; + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); + return err; + } /* Resource 0 is mapped to the hermes registers */ pci_iorange = pci_resource_start(pdev, 0); pci_iolen = pci_resource_len(pdev, 0); pci_ioaddr = ioremap(pci_iorange, pci_iolen); - if (! pci_iorange) + if (! pci_iorange) { + printk(KERN_ERR PFX "Cannot remap hardware registers\n"); goto fail; + } /* Allocate network device */ dev = alloc_orinocodev(0, NULL); @@ -226,18 +223,16 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - printk(KERN_DEBUG PFX - "Detected Orinoco/Prism2 PCI device at %s, mem:0x%lX to 0x%lX -> 0x%p, irq:%d\n", - pci_name(pdev), dev->mem_start, dev->mem_end, pci_ioaddr, pdev->irq); - hermes_struct_init(&priv->hw, pci_ioaddr, HERMES_32BIT_REGSPACING); pci_set_drvdata(pdev, dev); + printk(KERN_DEBUG PFX "Detected device %s, mem:0x%lx-0x%lx, irq %d\n", + pci_name(pdev), dev->mem_start, dev->mem_end, pdev->irq); + err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", - pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; goto fail; } @@ -245,7 +240,7 @@ /* Perform a COR reset to start the card */ if(orinoco_pci_cor_reset(priv) != 0) { - printk(KERN_ERR "%s: Failed to start the card\n", dev->name); + printk(KERN_ERR PFX "Initial reset failed\n"); err = -ETIMEDOUT; goto fail; } @@ -256,7 +251,7 @@ err = register_netdev(dev); if (err) { - printk(KERN_ERR "%s: Failed to register net device\n", dev->name); + printk(KERN_ERR PFX "Failed to register net device\n"); goto fail; } Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2005-02-10 14:47:40.526522472 +1100 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-10 14:47:41.294405736 +1100 @@ -126,7 +126,7 @@ { spin_lock_irqsave(&priv->lock, *flags); if (priv->hw_unavailable) { - printk(KERN_DEBUG "orinoco_lock() called with hw_unavailable (dev=%p)\n", + DEBUG(1, "orinoco_lock() called with hw_unavailable (dev=%p)\n", priv->ndev); spin_unlock_irqrestore(&priv->lock, *flags); return -EBUSY; Index: working-2.6/drivers/net/wireless/orinoco_tmd.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_tmd.c 2005-02-10 14:47:39.574667176 +1100 +++ working-2.6/drivers/net/wireless/orinoco_tmd.c 2005-02-10 14:47:41.295405584 +1100 @@ -92,8 +92,10 @@ void __iomem *mem; err = pci_enable_device(pdev); - if (err) + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); return -EIO; + } printk(KERN_DEBUG PFX "TMD setup\n"); pccard_ioaddr = pci_resource_start(pdev, 2); @@ -117,6 +119,7 @@ /* Allocate network device */ dev = alloc_orinocodev(0, NULL); if (! dev) { + printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; goto out2; } @@ -132,26 +135,27 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); + hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); + pci_set_drvdata(pdev, dev); + printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 TMD device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, pccard_ioaddr); - hermes_struct_init(&(priv->hw), mem, HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); - err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", - pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; goto out4; } dev->irq = pdev->irq; err = register_netdev(dev); - if (err) + if (err) { + printk(KERN_ERR PFX "Cannot register network device\n"); goto out5; + } return 0; Index: working-2.6/drivers/net/wireless/orinoco_cs.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_cs.c 2005-02-10 14:47:39.573667328 +1100 +++ working-2.6/drivers/net/wireless/orinoco_cs.c 2005-02-10 14:47:41.295405584 +1100 @@ -391,7 +391,7 @@ last_ret = pcmcia_get_next_tuple(handle, &tuple); if (last_ret == CS_NO_MORE_ITEMS) { printk(KERN_ERR PFX "GetNextTuple(): No matching " - "CIS configuration, maybe you need the " + "CIS configuration. Maybe you need the " "ignore_cis_vcc=1 parameter.\n"); goto cs_failed; } Index: working-2.6/drivers/net/wireless/airport.c =================================================================== --- working-2.6.orig/drivers/net/wireless/airport.c 2005-02-10 14:47:39.571667632 +1100 +++ working-2.6/drivers/net/wireless/airport.c 2005-02-10 14:47:41.295405584 +1100 @@ -28,7 +28,6 @@ #include #include #include -#include #include #include @@ -194,14 +193,14 @@ hermes_t *hw; if (macio_resource_count(mdev) < 1 || macio_irq_count(mdev) < 1) { - printk(KERN_ERR PFX "wrong interrupt/addresses in OF tree\n"); + printk(KERN_ERR PFX "Wrong interrupt/addresses in OF tree\n"); return -ENODEV; } /* Allocate space for private device-specific data */ dev = alloc_orinocodev(sizeof(*card), airport_hard_reset); if (! dev) { - printk(KERN_ERR PFX "can't allocate device datas\n"); + printk(KERN_ERR PFX "Cannot allocate network device\n"); return -ENODEV; } priv = netdev_priv(dev); @@ -224,11 +223,11 @@ /* Setup interrupts & base address */ dev->irq = macio_irq(mdev, 0); phys_addr = macio_resource_start(mdev, 0); /* Physical address */ - printk(KERN_DEBUG PFX "Airport at physical address %lx\n", phys_addr); + printk(KERN_DEBUG PFX "Physical address %lx\n", phys_addr); dev->base_addr = phys_addr; card->vaddr = ioremap(phys_addr, AIRPORT_IO_LEN); if (!card->vaddr) { - printk(PFX "ioremap() failed\n"); + printk(KERN_ERR PFX "ioremap() failed\n"); goto failed; } @@ -241,7 +240,7 @@ /* Reset it before we get the interrupt */ hermes_init(hw); - if (request_irq(dev->irq, orinoco_interrupt, 0, "Airport", dev)) { + if (request_irq(dev->irq, orinoco_interrupt, 0, dev->name, dev)) { printk(KERN_ERR PFX "Couldn't get IRQ %d\n", dev->irq); goto failed; } @@ -252,7 +251,7 @@ printk(KERN_ERR PFX "register_netdev() failed\n"); goto failed; } - printk(KERN_DEBUG PFX "card registered for interface %s\n", dev->name); + printk(KERN_DEBUG PFX "Card registered for interface %s\n", dev->name); card->ndev_registered = 1; return 0; failed: Index: working-2.6/drivers/net/wireless/orinoco_plx.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_plx.c 2005-02-10 14:47:39.574667176 +1100 +++ working-2.6/drivers/net/wireless/orinoco_plx.c 2005-02-10 14:47:41.296405432 +1100 @@ -167,15 +167,17 @@ int i; err = pci_enable_device(pdev); - if (err) + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); return -EIO; + } /* Resource 2 is mapped to the PCMCIA space */ attr_mem = ioremap(pci_resource_start(pdev, 2), PAGE_SIZE); if (!attr_mem) - goto out; + goto fail_resources; - printk(KERN_DEBUG "orinoco_plx: CIS: "); + printk(KERN_DEBUG PFX "CIS: "); for (i = 0; i < 16; i++) { printk("%02X:", readw(attr_mem+i)); } @@ -185,10 +187,11 @@ /* FIXME: we probably need to be smarted about this */ memcpy_fromio(magic, attr_mem, 16); if (memcmp(magic, cis_magic, 16) != 0) { - printk(KERN_ERR "orinoco_plx: The CIS value of Prism2 PC card is invalid.\n"); + printk(KERN_ERR PFX "The CIS value of Prism2 PC " + "card is unexpected\n"); err = -EIO; iounmap(attr_mem); - goto out; + goto fail_resources; } /* PCMCIA COR is the first byte following CIS: this write should @@ -199,8 +202,8 @@ iounmap(attr_mem); if (reg != COR_VALUE) { - printk(KERN_ERR "orinoco_plx: Error setting COR value (reg=%x)\n", reg); - goto out; + printk(KERN_ERR PFX "Error setting COR value (reg=%x)\n", reg); + goto fail_resources; } /* bjoern: We need to tell the card to enable interrupts, in @@ -209,40 +212,39 @@ addr = pci_resource_start(pdev, 1); reg = inl(addr+PLX_INTCSR); if (reg & PLX_INTCSR_INTEN) - printk(KERN_DEBUG "orinoco_plx: " - "Local Interrupt already enabled\n"); + printk(KERN_DEBUG PFX "Local Interrupt already enabled\n"); else { reg |= PLX_INTCSR_INTEN; outl(reg, addr+PLX_INTCSR); reg = inl(addr+PLX_INTCSR); if(!(reg & PLX_INTCSR_INTEN)) { - printk(KERN_ERR "orinoco_plx: " - "Couldn't enable Local Interrupts\n"); - goto out; + printk(KERN_ERR PFX "Couldn't enable Local Interrupts\n"); + goto fail_resources; } } - /* and 3 to the PCMCIA slot I/O address space */ + /* Resource 3 is mapped to the PCMCIA I/O address space */ pccard_ioaddr = pci_resource_start(pdev, 3); pccard_iolen = pci_resource_len(pdev, 3); if (! request_region(pccard_ioaddr, pccard_iolen, DRIVER_NAME)) { - printk(KERN_ERR "orinoco_plx: I/O resource 0x%lx @ 0x%lx busy\n", + printk(KERN_ERR PFX "I/O resource 0x%lx @ 0x%lx busy\n", pccard_iolen, pccard_ioaddr); err = -EBUSY; - goto out; + goto fail_resources; } mem = pci_iomap(pdev, 3, 0); if (!mem) { err = -ENOMEM; - goto out1; + goto fail_map; } /* Allocate network device */ dev = alloc_orinocodev(0, NULL); if (!dev) { + printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; - goto out2; + goto fail_alloc; } priv = netdev_priv(dev); @@ -250,39 +252,41 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); + hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); + pci_set_drvdata(pdev, dev); + printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 PLX device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, pccard_ioaddr); - hermes_struct_init(&(priv->hw), mem, HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); - err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto out3; + goto fail_irq; } dev->irq = pdev->irq; err = register_netdev(dev); - if (err) - goto out4; + if (err) { + printk(KERN_ERR PFX "Cannot register network device\n"); + goto fail; + } return 0; -out4: + fail: free_irq(dev->irq, dev); -out3: + fail_irq: free_netdev(dev); -out2: + fail_alloc: pci_iounmap(pdev, mem); -out1: + fail_map: release_region(pccard_ioaddr, pccard_iolen); -out: + fail_resources: pci_disable_device(pdev); - printk(KERN_DEBUG PFX "init_one(), FAIL!\n"); + return err; } Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-10 14:47:40.525522624 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-10 14:47:41.298405128 +1100 @@ -805,8 +805,9 @@ desc.tx_control = cpu_to_le16(HERMES_TXCTRL_TX_OK | HERMES_TXCTRL_TX_EX); err = hermes_bap_pwrite(hw, USER_BAP, &desc, sizeof(desc), txfid, 0); if (err) { - printk(KERN_ERR "%s: Error %d writing Tx descriptor to BAP\n", - dev->name, err); + if (net_ratelimit()) + printk(KERN_ERR "%s: Error %d writing Tx descriptor " + "to BAP\n", dev->name, err); stats->tx_errors++; goto fail; } @@ -836,8 +837,9 @@ err = hermes_bap_pwrite(hw, USER_BAP, &hdr, sizeof(hdr), txfid, HERMES_802_3_OFFSET); if (err) { - printk(KERN_ERR "%s: Error %d writing packet header to BAP\n", - dev->name, err); + if (net_ratelimit()) + printk(KERN_ERR "%s: Error %d writing packet " + "header to BAP\n", dev->name, err); stats->tx_errors++; goto fail; } @@ -1297,8 +1299,8 @@ } break; default: - printk(KERN_DEBUG "%s: Unknown information frame received " - "(type %04x).\n", dev->name, type); + printk(KERN_DEBUG "%s: Unknown information frame received: " + "type 0x%04x, length %d\n", dev->name, type, len); /* We don't actually do anything about it */ break; } @@ -1307,7 +1309,7 @@ static void __orinoco_ev_infdrop(struct net_device *dev, hermes_t *hw) { if (net_ratelimit()) - printk(KERN_WARNING "%s: Information frame lost.\n", dev->name); + printk(KERN_DEBUG "%s: Information frame lost.\n", dev->name); } /********************************************************************/ @@ -1785,7 +1787,8 @@ } if (p) - printk(KERN_WARNING "Multicast list is longer than mc_count\n"); + printk(KERN_WARNING "%s: Multicast list is " + "longer than mc_count\n", dev->name); err = hermes_write_ltv(hw, USER_BAP, HERMES_RID_CNFGROUPADDRESSES, HERMES_BYTES_TO_RECLEN(priv->mc_count * ETH_ALEN), @@ -2053,7 +2056,7 @@ le16_to_cpus(&sta_id.variant); le16_to_cpus(&sta_id.major); le16_to_cpus(&sta_id.minor); - printk(KERN_DEBUG "%s: Station identity %04x:%04x:%04x:%04x\n", + printk(KERN_DEBUG "%s: Station identity %04x:%04x:%04x:%04x\n", dev->name, sta_id.id, sta_id.variant, sta_id.major, sta_id.minor); @@ -3045,8 +3048,9 @@ priv->mwo_robust = 0; else { if (frq->fixed) - printk(KERN_WARNING "%s: Fixed fragmentation not \ -supported on this firmware. Using MWO robust instead.\n", dev->name); + printk(KERN_WARNING "%s: Fixed fragmentation is " + "not supported on this firmware. " + "Using MWO robust instead.\n", dev->name); priv->mwo_robust = 1; } } else { @@ -3518,7 +3522,7 @@ } /* Copy stats */ /* In theory, we should disable irqs while copying the stats - * because the rx path migh update it in the middle... + * because the rx path might update it in the middle... * Bah, who care ? - Jean II */ memcpy(&spy_stat, priv->spy_stat, sizeof(struct iw_quality) * IW_MAX_SPY); -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:07 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXp8006430 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id A4BAA67A7B; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:58:04 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [5/14] Orinoco driver updates - cleanup low-level code Message-ID: <20050224035804.GF32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035718.GE32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 2191 Lines: 65 Apply some cleanups to the low-level orinoco handling code in hermes.[ch]. This cleans up some error handling code, corrects an error code to something more accurate, and also increases a timeout value. This last can (when the hardware plays up) cause long delays with spinlocks held, which is bad, but is rather less prone to prematurely giving up, which has the unfortunate habit of fatally confusing the hardware in other ways :-/. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/hermes.c =================================================================== --- working-2.6.orig/drivers/net/wireless/hermes.c 2005-01-12 15:22:34.263633584 +1100 +++ working-2.6/drivers/net/wireless/hermes.c 2004-11-05 13:59:07.000000000 +1100 @@ -383,12 +383,17 @@ reg = hermes_read_reg(hw, oreg); } - if (reg & HERMES_OFFSET_BUSY) { - return -ETIMEDOUT; - } + if (reg != offset) { + printk(KERN_ERR "hermes @ %p: BAP%d offset %s: " + "reg=0x%x id=0x%x offset=0x%x\n", hw->iobase, bap, + (reg & HERMES_OFFSET_BUSY) ? "timeout" : "error", + reg, id, offset); + + if (reg & HERMES_OFFSET_BUSY) { + return -ETIMEDOUT; + } - if (reg & HERMES_OFFSET_ERR) { - return -EIO; + return -EIO; /* error or wrong offset */ } return 0; @@ -476,7 +481,7 @@ rlength = hermes_read_reg(hw, dreg); if (! rlength) - return -ENOENT; + return -ENODATA; rtype = hermes_read_reg(hw, dreg); Index: working-2.6/drivers/net/wireless/hermes.h =================================================================== --- working-2.6.orig/drivers/net/wireless/hermes.h 2005-01-12 11:13:41.000000000 +1100 +++ working-2.6/drivers/net/wireless/hermes.h 2004-11-05 13:53:55.000000000 +1100 @@ -340,7 +340,7 @@ #ifdef __KERNEL__ /* Timeouts */ -#define HERMES_BAP_BUSY_TIMEOUT (500) /* In iterations of ~1us */ +#define HERMES_BAP_BUSY_TIMEOUT (10000) /* In iterations of ~1us */ /* Basic control structure */ typedef struct hermes { -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXjJ006434 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id C906B67A79; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:02:28 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [10/14] Orinoco driver updates - prohibit IBSS with no ESSID Message-ID: <20050224040228.GL32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040153.GK32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 2688 Lines: 80 Remove has_ibss_any flag and never set the CREATEIBSS RID when the ESSID is empty. Too many firmware break if we do. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-24 14:50:50.125529816 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-24 14:50:53.166067584 +1100 @@ -1580,21 +1580,26 @@ } if (priv->has_ibss) { - err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFCREATEIBSS, - priv->createibss); - if (err) { - printk(KERN_ERR "%s: Error %d setting CREATEIBSS\n", dev->name, err); - return err; - } + u16 createibss; - if ((strlen(priv->desired_essid) == 0) && (priv->createibss) - && (!priv->has_ibss_any)) { + if ((strlen(priv->desired_essid) == 0) && (priv->createibss)) { printk(KERN_WARNING "%s: This firmware requires an " "ESSID in IBSS-Ad-Hoc mode.\n", dev->name); /* With wvlan_cs, in this case, we would crash. * hopefully, this driver will behave better... * Jean II */ + createibss = 0; + } else { + createibss = priv->createibss; + } + + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFCREATEIBSS, + createibss); + if (err) { + printk(KERN_ERR "%s: Error %d setting CREATEIBSS\n", + dev->name, err); + return err; } } @@ -2073,7 +2078,6 @@ priv->has_preamble = 0; priv->has_port3 = 1; priv->has_ibss = 1; - priv->has_ibss_any = 0; priv->has_wep = 0; priv->has_big_wep = 0; @@ -2089,7 +2093,6 @@ firmver = ((unsigned long)sta_id.major << 16) | sta_id.minor; priv->has_ibss = (firmver >= 0x60006); - priv->has_ibss_any = (firmver >= 0x60010); priv->has_wep = (firmver >= 0x40020); priv->has_big_wep = 1; /* FIXME: this is wrong - how do we tell Gold cards from the others? */ Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2005-02-24 14:50:46.549073520 +1100 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-24 14:50:53.167067432 +1100 @@ -57,7 +57,7 @@ #define FIRMWARE_TYPE_AGERE 1 #define FIRMWARE_TYPE_INTERSIL 2 #define FIRMWARE_TYPE_SYMBOL 3 - int has_ibss, has_port3, has_ibss_any, ibss_port; + int has_ibss, has_port3, ibss_port; int has_wep, has_big_wep; int has_mwo; int has_pm; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DX8Y006431 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id B5B8767A7E; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:00:24 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [7/14] Orinoco driver updates - use modern module_parm() Message-ID: <20050224040024.GI32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035957.GH32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1323 Lines: 33 Add descrptions to module parameters in the orinoco driver, and also add permissions to allow them to be exported in sysfs. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-10 13:19:14.000000000 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-10 13:24:03.000000000 +1100 @@ -461,12 +461,14 @@ /* Level of debugging. Used in the macros in orinoco.h */ #ifdef ORINOCO_DEBUG int orinoco_debug = ORINOCO_DEBUG; -module_param(orinoco_debug, int, 0); +module_param(orinoco_debug, int, 0644); +MODULE_PARM_DESC(orinoco_debug, "Debug level"); EXPORT_SYMBOL(orinoco_debug); #endif static int suppress_linkstatus; /* = 0 */ -module_param(suppress_linkstatus, bool, 0); +module_param(suppress_linkstatus, bool, 0644); +MODULE_PARM_DESC(suppress_linkstatus, "Don't log link status changes"); /********************************************************************/ /* Compile time configuration and compatibility stuff */ -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:07 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXvB006441 for ; Wed, 23 Feb 2005 20:13:34 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id D4ABF67A85; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:04:09 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [13/14] Orinoco driver updates - update firmware detection Message-ID: <20050224040409.GO32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> <20050224040228.GL32001@localhost.localdomain> <20050224040258.GM32001@localhost.localdomain> <20050224040319.GN32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040319.GN32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 8103 Lines: 249 Update firmware detection code. This will now reliably detect Intersil firmwares past verison 1.x, a serious flaw in the previous code. It cleans up the code, and reduces the size of the private structure by using single bits for the various firmware feature flags. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-24 14:50:57.300439064 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-24 14:50:59.879047056 +1100 @@ -2047,39 +2047,54 @@ /* Initialization */ /********************************************************************/ -struct sta_id { +struct comp_id { u16 id, variant, major, minor; } __attribute__ ((packed)); -static int determine_firmware_type(struct net_device *dev, struct sta_id *sta_id) +static inline fwtype_t determine_firmware_type(struct comp_id *nic_id) { - /* FIXME: this is fundamentally broken */ - unsigned int firmver = ((u32)sta_id->major << 16) | sta_id->minor; - - if (sta_id->variant == 1) + if (nic_id->id < 0x8000) return FIRMWARE_TYPE_AGERE; - else if ((sta_id->variant == 2) && - ((firmver == 0x10001) || (firmver == 0x20001))) + else if (nic_id->id == 0x8000 && nic_id->major == 0) return FIRMWARE_TYPE_SYMBOL; else return FIRMWARE_TYPE_INTERSIL; } -static void determine_firmware(struct net_device *dev) +/* Set priv->firmware type, determine firmware properties */ +static int determine_firmware(struct net_device *dev) { struct orinoco_private *priv = netdev_priv(dev); hermes_t *hw = &priv->hw; int err; - struct sta_id sta_id; + struct comp_id nic_id, sta_id; unsigned int firmver; char tmp[SYMBOL_MAX_VER_LEN+1]; + /* Get the hardware version */ + err = HERMES_READ_RECORD(hw, USER_BAP, HERMES_RID_NICID, &nic_id); + if (err) { + printk(KERN_ERR "%s: Cannot read hardware identity: error %d\n", + dev->name, err); + return err; + } + + le16_to_cpus(&nic_id.id); + le16_to_cpus(&nic_id.variant); + le16_to_cpus(&nic_id.major); + le16_to_cpus(&nic_id.minor); + printk(KERN_DEBUG "%s: Hardware identity %04x:%04x:%04x:%04x\n", + dev->name, nic_id.id, nic_id.variant, + nic_id.major, nic_id.minor); + + priv->firmware_type = determine_firmware_type(&nic_id); + /* Get the firmware version */ err = HERMES_READ_RECORD(hw, USER_BAP, HERMES_RID_STAID, &sta_id); if (err) { - printk(KERN_WARNING "%s: Error %d reading firmware info. Wildly guessing capabilities...\n", + printk(KERN_ERR "%s: Cannot read station identity: error %d\n", dev->name, err); - memset(&sta_id, 0, sizeof(sta_id)); + return err; } le16_to_cpus(&sta_id.id); @@ -2090,8 +2105,23 @@ dev->name, sta_id.id, sta_id.variant, sta_id.major, sta_id.minor); - if (! priv->firmware_type) - priv->firmware_type = determine_firmware_type(dev, &sta_id); + switch (sta_id.id) { + case 0x15: + printk(KERN_ERR "%s: Primary firmware is active\n", + dev->name); + return -ENODEV; + case 0x14b: + printk(KERN_ERR "%s: Tertiary firmware is active\n", + dev->name); + return -ENODEV; + case 0x1f: /* Intersil, Agere, Symbol Spectrum24 */ + case 0x21: /* Symbol Spectrum24 Trilogy */ + break; + default: + printk(KERN_NOTICE "%s: Unknown station ID, please report\n", + dev->name); + break; + } /* Default capabilities */ priv->has_sensitivity = 1; @@ -2107,9 +2137,8 @@ case FIRMWARE_TYPE_AGERE: /* Lucent Wavelan IEEE, Lucent Orinoco, Cabletron RoamAbout, ELSA, Melco, HP, IBM, Dell 1150, Compaq 110/210 */ - printk(KERN_DEBUG "%s: Looks like a Lucent/Agere firmware " - "version %d.%02d\n", dev->name, - sta_id.major, sta_id.minor); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Lucent/Agere %d.%02d", sta_id.major, sta_id.minor); firmver = ((unsigned long)sta_id.major << 16) | sta_id.minor; @@ -2152,14 +2181,15 @@ tmp[SYMBOL_MAX_VER_LEN] = '\0'; } - printk(KERN_DEBUG "%s: Looks like a Symbol firmware " - "version [%s] (parsing to %X)\n", dev->name, - tmp, firmver); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Symbol %s", tmp); priv->has_ibss = (firmver >= 0x20000); priv->has_wep = (firmver >= 0x15012); priv->has_big_wep = (firmver >= 0x20000); - priv->has_pm = (firmver >= 0x20000) && (firmver < 0x22000); + priv->has_pm = (firmver >= 0x20000 && firmver < 0x22000) || + (firmver >= 0x29000 && firmver < 0x30000) || + firmver >= 0x31000; priv->has_preamble = (firmver >= 0x20000); priv->ibss_port = 4; /* Tested with Intel firmware : 0x20015 => Jean II */ @@ -2171,9 +2201,9 @@ * different and less well tested */ /* D-Link MAC : 00:40:05:* */ /* Addtron MAC : 00:90:D1:* */ - printk(KERN_DEBUG "%s: Looks like an Intersil firmware " - "version %d.%d.%d\n", dev->name, - sta_id.major, sta_id.minor, sta_id.variant); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Intersil %d.%d.%d", sta_id.major, sta_id.minor, + sta_id.variant); firmver = ((unsigned long)sta_id.major << 16) | ((unsigned long)sta_id.minor << 8) | sta_id.variant; @@ -2191,9 +2221,11 @@ priv->ibss_port = 1; } break; - default: - break; } + printk(KERN_DEBUG "%s: Firmware determined as %s\n", dev->name, + priv->fw_name); + + return 0; } static int orinoco_init(struct net_device *dev) @@ -2219,7 +2251,12 @@ goto out; } - determine_firmware(dev); + err = determine_firmware(dev); + if (err != 0) { + printk(KERN_ERR "%s: Incompatible firmware, aborting\n", + dev->name); + goto out; + } if (priv->has_port3) printk(KERN_DEBUG "%s: Ad-hoc demo mode supported\n", dev->name); Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2005-02-24 14:50:53.167067432 +1100 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-24 14:50:59.879047056 +1100 @@ -30,6 +30,12 @@ char data[ORINOCO_MAX_KEY_SIZE]; } __attribute__ ((packed)); +typedef enum { + FIRMWARE_TYPE_AGERE, + FIRMWARE_TYPE_INTERSIL, + FIRMWARE_TYPE_SYMBOL +} fwtype_t; + struct orinoco_private { void *card; /* Pointer to card dependent structure */ int (*hard_reset)(struct orinoco_private *); @@ -53,19 +59,22 @@ u16 txfid; /* Capabilities of the hardware/firmware */ - int firmware_type; -#define FIRMWARE_TYPE_AGERE 1 -#define FIRMWARE_TYPE_INTERSIL 2 -#define FIRMWARE_TYPE_SYMBOL 3 - int has_ibss, has_port3, ibss_port; - int has_wep, has_big_wep; - int has_mwo; - int has_pm; - int has_preamble; - int has_sensitivity; + fwtype_t firmware_type; + char fw_name[32]; + int ibss_port; int nicbuf_size; u16 channel_mask; - int broken_disableport; + + /* Boolean capabilities */ + unsigned int has_ibss:1; + unsigned int has_port3:1; + unsigned int has_wep:1; + unsigned int has_big_wep:1; + unsigned int has_mwo:1; + unsigned int has_pm:1; + unsigned int has_preamble:1; + unsigned int has_sensitivity:1; + unsigned int broken_disableport:1; /* Configuration paramaters */ u32 iw_mode; Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-02-24 14:50:47.830878656 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-02-24 14:50:59.880046904 +1100 @@ -251,10 +251,6 @@ goto fail; } - /* Override the normal firmware detection - the Prism 2.5 PCI - * cards look like Lucent firmware but are actually Intersil */ - priv->firmware_type = FIRMWARE_TYPE_INTERSIL; - err = register_netdev(dev); if (err) { printk(KERN_ERR PFX "Failed to register net device\n"); -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:06 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXPN006432 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id BA94E67A80; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:00:52 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [8/14] Orinoco driver updates - PCMCIA initialization cleanups Message-ID: <20050224040052.GJ32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040024.GI32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 4418 Lines: 127 Cleanup the various bits of initialization code for PCMCIA / PC-Card orinoco devices. This includes one important bugfix where we could fail to take the lock in some circumstances. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco_cs.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_cs.c 2005-02-18 12:04:03.157157240 +1100 +++ working-2.6/drivers/net/wireless/orinoco_cs.c 2005-02-18 12:11:49.000000000 +1100 @@ -57,8 +57,8 @@ /* Some D-Link cards have buggy CIS. They do work at 5v properly, but * don't have any CIS entry for it. This workaround it... */ static int ignore_cis_vcc; /* = 0 */ - module_param(ignore_cis_vcc, int, 0); +MODULE_PARM_DESC(ignore_cis_vcc, "Allow voltage mismatch between card and socket"); /********************************************************************/ /* Magic constants */ @@ -128,6 +128,7 @@ if (err) return err; + msleep(100); clear_bit(0, &card->hard_reset_in_progress); return 0; @@ -166,9 +167,10 @@ link->priv = dev; /* Interrupt setup */ - link->irq.Attributes = IRQ_TYPE_EXCLUSIVE; + link->irq.Attributes = IRQ_TYPE_EXCLUSIVE | IRQ_HANDLE_PRESENT; link->irq.IRQInfo1 = IRQ_LEVEL_ID; - link->irq.Handler = NULL; + link->irq.Handler = orinoco_interrupt; + link->irq.Instance = dev; /* General socket configuration defaults can go here. In this * client, we assume very little, and rely on the CIS for @@ -184,6 +186,7 @@ dev_list = link; client_reg.dev_info = &dev_info; + client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; client_reg.EventMask = CS_EVENT_CARD_INSERTION | CS_EVENT_CARD_REMOVAL | CS_EVENT_RESET_PHYSICAL | CS_EVENT_CARD_RESET | @@ -309,8 +312,8 @@ cistpl_cftable_entry_t *cfg = &(parse.cftable_entry); cistpl_cftable_entry_t dflt = { .index = 0 }; - if (pcmcia_get_tuple_data(handle, &tuple) != 0 || - pcmcia_parse_tuple(handle, &tuple, &parse) != 0) + if ( (pcmcia_get_tuple_data(handle, &tuple) != 0) + || (pcmcia_parse_tuple(handle, &tuple, &parse) != 0)) goto next_entry; if (cfg->flags & CISTPL_CFTABLE_DEFAULT) @@ -349,8 +352,7 @@ dflt.vpp1.param[CISTPL_POWER_VNOM] / 10000; /* Do we need to allocate an interrupt? */ - if (cfg->irq.IRQInfo1 || dflt.irq.IRQInfo1) - link->conf.Attributes |= CONF_ENABLE_IRQ; + link->conf.Attributes |= CONF_ENABLE_IRQ; /* IO window settings */ link->io.NumPorts1 = link->io.NumPorts2 = 0; @@ -402,14 +404,7 @@ * a handler to the interrupt, unless the 'Handler' member of * the irq structure is initialized. */ - if (link->conf.Attributes & CONF_ENABLE_IRQ) { - link->irq.Attributes = IRQ_TYPE_EXCLUSIVE | IRQ_HANDLE_PRESENT; - link->irq.IRQInfo1 = IRQ_LEVEL_ID; - link->irq.Handler = orinoco_interrupt; - link->irq.Instance = dev; - - CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq)); - } + CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq)); /* We initialize the hermes structure before completing PCMCIA * configuration just in case the interrupt handler gets @@ -434,8 +429,6 @@ SET_MODULE_OWNER(dev); card->node.major = card->node.minor = 0; - /* register_netdev will give us an ethX name */ - dev->name[0] = '\0'; SET_NETDEV_DEV(dev, &handle_to_dev(handle)); /* Tell the stack we exist */ if (register_netdev(dev) != 0) { @@ -458,8 +451,7 @@ if (link->conf.Vpp1) printk(", Vpp %d.%d", link->conf.Vpp1 / 10, link->conf.Vpp1 % 10); - if (link->conf.Attributes & CONF_ENABLE_IRQ) - printk(", irq %d", link->irq.AssignedIRQ); + printk(", irq %d", link->irq.AssignedIRQ); if (link->io.NumPorts1) printk(", io 0x%04x-0x%04x", link->io.BasePort1, link->io.BasePort1 + link->io.NumPorts1 - 1); @@ -525,12 +517,12 @@ case CS_EVENT_CARD_REMOVAL: link->state &= ~DEV_PRESENT; if (link->state & DEV_CONFIG) { - orinoco_lock(priv, &flags); + unsigned long flags; + spin_lock_irqsave(&priv->lock, flags); netif_device_detach(dev); priv->hw_unavailable++; - - orinoco_unlock(priv, &flags); + spin_unlock_irqrestore(&priv->lock, flags); } break; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:08 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DWWu006429 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id AF2B467A7C; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 14:59:57 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [6/14] Orinoco driver updates - cleanup PCI initialization Message-ID: <20050224035957.GH32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224035804.GF32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 17588 Lines: 675 Update the initialization code in the various PCI incarnations of the orinoco driver. This applies similar initialization and shutdown cleanups to the orinoco_pci, orinoco_plx and orinoco_tmd drivers. It also adds COR reset support to the orinoco_plx and orinoco_tmd drivers, improves PCI power management support in the orinoco_pci driver and adds a couple of extra supported cards to the ID tables. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-01-12 15:47:48.215477920 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-01-12 16:10:57.324301280 +1100 @@ -129,6 +129,11 @@ #define HERMES_PCI_COR_OFFT (500) /* ms */ #define HERMES_PCI_COR_BUSYT (500) /* ms */ +/* Orinoco PCI specific data */ +struct orinoco_pci_card { + void __iomem *pci_ioaddr; +}; + /* * Do a soft reset of the PCI card using the Configuration Option Register * We need this to get going... @@ -164,8 +169,9 @@ mdelay(1); reg = hermes_read_regn(hw, CMD); } - /* Did we timeout ? */ - if(time_after_eq(jiffies, timeout)) { + + /* Still busy? */ + if (reg & HERMES_CMD_BUSY) { printk(KERN_ERR PFX "Busy timeout\n"); return -ETIMEDOUT; } @@ -184,6 +190,7 @@ u16 __iomem *pci_ioaddr = NULL; unsigned long pci_iolen; struct orinoco_private *priv = NULL; + struct orinoco_pci_card *card; struct net_device *dev = NULL; err = pci_enable_device(pdev); @@ -192,24 +199,31 @@ return err; } + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); + goto fail_resources; + } + /* Resource 0 is mapped to the hermes registers */ pci_iorange = pci_resource_start(pdev, 0); pci_iolen = pci_resource_len(pdev, 0); pci_ioaddr = ioremap(pci_iorange, pci_iolen); - if (! pci_iorange) { + if (!pci_iorange) { printk(KERN_ERR PFX "Cannot remap hardware registers\n"); - goto fail; + goto fail_map; } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); + dev = alloc_orinocodev(sizeof(*card), orinoco_pci_cor_reset); if (! dev) { err = -ENOMEM; - goto fail; + goto fail_alloc; } priv = netdev_priv(dev); - dev->base_addr = (unsigned long) pci_ioaddr; + card = priv->card; + card->pci_ioaddr = pci_ioaddr; dev->mem_start = pci_iorange; dev->mem_end = pci_iorange + pci_iolen - 1; SET_MODULE_OWNER(dev); @@ -226,14 +240,14 @@ if (err) { printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto fail; + goto fail_irq; } dev->irq = pdev->irq; /* Perform a COR reset to start the card */ - if(orinoco_pci_cor_reset(priv) != 0) { + err = orinoco_pci_cor_reset(priv); + if (err) { printk(KERN_ERR PFX "Initial reset failed\n"); - err = -ETIMEDOUT; goto fail; } @@ -250,16 +264,19 @@ return 0; fail: - if (dev) { - if (dev->irq) - free_irq(dev->irq, dev); + free_irq(pdev->irq, dev); - free_orinocodev(dev); - } + fail_irq: + pci_set_drvdata(pdev, NULL); + free_orinocodev(dev); + + fail_alloc: + iounmap(pci_ioaddr); - if (pci_ioaddr) - iounmap(pci_ioaddr); + fail_map: + pci_release_regions(pdev); + fail_resources: pci_disable_device(pdev); return err; @@ -269,18 +286,14 @@ { struct net_device *dev = pci_get_drvdata(pdev); struct orinoco_private *priv = netdev_priv(dev); + struct orinoco_pci_card *card = priv->card; unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); - - if (priv->hw.iobase) - iounmap(priv->hw.iobase); - + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); free_orinocodev(dev); - + iounmap(card->pci_ioaddr); + pci_release_regions(pdev); pci_disable_device(pdev); } @@ -312,6 +325,9 @@ orinoco_unlock(priv, &flags); + pci_save_state(pdev); + pci_set_power_state(pdev, 3); + return 0; } @@ -324,6 +340,9 @@ printk(KERN_DEBUG "%s: Orinoco-PCI waking up\n", dev->name); + pci_set_power_state(pdev, 0); + pci_restore_state(pdev); + err = orinoco_reinit_firmware(dev); if (err) { printk(KERN_ERR "%s: Error %d re-initializing firmware on orinoco_pci_resume()\n", @@ -354,6 +373,8 @@ {0x1260, 0x3872, PCI_ANY_ID, PCI_ANY_ID,}, /* Intersil Prism 2.5 */ {0x1260, 0x3873, PCI_ANY_ID, PCI_ANY_ID,}, + /* Samsung MagicLAN SWL-2210P */ + {0x167d, 0xa000, PCI_ANY_ID, PCI_ANY_ID,}, {0,}, }; Index: working-2.6/drivers/net/wireless/orinoco_plx.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_plx.c 2005-01-12 15:47:48.216477768 +1100 +++ working-2.6/drivers/net/wireless/orinoco_plx.c 2004-11-05 14:20:30.000000000 +1100 @@ -142,26 +142,68 @@ #include "hermes.h" #include "orinoco.h" -#define COR_OFFSET (0x3e0/2) /* COR attribute offset of Prism2 PC card */ +#define COR_OFFSET (0x3e0) /* COR attribute offset of Prism2 PC card */ #define COR_VALUE (COR_LEVEL_REQ | COR_FUNC_ENA) /* Enable PC card with interrupt in level trigger */ +#define COR_RESET (0x80) /* reset bit in the COR register */ +#define PLX_RESET_TIME (500) /* milliseconds */ #define PLX_INTCSR 0x4c /* Interrupt Control & Status Register */ #define PLX_INTCSR_INTEN (1<<6) /* Interrupt Enable bit */ -static const u16 cis_magic[] = { - 0x0001, 0x0003, 0x0000, 0x0000, 0x00ff, 0x0017, 0x0004, 0x0067 +static const u8 cis_magic[] = { + 0x01, 0x03, 0x00, 0x00, 0xff, 0x17, 0x04, 0x67 }; +/* Orinoco PLX specific data */ +struct orinoco_plx_card { + void __iomem *attr_mem; +}; + +/* + * Do a soft reset of the card using the Configuration Option Register + */ +static int orinoco_plx_cor_reset(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + struct orinoco_plx_card *card = priv->card; + u8 __iomem *attr_mem = card->attr_mem; + unsigned long timeout; + u16 reg; + + writeb(COR_VALUE | COR_RESET, attr_mem + COR_OFFSET); + mdelay(1); + + writeb(COR_VALUE, attr_mem + COR_OFFSET); + mdelay(1); + + /* Just in case, wait more until the card is no longer busy */ + timeout = jiffies + (PLX_RESET_TIME * HZ / 1000); + reg = hermes_read_regn(hw, CMD); + while (time_before(jiffies, timeout) && (reg & HERMES_CMD_BUSY)) { + mdelay(1); + reg = hermes_read_regn(hw, CMD); + } + + /* Did we timeout ? */ + if (reg & HERMES_CMD_BUSY) { + printk(KERN_ERR PFX "Busy timeout\n"); + return -ETIMEDOUT; + } + + return 0; +} + + static int orinoco_plx_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { int err = 0; - u16 __iomem *attr_mem = NULL; - u32 reg, addr; + u8 __iomem *attr_mem = NULL; + u32 csr_reg, plx_addr; struct orinoco_private *priv = NULL; + struct orinoco_plx_card *card; unsigned long pccard_ioaddr = 0; unsigned long pccard_iolen = 0; - u16 magic[8]; struct net_device *dev = NULL; void __iomem *mem; int i; @@ -169,78 +211,38 @@ err = pci_enable_device(pdev); if (err) { printk(KERN_ERR PFX "Cannot enable PCI device\n"); - return -EIO; + return err; } - /* Resource 2 is mapped to the PCMCIA space */ - attr_mem = ioremap(pci_resource_start(pdev, 2), PAGE_SIZE); - if (!attr_mem) + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); goto fail_resources; - - printk(KERN_DEBUG PFX "CIS: "); - for (i = 0; i < 16; i++) { - printk("%02X:", readw(attr_mem+i)); } - printk("\n"); - - /* Verify whether PC card is present */ - /* FIXME: we probably need to be smarted about this */ - memcpy_fromio(magic, attr_mem, 16); - if (memcmp(magic, cis_magic, 16) != 0) { - printk(KERN_ERR PFX "The CIS value of Prism2 PC " - "card is unexpected\n"); - err = -EIO; - iounmap(attr_mem); - goto fail_resources; - } - - /* PCMCIA COR is the first byte following CIS: this write should - * enable I/O mode and select level-triggered interrupts */ - writew(COR_VALUE, attr_mem + COR_OFFSET); - mdelay(1); - reg = readw(attr_mem + COR_OFFSET); - iounmap(attr_mem); - if (reg != COR_VALUE) { - printk(KERN_ERR PFX "Error setting COR value (reg=%x)\n", reg); - goto fail_resources; - } + /* Resource 1 is mapped to PLX-specific registers */ + plx_addr = pci_resource_start(pdev, 1); - /* bjoern: We need to tell the card to enable interrupts, in - case the serial eprom didn't do this already. See the - PLX9052 data book, p8-1 and 8-24 for reference. */ - addr = pci_resource_start(pdev, 1); - reg = inl(addr+PLX_INTCSR); - if (reg & PLX_INTCSR_INTEN) - printk(KERN_DEBUG PFX "Local Interrupt already enabled\n"); - else { - reg |= PLX_INTCSR_INTEN; - outl(reg, addr+PLX_INTCSR); - reg = inl(addr+PLX_INTCSR); - if(!(reg & PLX_INTCSR_INTEN)) { - printk(KERN_ERR PFX "Couldn't enable Local Interrupts\n"); - goto fail_resources; - } + /* Resource 2 is mapped to the PCMCIA attribute memory */ + attr_mem = ioremap(pci_resource_start(pdev, 2), + pci_resource_len(pdev, 2)); + if (!attr_mem) { + printk(KERN_ERR PFX "Cannot remap PCMCIA space\n"); + goto fail_map_attr; } /* Resource 3 is mapped to the PCMCIA I/O address space */ pccard_ioaddr = pci_resource_start(pdev, 3); pccard_iolen = pci_resource_len(pdev, 3); - if (! request_region(pccard_ioaddr, pccard_iolen, DRIVER_NAME)) { - printk(KERN_ERR PFX "I/O resource 0x%lx @ 0x%lx busy\n", - pccard_iolen, pccard_ioaddr); - err = -EBUSY; - goto fail_resources; - } mem = pci_iomap(pdev, 3, 0); if (!mem) { err = -ENOMEM; - goto fail_map; + goto fail_map_io; } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); + dev = alloc_orinocodev(sizeof(*card), orinoco_plx_cor_reset); if (!dev) { printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; @@ -248,6 +250,8 @@ } priv = netdev_priv(dev); + card = priv->card; + card->attr_mem = attr_mem; dev->base_addr = pccard_ioaddr; SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); @@ -268,6 +272,43 @@ } dev->irq = pdev->irq; + /* bjoern: We need to tell the card to enable interrupts, in + case the serial eprom didn't do this already. See the + PLX9052 data book, p8-1 and 8-24 for reference. */ + csr_reg = inl(plx_addr + PLX_INTCSR); + if (!(csr_reg & PLX_INTCSR_INTEN)) { + csr_reg |= PLX_INTCSR_INTEN; + outl(csr_reg, plx_addr + PLX_INTCSR); + csr_reg = inl(plx_addr + PLX_INTCSR); + if (!(csr_reg & PLX_INTCSR_INTEN)) { + printk(KERN_ERR PFX "Cannot enable interrupts\n"); + goto fail; + } + } + + err = orinoco_plx_cor_reset(priv); + if (err) { + printk(KERN_ERR PFX "Initial reset failed\n"); + goto fail; + } + + printk(KERN_DEBUG PFX "CIS: "); + for (i = 0; i < 16; i++) { + printk("%02X:", readb(attr_mem + 2*i)); + } + printk("\n"); + + /* Verify whether a supported PC card is present */ + /* FIXME: we probably need to be smarted about this */ + for (i = 0; i < sizeof(cis_magic); i++) { + if (cis_magic[i] != readb(attr_mem +2*i)) { + printk(KERN_ERR PFX "The CIS value of Prism2 PC " + "card is unexpected\n"); + err = -EIO; + goto fail; + } + } + err = register_netdev(dev); if (err) { printk(KERN_ERR PFX "Cannot register network device\n"); @@ -277,13 +318,21 @@ return 0; fail: - free_irq(dev->irq, dev); + free_irq(pdev->irq, dev); + fail_irq: + pci_set_drvdata(pdev, NULL); free_orinocodev(dev); + fail_alloc: pci_iounmap(pdev, mem); - fail_map: - release_region(pccard_ioaddr, pccard_iolen); + + fail_map_io: + iounmap(attr_mem); + + fail_map_attr: + pci_release_regions(pdev); + fail_resources: pci_disable_device(pdev); @@ -294,20 +343,18 @@ { struct net_device *dev = pci_get_drvdata(pdev); struct orinoco_private *priv = netdev_priv(dev); + struct orinoco_plx_card *card = priv->card; + u8 __iomem *attr_mem = card->attr_mem; - unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); + BUG_ON(! dev); - pci_iounmap(pdev, priv->hw.iobase); - + unregister_netdev(dev); + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); - free_orinocodev(dev); - - release_region(pci_resource_start(pdev, 3), pci_resource_len(pdev, 3)); - + pci_iounmap(pdev, priv->hw.iobase); + iounmap(attr_mem); + pci_release_regions(pdev); pci_disable_device(pdev); } Index: working-2.6/drivers/net/wireless/orinoco_tmd.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_tmd.c 2005-01-12 15:47:48.216477768 +1100 +++ working-2.6/drivers/net/wireless/orinoco_tmd.c 2004-11-05 14:37:35.000000000 +1100 @@ -79,59 +79,89 @@ #include "orinoco.h" #define COR_VALUE (COR_LEVEL_REQ | COR_FUNC_ENA) /* Enable PC card with interrupt in level trigger */ +#define COR_RESET (0x80) /* reset bit in the COR register */ +#define TMD_RESET_TIME (500) /* milliseconds */ + +/* Orinoco TMD specific data */ +struct orinoco_tmd_card { + u32 tmd_io; +}; + + +/* + * Do a soft reset of the card using the Configuration Option Register + */ +static int orinoco_tmd_cor_reset(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + struct orinoco_tmd_card *card = priv->card; + u32 addr = card->tmd_io; + unsigned long timeout; + u16 reg; + + outb(COR_VALUE | COR_RESET, addr); + mdelay(1); + + outb(COR_VALUE, addr); + mdelay(1); + + /* Just in case, wait more until the card is no longer busy */ + timeout = jiffies + (TMD_RESET_TIME * HZ / 1000); + reg = hermes_read_regn(hw, CMD); + while (time_before(jiffies, timeout) && (reg & HERMES_CMD_BUSY)) { + mdelay(1); + reg = hermes_read_regn(hw, CMD); + } + + /* Did we timeout ? */ + if (reg & HERMES_CMD_BUSY) { + printk(KERN_ERR PFX "Busy timeout\n"); + return -ETIMEDOUT; + } + + return 0; +} + static int orinoco_tmd_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { int err = 0; - u32 reg, addr; struct orinoco_private *priv = NULL; - unsigned long pccard_ioaddr = 0; - unsigned long pccard_iolen = 0; + struct orinoco_tmd_card *card; struct net_device *dev = NULL; void __iomem *mem; err = pci_enable_device(pdev); if (err) { printk(KERN_ERR PFX "Cannot enable PCI device\n"); - return -EIO; + return err; } - printk(KERN_DEBUG PFX "TMD setup\n"); - pccard_ioaddr = pci_resource_start(pdev, 2); - pccard_iolen = pci_resource_len(pdev, 2); - if (! request_region(pccard_ioaddr, pccard_iolen, DRIVER_NAME)) { - printk(KERN_ERR PFX "I/O resource at 0x%lx len 0x%lx busy\n", - pccard_ioaddr, pccard_iolen); - err = -EBUSY; - goto out; + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); + goto fail_resources; } - addr = pci_resource_start(pdev, 1); - outb(COR_VALUE, addr); - mdelay(1); - reg = inb(addr); - if (reg != COR_VALUE) { - printk(KERN_ERR PFX "Error setting TMD COR values %x should be %x\n", reg, COR_VALUE); - err = -EIO; - goto out2; + + mem = pci_iomap(pdev, 2, 0); + if (! mem) { + err = -ENOMEM; + goto fail_iomap; } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); + dev = alloc_orinocodev(sizeof(*card), orinoco_tmd_cor_reset); if (! dev) { printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; - goto out2; - } - - mem = pci_iomap(pdev, 2, 0); - if (!mem) { - err = -ENOMEM; - goto out3; + goto fail_alloc; } priv = netdev_priv(dev); - dev->base_addr = pccard_ioaddr; + card = priv->card; + card->tmd_io = pci_resource_start(pdev, 1); + dev->base_addr = pci_resource_start(pdev, 2); SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); @@ -140,36 +170,46 @@ printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 TMD device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, - pccard_ioaddr); + dev->base_addr); err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto out4; + goto fail_irq; } dev->irq = pdev->irq; + err = orinoco_tmd_cor_reset(priv); + if (err) { + printk(KERN_ERR PFX "Initial reset failed\n"); + goto fail; + } + err = register_netdev(dev); if (err) { printk(KERN_ERR PFX "Cannot register network device\n"); - goto out5; + goto fail; } return 0; -out5: - free_irq(dev->irq, dev); -out4: - pci_iounmap(pdev, mem); -out3: + fail: + free_irq(pdev->irq, dev); + + fail_irq: + pci_set_drvdata(pdev, NULL); free_orinocodev(dev); -out2: - release_region(pccard_ioaddr, pccard_iolen); -out: + + fail_alloc: + pci_iounmap(pdev, mem); + + fail_iomap: + pci_release_regions(pdev); + + fail_resources: pci_disable_device(pdev); - printk(KERN_DEBUG PFX "init_one(), FAIL!\n"); return err; } @@ -177,21 +217,16 @@ static void __devexit orinoco_tmd_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct orinoco_private *priv = netdev_priv(dev); + struct orinoco_private *priv = dev->priv; - unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); - - pci_iounmap(pdev, priv->hw.iobase); + BUG_ON(! dev); + unregister_netdev(dev); + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); - free_orinocodev(dev); - - release_region(pci_resource_start(pdev, 2), pci_resource_len(pdev, 2)); - + pci_iounmap(pdev, priv->hw.iobase); + pci_release_regions(pdev); pci_disable_device(pdev); } -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DX8V006442 for ; Wed, 23 Feb 2005 20:13:34 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id D811B67A83; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:05:15 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [14/14] Orinoco driver updates - update version and changelog Message-ID: <20050224040515.GP32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> <20050224040228.GL32001@localhost.localdomain> <20050224040258.GM32001@localhost.localdomain> <20050224040319.GN32001@localhost.localdomain> <20050224040409.GO32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040409.GO32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 2640 Lines: 59 Previous patches have brought the in-kernel orinoco driver roughly to parity with version 0.14alpha2 from out-of-tree. Update the version number and changelog accordingly. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-24 14:50:59.879047056 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-24 14:51:02.388665536 +1100 @@ -393,6 +393,29 @@ * in the rx_dropped statistics. * o Provided a module parameter to suppress linkstatus messages. * + * v0.13e -> v0.14alpha1 - 30 Sep 2003 - David Gibson + * o Replaced priv->connected logic with netif_carrier_on/off() + * calls. + * o Remove has_ibss_any and never set the CREATEIBSS RID when + * the ESSID is empty. Too many firmwares break if we do. + * o 2.6 merges: Replace pdev->slot_name with pci_name(), remove + * __devinitdata from PCI ID tables, use free_netdev(). + * o Enabled shared-key authentication for Agere firmware (from + * Robert J. Moore + * o Move netif_wake_queue() (back) to the Tx completion from the + * ALLOC event. This seems to prevent/mitigate the rolling + * error -110 problems at least on some Intersil firmwares. + * Theoretically reduces performance, but I can't measure it. + * Patch from Andrew Tridgell + * + * v0.14alpha1 -> v0.14alpha2 - 20 Oct 2003 - David Gibson + * o Correctly turn off shared-key authentication when requested + * (bugfix from Robert J. Moore). + * o Correct airport sleep interfaces for current 2.6 kernels. + * o Add code for key change without disabling/enabling the MAC + * port. This is supposed to allow 802.1x to work sanely, but + * doesn't seem to yet. + * * TODO * o New wireless extensions API (patch from Moustafa * Youssef, updated by Jim Carter and Pavel Roskin). Index: working-2.6/drivers/net/wireless/orinoco.h =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.h 2005-02-24 14:50:59.879047056 +1100 +++ working-2.6/drivers/net/wireless/orinoco.h 2005-02-24 14:51:02.389665384 +1100 @@ -7,7 +7,7 @@ #ifndef _ORINOCO_H #define _ORINOCO_H -#define DRIVER_VERSION "0.13e" +#define DRIVER_VERSION "0.14alpha2" #include #include -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:08 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DX6k006438 for ; Wed, 23 Feb 2005 20:13:34 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id D0D9867A84; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:03:19 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [12/14] Orinoco driver updates - WEP updates Message-ID: <20050224040319.GN32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> <20050224040228.GL32001@localhost.localdomain> <20050224040258.GM32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040258.GM32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 8625 Lines: 335 Updates to the WEP configuration code. This adds support for shared key authentication on Agere firmwares. It also adds support (in some cases) for changing the WEP keys without disabling the MAC port (thus triggering a reassociation by the firmware). This is needed by 802.1x implementations, although it's not clear if the code so far is sufficient to allow working 802.1x. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-24 14:50:55.904651256 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-24 14:50:57.300439064 +1100 @@ -1437,55 +1437,46 @@ return err; } -static int __orinoco_hw_setup_wep(struct orinoco_private *priv) +/* Change the WEP keys and/or the current keys. Can be called + * either from __orinoco_hw_setup_wep() or directly from + * orinoco_ioctl_setiwencode(). In the later case the association + * with the AP is not broken (if the firmware can handle it), + * which is needed for 802.1x implementations. */ +static int __orinoco_hw_setup_wepkeys(struct orinoco_private *priv) { hermes_t *hw = &priv->hw; int err = 0; - int master_wep_flag; - int auth_flag; switch (priv->firmware_type) { - case FIRMWARE_TYPE_AGERE: /* Agere style WEP */ - if (priv->wep_on) { - err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFTXKEY_AGERE, - priv->tx_key); - if (err) - return err; - - err = HERMES_WRITE_RECORD(hw, USER_BAP, - HERMES_RID_CNFWEPKEYS_AGERE, - &priv->keys); - if (err) - return err; - } + case FIRMWARE_TYPE_AGERE: + err = HERMES_WRITE_RECORD(hw, USER_BAP, + HERMES_RID_CNFWEPKEYS_AGERE, + &priv->keys); + if (err) + return err; err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFWEPENABLED_AGERE, - priv->wep_on); + HERMES_RID_CNFTXKEY_AGERE, + priv->tx_key); if (err) return err; break; - - case FIRMWARE_TYPE_INTERSIL: /* Intersil style WEP */ - case FIRMWARE_TYPE_SYMBOL: /* Symbol style WEP */ - master_wep_flag = 0; /* Off */ - if (priv->wep_on) { + case FIRMWARE_TYPE_INTERSIL: + case FIRMWARE_TYPE_SYMBOL: + { int keylen; int i; - /* Fudge around firmware weirdness */ + /* Force uniform key length to work around firmware bugs */ keylen = le16_to_cpu(priv->keys[priv->tx_key].len); + if (keylen > LARGE_KEY_SIZE) { + printk(KERN_ERR "%s: BUG: Key %d has oversize length %d.\n", + priv->ndev->name, priv->tx_key, keylen); + return -E2BIG; + } + /* Write all 4 keys */ for(i = 0; i < ORINOCO_MAX_KEYS; i++) { -/* int keylen = le16_to_cpu(priv->keys[i].len); */ - - if (keylen > LARGE_KEY_SIZE) { - printk(KERN_ERR "%s: BUG: Key %d has oversize length %d.\n", - priv->ndev->name, i, keylen); - return -E2BIG; - } - err = hermes_write_ltv(hw, USER_BAP, HERMES_RID_CNFDEFAULTKEY0 + i, HERMES_BYTES_TO_RECLEN(keylen), @@ -1500,27 +1491,63 @@ priv->tx_key); if (err) return err; - - if (priv->wep_restrict) { - auth_flag = 2; - master_wep_flag = 3; - } else { - /* Authentication is where Intersil and Symbol - * firmware differ... */ - auth_flag = 1; - if (priv->firmware_type == FIRMWARE_TYPE_SYMBOL) - master_wep_flag = 3; /* Symbol */ - else - master_wep_flag = 1; /* Intersil */ - } + } + break; + } + + return 0; +} + +static int __orinoco_hw_setup_wep(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + int err = 0; + int master_wep_flag; + int auth_flag; + if (priv->wep_on) + __orinoco_hw_setup_wepkeys(priv); + + if (priv->wep_restrict) + auth_flag = HERMES_AUTH_SHARED_KEY; + else + auth_flag = HERMES_AUTH_OPEN; + + switch (priv->firmware_type) { + case FIRMWARE_TYPE_AGERE: /* Agere style WEP */ + if (priv->wep_on) { + /* Enable the shared-key authentication. */ + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFAUTHENTICATION_AGERE, + auth_flag); + } + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFWEPENABLED_AGERE, + priv->wep_on); + if (err) + return err; + break; + + case FIRMWARE_TYPE_INTERSIL: /* Intersil style WEP */ + case FIRMWARE_TYPE_SYMBOL: /* Symbol style WEP */ + if (priv->wep_on) { + if (priv->wep_restrict || + (priv->firmware_type == FIRMWARE_TYPE_SYMBOL)) + master_wep_flag = HERMES_WEP_PRIVACY_INVOKED | + HERMES_WEP_EXCL_UNENCRYPTED; + else + master_wep_flag = HERMES_WEP_PRIVACY_INVOKED; err = hermes_write_wordrec(hw, USER_BAP, HERMES_RID_CNFAUTHENTICATION, auth_flag); if (err) return err; - } + } else + master_wep_flag = 0; + + if (priv->iw_mode == IW_MODE_MONITOR) + master_wep_flag |= HERMES_WEP_HOST_DECRYPT; /* Master WEP setting : on/off */ err = hermes_write_wordrec(hw, USER_BAP, @@ -1530,13 +1557,6 @@ return err; break; - - default: - if (priv->wep_on) { - printk(KERN_ERR "%s: WEP enabled, although not supported!\n", - priv->ndev->name); - return -EINVAL; - } } return 0; @@ -2702,11 +2722,17 @@ int err = 0; char keybuf[ORINOCO_MAX_KEY_SIZE]; unsigned long flags; - + + if (! priv->has_wep) + return -EOPNOTSUPP; + if (erq->pointer) { - /* We actually have a key to set */ - if ( (erq->length < SMALL_KEY_SIZE) || (erq->length > ORINOCO_MAX_KEY_SIZE) ) - return -EINVAL; + /* We actually have a key to set - check its length */ + if (erq->length > LARGE_KEY_SIZE) + return -E2BIG; + + if ( (erq->length > SMALL_KEY_SIZE) && !priv->has_big_wep ) + return -E2BIG; if (copy_from_user(keybuf, erq->pointer, erq->length)) return -EFAULT; @@ -2714,19 +2740,8 @@ if (orinoco_lock(priv, &flags) != 0) return -EBUSY; - + if (erq->pointer) { - if (erq->length > ORINOCO_MAX_KEY_SIZE) { - err = -E2BIG; - goto out; - } - - if ( (erq->length > LARGE_KEY_SIZE) - || ( ! priv->has_big_wep && (erq->length > SMALL_KEY_SIZE)) ) { - err = -EINVAL; - goto out; - } - if ((index < 0) || (index >= ORINOCO_MAX_KEYS)) index = priv->tx_key; @@ -2737,7 +2752,7 @@ xlen = SMALL_KEY_SIZE; } else xlen = 0; - + /* Switch on WEP if off */ if ((!enable) && (xlen > 0)) { setindex = index; @@ -2761,10 +2776,9 @@ setindex = index; } } - + if (erq->flags & IW_ENCODE_DISABLED) enable = 0; - /* Only for Prism2 & Symbol cards (so far) - Jean II */ if (erq->flags & IW_ENCODE_OPEN) restricted = 0; if (erq->flags & IW_ENCODE_RESTRICTED) @@ -2777,6 +2791,15 @@ memcpy(priv->keys[index].data, keybuf, erq->length); } priv->tx_key = setindex; + + /* Try fast key change if connected and only keys are changed */ + if (priv->wep_on && enable && (priv->wep_restrict == restricted) && + netif_carrier_ok(dev)) { + err = __orinoco_hw_setup_wepkeys(priv); + /* No need to commit if successful */ + goto out; + } + priv->wep_on = enable; priv->wep_restrict = restricted; @@ -2794,6 +2817,9 @@ char keybuf[ORINOCO_MAX_KEY_SIZE]; unsigned long flags; + if (! priv->has_wep) + return -EOPNOTSUPP; + if (orinoco_lock(priv, &flags) != 0) return -EBUSY; @@ -2804,23 +2830,18 @@ if (! priv->wep_on) erq->flags |= IW_ENCODE_DISABLED; erq->flags |= index + 1; - - /* Only for symbol cards - Jean II */ - if (priv->firmware_type != FIRMWARE_TYPE_AGERE) { - if(priv->wep_restrict) - erq->flags |= IW_ENCODE_RESTRICTED; - else - erq->flags |= IW_ENCODE_OPEN; - } + + if (priv->wep_restrict) + erq->flags |= IW_ENCODE_RESTRICTED; + else + erq->flags |= IW_ENCODE_OPEN; xlen = le16_to_cpu(priv->keys[index].len); erq->length = xlen; - if (erq->pointer) { - memcpy(keybuf, priv->keys[index].data, ORINOCO_MAX_KEY_SIZE); - } - + memcpy(keybuf, priv->keys[index].data, ORINOCO_MAX_KEY_SIZE); + orinoco_unlock(priv, &flags); if (erq->pointer) { @@ -3626,22 +3647,12 @@ break; case SIOCSIWENCODE: - if (! priv->has_wep) { - err = -EOPNOTSUPP; - break; - } - err = orinoco_ioctl_setiwencode(dev, &wrq->u.encoding); if (! err) changed = 1; break; case SIOCGIWENCODE: - if (! priv->has_wep) { - err = -EOPNOTSUPP; - break; - } - if (! capable(CAP_NET_ADMIN)) { err = -EPERM; break; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Wed Feb 23 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:14:06 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4DXtN006435 for ; Wed, 23 Feb 2005 20:13:33 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id CBDF367A82; Thu, 24 Feb 2005 15:13:20 +1100 (EST) Date: Thu, 24 Feb 2005 15:02:58 +1100 From: David Gibson To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [11/14] Orinoco driver updates - delay Tx wake Message-ID: <20050224040258.GM32001@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> <20050224040228.GL32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040228.GL32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1299 Lines: 44 Delay netif_wake_queue() until the packet has actually been transmitted, rather than just when the firmware has copied it into its internal buffers. This seems to prevent problems on some Intersil firmware versions (I suspect the problems were caused by the firmware's buffers filling up). Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-18 12:48:30.523655896 +1100 +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-18 12:58:09.407652152 +1100 @@ -901,8 +901,6 @@ printk(KERN_WARNING "%s: Allocate event on unexpected fid (%04X)\n", dev->name, fid); return; - } else { - netif_wake_queue(dev); } hermes_write_regn(hw, ALLOCFID, DUMMY_FID); @@ -915,6 +913,8 @@ stats->tx_packets++; + netif_wake_queue(dev); + hermes_write_regn(hw, TXCOMPLFID, DUMMY_FID); } @@ -941,6 +941,7 @@ stats->tx_errors++; + netif_wake_queue(dev); hermes_write_regn(hw, TXCOMPLFID, DUMMY_FID); } -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From davem@davemloft.net Wed Feb 23 20:18:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:18:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4Il0I008870 for ; Wed, 23 Feb 2005 20:18:47 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D4ARa-0001T2-00; Wed, 23 Feb 2005 20:17:42 -0800 Date: Wed, 23 Feb 2005 20:17:41 -0800 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, AndyLiebman@aol.com, terryg@axian.com, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: Frequent Oops on Shutdown 2.6.10 Message-Id: <20050223201741.4e072bfc.davem@davemloft.net> In-Reply-To: <20050223224827.GA7418@gondor.apana.org.au> References: <20050222101526.GA5814@gondor.apana.org.au> <20050223.183555.80618945.yoshfuji@linux-ipv6.org> <20050223095144.GB16820@gondor.apana.org.au> <20050224.014148.47626020.yoshfuji@linux-ipv6.org> <20050223224827.GA7418@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 396 Lines: 14 On Thu, 24 Feb 2005 09:48:27 +1100 Herbert Xu wrote: > On Thu, Feb 24, 2005 at 01:41:48AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > Here's the (hopefuly) final one. > > Looks good to me. > > > Signed-off-by: Hideaki YOSHIFUJI > > Signed-off-by: Herbert Xu Applied to 2.6.11, thanks everyone. From davem@davemloft.net Wed Feb 23 20:31:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:31:55 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4Vnv8019257 for ; Wed, 23 Feb 2005 20:31:49 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D4Af7-0001Yb-00; Wed, 23 Feb 2005 20:31:41 -0800 Date: Wed, 23 Feb 2005 20:31:40 -0800 From: "David S. Miller" To: Robert Olsson Cc: rddunlap@osdl.org, Robert.Olsson@data.slu.se, romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: [PATCH] pktgen: reduce stack usage Message-Id: <20050223203140.4bc3994a.davem@davemloft.net> In-Reply-To: <16923.21163.112945.608974@robur.slu.se> References: <20050218134219.3f079110.rddunlap@osdl.org> <20050218221121.GA22845@electric-eye.fr.zoreil.com> <42166E3F.2050304@osdl.org> <16921.60572.951532.31861@robur.slu.se> <421A0880.5070205@osdl.org> <16923.21163.112945.608974@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 296 Lines: 13 On Tue, 22 Feb 2005 16:41:31 +0100 Robert Olsson wrote: > Randy.Dunlap writes: > > > Here is version with just one buffer. > > > > Yep, even better: few changes + using sizeof. > > Hello. > > OK! Then we ask DaveM to apply the patch. Applied, thanks guys. From jgarzik@pobox.com Wed Feb 23 20:35:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:35:37 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4ZTSD019797 for ; Wed, 23 Feb 2005 20:35:29 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4Aik-0007YV-My; Thu, 24 Feb 2005 04:35:26 +0000 Message-ID: <421D5979.5080600@pobox.com> Date: Wed, 23 Feb 2005 23:35:05 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [6/14] Orinoco driver updates - cleanup PCI initialization References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> In-Reply-To: <20050224035957.GH32001@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2029 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: 101 Lines: 7 FYI, pci_set_drvdata() needs to be one of the last functions called during PCI ->probe(). Jeff From jgarzik@pobox.com Wed Feb 23 20:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:35:56 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4ZnbD019920 for ; Wed, 23 Feb 2005 20:35:50 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4Aj7-0007aO-04; Thu, 24 Feb 2005 04:35:49 +0000 Message-ID: <421D5997.5030002@pobox.com> Date: Wed, 23 Feb 2005 23:35:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [7/14] Orinoco driver updates - use modern module_parm() References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> In-Reply-To: <20050224040024.GI32001@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2030 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: 898 Lines: 26 David Gibson wrote: > Add descrptions to module parameters in the orinoco driver, and also > add permissions to allow them to be exported in sysfs. > > Signed-off-by: David Gibson > > Index: working-2.6/drivers/net/wireless/orinoco.c > =================================================================== > --- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-10 13:19:14.000000000 +1100 > +++ working-2.6/drivers/net/wireless/orinoco.c 2005-02-10 13:24:03.000000000 +1100 > @@ -461,12 +461,14 @@ > /* Level of debugging. Used in the macros in orinoco.h */ > #ifdef ORINOCO_DEBUG > int orinoco_debug = ORINOCO_DEBUG; > -module_param(orinoco_debug, int, 0); > +module_param(orinoco_debug, int, 0644); > +MODULE_PARM_DESC(orinoco_debug, "Debug level"); > EXPORT_SYMBOL(orinoco_debug); > #endif eventually it would be nice to support netif_msg_* Jeff From jgarzik@pobox.com Wed Feb 23 20:44:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 20:44:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O4iTQv020983 for ; Wed, 23 Feb 2005 20:44:30 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4ArS-0007hY-MG; Thu, 24 Feb 2005 04:44:26 +0000 Message-ID: <421D5B9C.6020209@pobox.com> Date: Wed, 23 Feb 2005 23:44:12 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [14/14] Orinoco driver updates - update version and changelog References: <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224040153.GK32001@localhost.localdomain> <20050224040228.GL32001@localhost.localdomain> <20050224040258.GM32001@localhost.localdomain> <20050224040319.GN32001@localhost.localdomain> <20050224040409.GO32001@localhost.localdomain> <20050224040515.GP32001@localhost.localdomain> In-Reply-To: <20050224040515.GP32001@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2031 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: 191 Lines: 9 applied patches 1-14 to netdev-2.6. We'll let it sit there for a bit, for testing and such. (netdev-2.6 gets auto-propagated to -mm) Thanks for your patience and perserverance. Jeff From jgarzik@pobox.com Wed Feb 23 21:02:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 21:02:43 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O52a29021952 for ; Wed, 23 Feb 2005 21:02:36 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4B8w-00080W-14; Thu, 24 Feb 2005 05:02:30 +0000 Message-ID: <421D5FD3.9020107@pobox.com> Date: Thu, 24 Feb 2005 00:02:11 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Farnsworth CC: netdev@oss.sgi.com, Ralf Baechle , Manish Lachwani , Brian Waite , "Steven J. Hill" , Benjamin Herrenschmidt Subject: Re: [PATCH] mv643xx enet update + ethtool support References: <20050217224239.GA16609@xyzzy> In-Reply-To: <20050217224239.GA16609@xyzzy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2032 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: 1683 Lines: 54 Dale Farnsworth wrote: > Here is an update to mv643xx ethernet support. > There are several small bugfixes. The two larger issues are > the beginning of ethtool support and the fact that I've disabled > hardware tcp/udp checksum generation. It now looks like there's > a hardware bug with the checksums, but I'm still characterizing it. > > ChangeSets before 1.2065 are already in -netdev. > I've included a cumulative patch of the new changesets below. > > Thanks, > -Dale Farnsworth > > Please do a > > bk pull bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet Pulled. Two comments: 1) Your descriptions MUST follow the "one line summary" format found in other changesets. When Linus, myself and others use automated tools to summarize a large number of changesets, the first line from each changeset description is used. You should include an identifier indicating which area of the kernel tree you are modifying ("mv643xx" in this case), and a one-line summary of the changeset. For example, when I check in net driver changesets, they look like [netdrvr 8139too] fix bugs, whitespace change * fix RX error overflow case * Update PCI initialization code to better use PCI API * trim trailing whitespace (chomp) For now, I have (with great patience) hand-edited all 30+ changesets to fix this up. See rule #1 of http://linux.yyz.us/patch-format.html. Even though that URL applies to patches, not BitKeeper, the one-line-summary and $subsystem portions are applicable to you. > +void mv643xx_set_ethtool_ops(struct net_device *netdev) > +{ > + SET_ETHTOOL_OPS(netdev, &mv643xx_ethtool_ops); > +} > + 2) This function should not exist. Jeff From jgarzik@pobox.com Wed Feb 23 21:41:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 21:41:55 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O5fpe9023152 for ; Wed, 23 Feb 2005 21:41:51 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4Bkz-0000CK-CM; Thu, 24 Feb 2005 05:41:49 +0000 Message-ID: <421D6910.6030700@pobox.com> Date: Thu, 24 Feb 2005 00:41:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Malli Chilakala CC: netdev Subject: Re: [PATCH net-drivers-2.4 10/10] e1000: Driver version white space, device id, comments & other References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2033 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: 23 Lines: 2 applied 1-10 to 2.4.x From jgarzik@pobox.com Wed Feb 23 22:16:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 22:16:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O6GhNM024462 for ; Wed, 23 Feb 2005 22:16:44 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4CIk-00013s-If; Thu, 24 Feb 2005 06:16:42 +0000 Message-ID: <421D713C.3040605@pobox.com> Date: Thu, 24 Feb 2005 01:16:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, Stephen Hemminger , Randy Dunlap , James Ketrenos Subject: Re: [patch 2.6.11-rc4-netdev1 2/4] ieee80211: removal of unneeded checks References: <420FBAD3.3020909@pobox.com> <20050213232421.GB2060@electric-eye.fr.zoreil.com> <20050213232559.GA2898@electric-eye.fr.zoreil.com> In-Reply-To: <20050213232559.GA2898@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2034 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 105 Lines: 8 applied patches 1, 3, and 4. I thought this patch (#2) needed splitting up, but otherwise OK. Jeff From mgalgoci@parcelfarce.linux.theplanet.co.uk Wed Feb 23 22:31:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 22:31:44 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O6VcW5025395 for ; Wed, 23 Feb 2005 22:31:38 -0800 Received: from [127.0.0.1] (helo=localhost) by parcelfarce.linux.theplanet.co.uk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4CXB-0001d8-DT; Thu, 24 Feb 2005 06:31:37 +0000 Date: Thu, 24 Feb 2005 06:31:37 +0000 (GMT) From: Matthew J Galgoci To: netdev@oss.sgi.com cc: jgarzik@pobox.com Subject: wireless-2.6 cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mgalgoci@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: netdev Content-Length: 14443 Lines: 396 Cleanup drivers/net/wireless/* and remove unnecessary ieee802_11.h b/drivers/net/wireless/atmel.c | 62 +++++++++++++++--------------- b/drivers/net/wireless/orinoco.c | 11 ++--- b/drivers/net/wireless/wl3501.h | 4 - drivers/net/wireless/ieee802_11.h | 78 -------------------------------------- 4 files changed, 39 insertions(+), 116 deletions(-) diff -Nru a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c --- a/drivers/net/wireless/atmel.c 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/atmel.c 2005-02-13 19:18:22 -05:00 @@ -68,7 +68,7 @@ #include #include #include -#include "ieee802_11.h" +#include #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -600,12 +600,12 @@ static void atmel_wmem32(struct atmel_private *priv, u16 pos, u32 data); static void atmel_command_irq(struct atmel_private *priv); static int atmel_validate_channel(struct atmel_private *priv, int channel); -static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u16 frame_len, u8 rssi); static void atmel_management_timer(u_long a); static void atmel_send_command(struct atmel_private *priv, int command, void *cmd, int cmd_size); static int atmel_send_command_wait(struct atmel_private *priv, int command, void *cmd, int cmd_size); -static void atmel_transmit_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_transmit_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u8 *body, int body_len); static u8 atmel_get_mib8(struct atmel_private *priv, u8 type, u8 index); @@ -809,7 +809,7 @@ static int start_tx (struct sk_buff *skb, struct net_device *dev) { struct atmel_private *priv = netdev_priv(dev); - struct ieee802_11_hdr header; + struct ieee80211_hdr header; unsigned long flags; u16 buff, frame_ctl, len = (ETH_ZLEN < skb->len) ? skb->len : ETH_ZLEN; u8 SNAP_RFC1024[6] = {0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00}; @@ -845,17 +845,17 @@ return 1; } - frame_ctl = IEEE802_11_FTYPE_DATA; + frame_ctl = IEEE80211_FTYPE_DATA; header.duration_id = 0; header.seq_ctl = 0; if (priv->wep_is_on) - frame_ctl |= IEEE802_11_FCTL_WEP; + frame_ctl |= IEEE80211_FCTL_WEP; if (priv->operating_mode == IW_MODE_ADHOC) { memcpy(&header.addr1, skb->data, 6); memcpy(&header.addr2, dev->dev_addr, 6); memcpy(&header.addr3, priv->BSSID, 6); } else { - frame_ctl |= IEEE802_11_FCTL_TODS; + frame_ctl |= IEEE80211_FCTL_TODS; memcpy(&header.addr1, priv->CurrentBSSID, 6); memcpy(&header.addr2, dev->dev_addr, 6); memcpy(&header.addr3, skb->data, 6); @@ -884,7 +884,7 @@ } static void atmel_transmit_management_frame(struct atmel_private *priv, - struct ieee802_11_hdr *header, + struct ieee80211_hdr *header, u8 *body, int body_len) { u16 buff; @@ -899,7 +899,7 @@ tx_update_descriptor(priv, header->addr1[0] & 0x01, len, buff, TX_PACKET_TYPE_MGMT); } -static void fast_rx_path(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void fast_rx_path(struct atmel_private *priv, struct ieee80211_hdr *header, u16 msdu_size, u16 rx_packet_loc, u32 crc) { /* fast path: unfragmented packet copy directly into skbuf */ @@ -937,7 +937,7 @@ } memcpy(skbp, header->addr1, 6); /* destination address */ - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) memcpy(&skbp[6], header->addr3, 6); else memcpy(&skbp[6], header->addr2, 6); /* source address */ @@ -972,14 +972,14 @@ return (crc ^ 0xffffffff) == netcrc; } -static void frag_rx_path(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void frag_rx_path(struct atmel_private *priv, struct ieee80211_hdr *header, u16 msdu_size, u16 rx_packet_loc, u32 crc, u16 seq_no, u8 frag_no, int more_frags) { u8 mac4[6]; u8 source[6]; struct sk_buff *skb; - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) memcpy(source, header->addr3, 6); else memcpy(source, header->addr2, 6); @@ -1064,7 +1064,7 @@ static void rx_done_irq(struct atmel_private *priv) { int i; - struct ieee802_11_hdr header; + struct ieee80211_hdr header; for (i = 0; atmel_rmem8(priv, atmel_rx(priv, RX_DESC_FLAGS_OFFSET, priv->rx_desc_head)) == RX_DESC_FLAG_VALID && @@ -1099,7 +1099,7 @@ /* probe for CRC use here if needed once five packets have arrived with the same crc status, we assume we know what's happening and stop probing */ if (priv->probe_crc) { - if (!priv->wep_is_on || !(frame_ctl & IEEE802_11_FCTL_WEP)) { + if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP)) { priv->do_rx_crc = probe_crc(priv, rx_packet_loc, msdu_size); } else { priv->do_rx_crc = probe_crc(priv, rx_packet_loc + 24, msdu_size - 24); @@ -1114,16 +1114,16 @@ } /* don't CRC header when WEP in use */ - if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE802_11_FCTL_WEP))) { + if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP))) { crc = crc32_le(0xffffffff, (unsigned char *)&header, 24); } msdu_size -= 24; /* header */ - if ((frame_ctl & IEEE802_11_FCTL_FTYPE) == IEEE802_11_FTYPE_DATA) { + if ((frame_ctl & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA) { - int more_fragments = frame_ctl & IEEE802_11_FCTL_MOREFRAGS; - u8 packet_fragment_no = seq_control & IEEE802_11_SCTL_FRAG; - u16 packet_sequence_no = (seq_control & IEEE802_11_SCTL_SEQ) >> 4; + int more_fragments = frame_ctl & IEEE80211_FCTL_MOREFRAGS; + u8 packet_fragment_no = seq_control & IEEE80211_SCTL_FRAG; + u16 packet_sequence_no = (seq_control & IEEE80211_SCTL_SEQ) >> 4; if (!more_fragments && packet_fragment_no == 0 ) { fast_rx_path(priv, &header, msdu_size, rx_packet_loc, crc); @@ -1133,7 +1133,7 @@ } } - if ((frame_ctl & IEEE802_11_FCTL_FTYPE) == IEEE802_11_FTYPE_MGMT) { + if ((frame_ctl & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT) { /* copy rest of packet into buffer */ atmel_copy_to_host(priv->dev, (unsigned char *)&priv->rx_buf, rx_packet_loc + 24, msdu_size); @@ -2637,10 +2637,10 @@ static void send_authentication_request(struct atmel_private *priv, u8 *challenge, int challenge_len) { - struct ieee802_11_hdr header; + struct ieee80211_hdr header; struct auth_body auth; - header.frame_ctl = cpu_to_le16(IEEE802_11_FTYPE_MGMT | IEEE802_11_STYPE_AUTH); + header.frame_ctl = cpu_to_le16(IEEE80211_FTYPE_MGMT | IEEE80211_STYPE_AUTH); header.duration_id = cpu_to_le16(0x8000); header.seq_ctl = 0; memcpy(header.addr1, priv->CurrentBSSID, 6); @@ -2651,7 +2651,7 @@ auth.alg = cpu_to_le16(C80211_MGMT_AAN_SHAREDKEY); /* no WEP for authentication frames with TrSeqNo 1 */ if (priv->CurrentAuthentTransactionSeqNum != 1) - header.frame_ctl |= cpu_to_le16(IEEE802_11_FCTL_WEP); + header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_WEP); } else { auth.alg = cpu_to_le16(C80211_MGMT_AAN_OPENSYSTEM); } @@ -2675,7 +2675,7 @@ { u8 *ssid_el_p; int bodysize; - struct ieee802_11_hdr header; + struct ieee80211_hdr header; struct ass_req_format { u16 capability; u16 listen_interval; @@ -2688,8 +2688,8 @@ u8 rates[4]; } body; - header.frame_ctl = cpu_to_le16(IEEE802_11_FTYPE_MGMT | - (is_reassoc ? IEEE802_11_STYPE_REASSOC_REQ : IEEE802_11_STYPE_ASSOC_REQ)); + header.frame_ctl = cpu_to_le16(IEEE80211_FTYPE_MGMT | + (is_reassoc ? IEEE80211_STYPE_REASSOC_REQ : IEEE80211_STYPE_ASSOC_REQ)); header.duration_id = cpu_to_le16(0x8000); header.seq_ctl = 0; @@ -2725,9 +2725,9 @@ atmel_transmit_management_frame(priv, &header, (void *)&body, bodysize); } -static int is_frame_from_current_bss(struct atmel_private *priv, struct ieee802_11_hdr *header) +static int is_frame_from_current_bss(struct atmel_private *priv, struct ieee80211_hdr *header) { - if (le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_FROMDS) + if (le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_FROMDS) return memcmp(header->addr3, priv->CurrentBSSID, 6) == 0; else return memcmp(header->addr2, priv->CurrentBSSID, 6) == 0; @@ -2775,7 +2775,7 @@ } -static void store_bss_info(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void store_bss_info(struct atmel_private *priv, struct ieee80211_hdr *header, u16 capability, u16 beacon_period, u8 channel, u8 rssi, u8 ssid_len, u8 *ssid, int is_beacon) { @@ -3050,12 +3050,12 @@ } /* deals with incoming managment frames. */ -static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, +static void atmel_management_frame(struct atmel_private *priv, struct ieee80211_hdr *header, u16 frame_len, u8 rssi) { u16 subtype; - switch (subtype = le16_to_cpu(header->frame_ctl) & IEEE802_11_FCTL_STYPE) { + switch (subtype = le16_to_cpu(header->frame_ctl) & IEEE80211_FCTL_STYPE) { case C80211_SUBTYPE_MGMT_BEACON : case C80211_SUBTYPE_MGMT_ProbeResponse: diff -Nru a/drivers/net/wireless/ieee802_11.h b/drivers/net/wireless/ieee802_11.h --- a/drivers/net/wireless/ieee802_11.h 2005-02-13 19:18:22 -05:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,78 +0,0 @@ -#ifndef _IEEE802_11_H -#define _IEEE802_11_H - -#define IEEE802_11_DATA_LEN 2304 -/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section - 6.2.1.1.2. - - The figure in section 7.1.2 suggests a body size of up to 2312 - bytes is allowed, which is a bit confusing, I suspect this - represents the 2304 bytes of real data, plus a possible 8 bytes of - WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ - - -#define IEEE802_11_HLEN 30 -#define IEEE802_11_FRAME_LEN (IEEE802_11_DATA_LEN + IEEE802_11_HLEN) - -struct ieee802_11_hdr { - u16 frame_ctl; - u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; - u16 seq_ctl; - u8 addr4[ETH_ALEN]; -} __attribute__ ((packed)); - -/* Frame control field constants */ -#define IEEE802_11_FCTL_VERS 0x0002 -#define IEEE802_11_FCTL_FTYPE 0x000c -#define IEEE802_11_FCTL_STYPE 0x00f0 -#define IEEE802_11_FCTL_TODS 0x0100 -#define IEEE802_11_FCTL_FROMDS 0x0200 -#define IEEE802_11_FCTL_MOREFRAGS 0x0400 -#define IEEE802_11_FCTL_RETRY 0x0800 -#define IEEE802_11_FCTL_PM 0x1000 -#define IEEE802_11_FCTL_MOREDATA 0x2000 -#define IEEE802_11_FCTL_WEP 0x4000 -#define IEEE802_11_FCTL_ORDER 0x8000 - -#define IEEE802_11_FTYPE_MGMT 0x0000 -#define IEEE802_11_FTYPE_CTL 0x0004 -#define IEEE802_11_FTYPE_DATA 0x0008 - -/* management */ -#define IEEE802_11_STYPE_ASSOC_REQ 0x0000 -#define IEEE802_11_STYPE_ASSOC_RESP 0x0010 -#define IEEE802_11_STYPE_REASSOC_REQ 0x0020 -#define IEEE802_11_STYPE_REASSOC_RESP 0x0030 -#define IEEE802_11_STYPE_PROBE_REQ 0x0040 -#define IEEE802_11_STYPE_PROBE_RESP 0x0050 -#define IEEE802_11_STYPE_BEACON 0x0080 -#define IEEE802_11_STYPE_ATIM 0x0090 -#define IEEE802_11_STYPE_DISASSOC 0x00A0 -#define IEEE802_11_STYPE_AUTH 0x00B0 -#define IEEE802_11_STYPE_DEAUTH 0x00C0 - -/* control */ -#define IEEE802_11_STYPE_PSPOLL 0x00A0 -#define IEEE802_11_STYPE_RTS 0x00B0 -#define IEEE802_11_STYPE_CTS 0x00C0 -#define IEEE802_11_STYPE_ACK 0x00D0 -#define IEEE802_11_STYPE_CFEND 0x00E0 -#define IEEE802_11_STYPE_CFENDACK 0x00F0 - -/* data */ -#define IEEE802_11_STYPE_DATA 0x0000 -#define IEEE802_11_STYPE_DATA_CFACK 0x0010 -#define IEEE802_11_STYPE_DATA_CFPOLL 0x0020 -#define IEEE802_11_STYPE_DATA_CFACKPOLL 0x0030 -#define IEEE802_11_STYPE_NULLFUNC 0x0040 -#define IEEE802_11_STYPE_CFACK 0x0050 -#define IEEE802_11_STYPE_CFPOLL 0x0060 -#define IEEE802_11_STYPE_CFACKPOLL 0x0070 - -#define IEEE802_11_SCTL_FRAG 0x000F -#define IEEE802_11_SCTL_SEQ 0xFFF0 - -#endif /* _IEEE802_11_H */ diff -Nru a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c --- a/drivers/net/wireless/orinoco.c 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/orinoco.c 2005-02-13 19:18:22 -05:00 @@ -441,6 +441,8 @@ #include #include +#include + #include #include #include @@ -448,7 +450,6 @@ #include "hermes.h" #include "hermes_rid.h" #include "orinoco.h" -#include "ieee802_11.h" /********************************************************************/ /* Module information */ @@ -484,7 +485,7 @@ /********************************************************************/ #define ORINOCO_MIN_MTU 256 -#define ORINOCO_MAX_MTU (IEEE802_11_DATA_LEN - ENCAPS_OVERHEAD) +#define ORINOCO_MAX_MTU (IEEE80211_DATA_LEN - ENCAPS_OVERHEAD) #define SYMBOL_MAX_VER_LEN (14) #define USER_BAP 0 @@ -735,7 +736,7 @@ if ( (new_mtu < ORINOCO_MIN_MTU) || (new_mtu > ORINOCO_MAX_MTU) ) return -EINVAL; - if ( (new_mtu + ENCAPS_OVERHEAD + IEEE802_11_HLEN) > + if ( (new_mtu + ENCAPS_OVERHEAD + IEEE80211_HLEN) > (priv->nicbuf_size - ETH_HLEN) ) return -EINVAL; @@ -1074,7 +1075,7 @@ stats->rx_dropped++; goto drop; } - if (length > IEEE802_11_DATA_LEN) { + if (length > IEEE80211_DATA_LEN) { printk(KERN_WARNING "%s: Oversized frame received (%d bytes)\n", dev->name, length); stats->rx_length_errors++; @@ -2178,7 +2179,7 @@ /* No need to lock, the hw_unavailable flag is already set in * alloc_orinocodev() */ - priv->nicbuf_size = IEEE802_11_FRAME_LEN + ETH_HLEN; + priv->nicbuf_size = IEEE80211_FRAME_LEN + ETH_HLEN; /* Initialize the firmware */ err = hermes_init(hw); diff -Nru a/drivers/net/wireless/wl3501.h b/drivers/net/wireless/wl3501.h --- a/drivers/net/wireless/wl3501.h 2005-02-13 19:18:22 -05:00 +++ b/drivers/net/wireless/wl3501.h 2005-02-13 19:18:22 -05:00 @@ -2,7 +2,7 @@ #define __WL3501_H__ #include -#include "ieee802_11.h" +#include /* define for WLA 2.0 */ #define WL3501_BLKSZ 256 @@ -548,7 +548,7 @@ struct wl3501_80211_tx_hdr { struct wl3501_80211_tx_plcp_hdr pclp_hdr; - struct ieee802_11_hdr mac_hdr; + struct ieee80211_hdr mac_hdr; } __attribute__ ((packed)); /* From brodo@linta.de Wed Feb 23 22:55:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 22:55:39 -0800 (PST) Received: from linta.de (isilmar.linta.de [213.239.214.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O6tXVa026684 for ; Wed, 23 Feb 2005 22:55:34 -0800 Received: (qmail 9353 invoked by uid 1000); 24 Feb 2005 06:55:27 -0000 Date: Thu, 24 Feb 2005 07:55:27 +0100 From: Dominik Brodowski To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [8/14] Orinoco driver updates - PCMCIA initialization cleanups Message-ID: <20050224065527.GA8931@isilmar.linta.de> Mail-Followup-To: Dominik Brodowski , Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224040052.GJ32001@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@dominikbrodowski.net Precedence: bulk X-list: netdev Content-Length: 195 Lines: 9 > @@ -184,6 +186,7 @@ > dev_list = link; > > client_reg.dev_info = &dev_info; > + client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; That's not needed any longer for 2.6. Dominik From jgarzik@pobox.com Wed Feb 23 23:28:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 23:28:23 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O7SGhx028420 for ; Wed, 23 Feb 2005 23:28:16 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4DPy-0002vW-Jq; Thu, 24 Feb 2005 07:28:15 +0000 Message-ID: <421D81FF.5060200@pobox.com> Date: Thu, 24 Feb 2005 02:27:59 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel Subject: netdev-2.6, wireless-2.6 queues updated Content-Type: multipart/mixed; boundary="------------070108020601070901050105" X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2037 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: 23713 Lines: 499 This is a multi-part message in MIME format. --------------070108020601070901050105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See attached changelog. I'm too slack to post a patch tonight. --------------070108020601070901050105 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/netdev-2.6 This will update the following files: drivers/net/bagetlance.c | 1368 ----- include/linux/dp83840.h | 41 Documentation/networking/bonding.txt | 2101 +++++---- Documentation/networking/e100.txt | 3 Documentation/networking/ixgb.txt | 9 MAINTAINERS | 7 arch/arm/mach-pxa/lubbock.c | 2 arch/arm/mach-sa1100/neponset.c | 2 drivers/net/3c503.c | 67 drivers/net/3c509.c | 4 drivers/net/3c515.c | 32 drivers/net/3c527.c | 2 drivers/net/3c59x.c | 2 drivers/net/8139cp.c | 100 drivers/net/8139too.c | 293 - drivers/net/Kconfig | 59 drivers/net/Makefile | 2 drivers/net/Space.c | 11 drivers/net/amd8111e.c | 6 drivers/net/arcnet/arc-rawmode.c | 4 drivers/net/arcnet/arc-rimi.c | 14 drivers/net/arcnet/arcnet.c | 30 drivers/net/arcnet/com20020.c | 6 drivers/net/arcnet/com90io.c | 4 drivers/net/arcnet/com90xx.c | 8 drivers/net/arcnet/rfc1051.c | 8 drivers/net/arcnet/rfc1201.c | 12 drivers/net/au1000_eth.c | 1361 ++++- drivers/net/au1000_eth.h | 55 drivers/net/b44.c | 2 drivers/net/b44.h | 14 drivers/net/bonding/bond_3ad.c | 2 drivers/net/bonding/bond_3ad.h | 1 drivers/net/bonding/bond_alb.c | 12 drivers/net/bonding/bond_main.c | 35 drivers/net/cs89x0.c | 4 drivers/net/depca.c | 4 drivers/net/dgrs.c | 6 drivers/net/e100.c | 4 drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 drivers/net/e1000/e1000_hw.c | 86 drivers/net/e1000/e1000_hw.h | 11 drivers/net/e1000/e1000_main.c | 249 - drivers/net/eepro100.c | 17 drivers/net/epic100.c | 2 drivers/net/es3210.c | 32 drivers/net/ethertap.c | 4 drivers/net/ewrk3.c | 87 drivers/net/fealnx.c | 275 - drivers/net/hamradio/baycom_epp.c | 53 drivers/net/hamradio/baycom_par.c | 8 drivers/net/hamradio/baycom_ser_fdx.c | 7 drivers/net/hamradio/baycom_ser_hdx.c | 7 drivers/net/hamradio/bpqether.c | 17 drivers/net/hamradio/dmascc.c | 2073 ++++---- drivers/net/hamradio/hdlcdrv.c | 48 drivers/net/hamradio/mkiss.c | 12 drivers/net/hamradio/yam.c | 38 drivers/net/ibm_emac/ibm_emac.h | 4 drivers/net/ibmlana.c | 99 drivers/net/ibmlana.h | 1 drivers/net/ioc3-eth.c | 83 drivers/net/irda/act200l-sir.c | 3 drivers/net/irda/donauboe.c | 2 drivers/net/irda/irtty-sir.c | 4 drivers/net/irda/ma600-sir.c | 12 drivers/net/irda/sir_dev.c | 4 drivers/net/irda/tekram-sir.c | 3 drivers/net/ixgb/ixgb.h | 3 drivers/net/ixgb/ixgb_ee.c | 16 drivers/net/ixgb/ixgb_ee.h | 3 drivers/net/ixgb/ixgb_ethtool.c | 5 drivers/net/ixgb/ixgb_hw.c | 2 drivers/net/ixgb/ixgb_hw.h | 2 drivers/net/ixgb/ixgb_ids.h | 2 drivers/net/ixgb/ixgb_main.c | 73 drivers/net/ixgb/ixgb_osdep.h | 2 drivers/net/ixgb/ixgb_param.c | 2 drivers/net/jazzsonic.c | 217 drivers/net/loopback.c | 2 drivers/net/lp486e.c | 8 drivers/net/meth.c | 275 - drivers/net/meth.h | 2 drivers/net/mv643xx_eth.c | 2690 ++++++----- drivers/net/mv643xx_eth.h | 641 +- drivers/net/natsemi.c | 13 drivers/net/ne2k-pci.c | 4 drivers/net/ni65.c | 3 drivers/net/ns83820.c | 3 drivers/net/pcmcia/ibmtr_cs.c | 7 drivers/net/pcmcia/xirc2ps_cs.c | 23 drivers/net/pcnet32.c | 47 drivers/net/ppp_deflate.c | 4 drivers/net/ppp_generic.c | 2 drivers/net/pppoe.c | 2 drivers/net/s2io.c | 173 drivers/net/s2io.h | 8 drivers/net/sb1000.c | 8 drivers/net/sb1250-mac.c | 109 drivers/net/sgiseeq.c | 70 drivers/net/shaper.c | 2 drivers/net/sis900.c | 197 drivers/net/sk98lin/skge.c | 2 drivers/net/sk_mca.c | 126 drivers/net/sk_mca.h | 19 drivers/net/skge.c | 3334 ++++++++++++++ drivers/net/skge.h | 3005 ++++++++++++ drivers/net/slhc.c | 27 drivers/net/smc-mca.c | 37 drivers/net/smc-ultra.c | 34 drivers/net/smc-ultra32.c | 30 drivers/net/smc91x.c | 275 - drivers/net/smc91x.h | 79 drivers/net/sonic.c | 4 drivers/net/sundance.c | 7 drivers/net/sungem.c | 2 drivers/net/tg3.c | 4 drivers/net/tg3.h | 14 drivers/net/tokenring/ibmtr.c | 158 drivers/net/tulip/interrupt.c | 2 drivers/net/tulip/tulip_core.c | 2 drivers/net/tun.c | 4 drivers/net/typhoon-firmware.h | 5568 ++++++++++-------------- drivers/net/typhoon.c | 254 - drivers/net/via-rhine.c | 4 drivers/net/via-velocity.c | 6 drivers/net/wan/cosa.c | 7 drivers/net/wd.c | 36 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/airo.c | 25 drivers/net/wireless/airport.c | 22 drivers/net/wireless/arlan.h | 4 drivers/net/wireless/atmel_cs.c | 3 drivers/net/wireless/hermes.c | 72 drivers/net/wireless/hermes.h | 64 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1080 ++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 ++ drivers/net/wireless/hostap/hostap_ap.c | 3259 ++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 556 ++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 ++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 +++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 785 +++ drivers/net/wireless/hostap/hostap_download.c | 761 +++ drivers/net/wireless/hostap/hostap_hw.c | 3607 +++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 469 ++ drivers/net/wireless/hostap/hostap_ioctl.c | 3624 +++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 452 + drivers/net/wireless/hostap/hostap_plx.c | 611 ++ drivers/net/wireless/hostap/hostap_proc.c | 466 ++ drivers/net/wireless/hostap/hostap_wlan.h | 1071 ++++ drivers/net/wireless/orinoco.c | 419 + drivers/net/wireless/orinoco.h | 37 drivers/net/wireless/orinoco_cs.c | 50 drivers/net/wireless/orinoco_pci.c | 123 drivers/net/wireless/orinoco_plx.c | 234 - drivers/net/wireless/orinoco_tmd.c | 149 drivers/net/wireless/prism54/isl_ioctl.c | 2 drivers/net/wireless/ray_cs.c | 5 drivers/net/wireless/strip.c | 16 include/linux/ibmtr.h | 15 include/linux/mii.h | 4 include/linux/mv643xx.h | 448 + include/linux/netdevice.h | 2 include/linux/pci_ids.h | 8 include/net/ieee80211.h | 887 +++ include/net/ieee80211_crypt.h | 86 include/net/slhc_vj.h | 3 net/Kconfig | 2 net/Makefile | 1 net/core/dev.c | 28 net/ieee80211/Kconfig | 71 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 259 + net/ieee80211/ieee80211_crypt_ccmp.c | 470 ++ net/ieee80211/ieee80211_crypt_tkip.c | 708 +++ net/ieee80211/ieee80211_crypt_wep.c | 272 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++ net/ieee80211/ieee80211_tx.c | 448 + net/ieee80211/ieee80211_wx.c | 471 ++ 192 files changed, 43702 insertions(+), 10589 deletions(-) through these ChangeSets: : o sundance: attempt to address high irqs due to TX overflow : o Big rename o Rename MV_READ => mv_read and MV_WRITE => mv_write o Additional whitespace cleanups, mostly changing spaces to tabs in comments o Run mv643xx_eth.[ch] through scripts/Lindent o Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. o This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case o Add support for PHYs/boards that don't support autonegotiation o With this patch, the driver now calls netif_carrier_off/netif_carrier_on o This patch cleans up the handling of receive skb sizing : o ieee80211 subsystem : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: use netif_poll_{enable|disable} o e1000: Robert Olsson's fix and refinement o ixgb: Driver version, white space, other stuff o ixgb: Invalidate software cache, when EEPROM write occurs o ixgb: Robert Olsson's fix and refinement to poll o ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq o ixgb: use netif_poll_{enable|disable} : o [netdrvr 8139cp] add PCI ID Adrian Bunk: o drivers/net/via-rhine.c: make a variable static const o drivers/net/sb1000.c: make some variables static o drivers/net/lp486e.c: make some code static o drivers/net/3c509.c: make 2 structs static o drivers/net/3c527.c: make a struct static o drivers/net/amd8111e.c: make 2 functions static o drivers/net/loopback.c: make a function static o drivers/net/ethertap.c: make 2 functions static o drivers/net/dgrs.c: make 3 functions static o drivers/net/depca.c: make 2 structs static o drivers/net/bonding/: make 3 functions static o drivers/net/s2io.c: cleanups o drivers/net/pppoe.c: make a struct static o drivers/net/ppp_deflate.c: make 2 structs static o drivers/net/via-velocity.c: make a function static o drivers/net/tun.c: make 2 functions static o drivers/net/tulip/interrupt.c: make a variable static o drivers/net/shaper.c: make a variable static o drivers/net/slhc.c: remove 2 functions o remove dp83840.h Alexander Viro: o hostap __user annotations o smc91x iomem annotations o 3c503 (iomem + isa-ectomy) o ibmlana part 2 (iomem annotations and isa-ectomy) o ibmlana part 1 (netdev_priv()) o sk_mca - iomem and isa-ectomy o sk_mca - netdev_priv() o ibmtr 2/2: ibmtr annotations - the rest o ibmtr 1/2: iomem annotations - trivial part o es3210 iomem annotions and isa-ectomy o ewrk3 iomem annotations + isa-ectomy o wd iomem annotations + isa-ectomy o smc-ultra32 iomem annotations + isa-ectomy o smc-ultra iomem annotations + isa-ectomy o smc-mca iomem annotations and isa-ectomy o fealnx iomem annotations, switch to io{read,write} o wireless iomem annotations and fixes, switch to io{read,write} Dale Farnsworth: o [netdrvr mv643xx] Remove call to msleep() while locks are held. We don't really need to wait for the link to come up. It was a workaround to avoid a transient error message, "Virtual device %s asks to queue packet!\n", in dev_queue_xmit() when called by ic_bootp_send_if(). This happens because right after opening the network device, there is a pending PHY status change interrupt causing the driver to call netif_stop_queue(). A half second later, the link comes up and all is well. We could have moved the call to msleep() to mv643xx_eth_open() to perpetuate the workaround, but I think it's best to remove it entirely. o [netdrvr mv643xx] Ensure that we only change the Port Serial Control Reg while the port is disabled. o [netdrvr mv643xx] Add ethtool support to the mv643xx ethernet driver o [netdrvr mv643xx] Enable the mv643xx ethernet support on platforms using the MV64360 chip o [netdrvr mv643xx] Disable tcp/udp checksum offload to hardware. It generally works, but the hardware appears to generate the wrong checksum if the hw checksum generation wasn't used in the previous packet sent. o [netdrvr mv643xx] We already set ETH_TX_ENABLE_INTERRUPT whenever we set ETH_TX_LAST_DESC o [netdrvr mv643xx] Update tx_bytes statistic when using hw tcp/udp checksum generation o [netdrvr mv643xx] Call netif_carrier_off when closing the driver o [netdrvr mv643xx] Trivial. Remove repeated comment o [netdrvr mv643xx] Clear transmit l4i_chk even when the hardware ignores it o [netdrvr mv643xx] Increment tx_ring_skbs before calling eth_port_send, since o [netdrvr mv643xx] Fix handling of unaligned tiny fragments not handled by hardware Check all fragments instead of just the last. o [netdrvr mv643xx] Fix a few places I missed in the previous rename patch o This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. o This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. o This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: o This patch adds device driver model support to the mv643xx_eth driver o This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. o This patch fixes the code that enables hardware checksum generation o This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. o This patch removes code that is redundant or useless Daniele Venzano: o sis900: chiprev i/o cleanups o sis900: debugging output update o sis900 printk audit o sis900: version bump; remove broken URL o sis900: add infrastructure needed for standard netif messages David Dillow: o Bump version and release date o Version 03.001.008 of the Typhoon firmware, courtesy of 3Com o Fixup the version reporting to match 3Com o Use module_param() and add descriptions o Teach typhoon to use port IO on machines that need it. It will attempt to use MMIO, but if that fails (or the user asks), it will fallback to port IO. o Enable bus mastering before saving our state, or we'll only be able to load the modules one time. David Gibson: o Orinoco driver updates - update version and changelog o Orinoco driver updates - update firmware detection o Orinoco driver updates - WEP updates o Orinoco driver updates - delay Tx wake o Orinoco driver updates - prohibit IBSS with no ESSID o Orinoco driver updates - update is_ethersnap() o Orinoco driver updates - PCMCIA initialization cleanups o Orinoco driver updates - use modern module_parm() o Orinoco driver updates - cleanup PCI initialization o Orinoco driver updates - cleanup low-level code o Orinoco driver updates - add free_orinocodev() o Orinoco driver updates - use mdelay()/ssleep() more o Orinoco driver updates - update printk()s o Orinoco driver updates - use netif_carrier_*() David T. Hollis: o Move MII-related constants from b44/tg3 drivers to linux/mii.h Domen Puncer: o net/ewrk3: replace schedule_timeout() with msleep_interruptible() o net/tekram-sir: replace schedule_timeout() with msleep() o net/ns83820: replace schedule_timeout() with msleep() o net/ni65: replace schedule_timeout() with msleep() o net/sir_dev: replace schedule_timeout() with msleep() o net/xirc2ps_cs: replace Wait() with msleep() o net/ma600-sir: replace schedule_timeout() with msleep() o net/irtty-sir: replace schedule_timeout() with msleep() o net/act2001-sir: replace schedule_timeout() with msleep() o arcnet: remove casts Don Fry: o pcnet32: 79c976 with fiber optic fix Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o ieee80211: offset_in_page() removal o ieee80211: C99 initialization for eap_types o ieee80211: failure of ieee80211_crypto_init() o strip: use of netdev_priv o 8139cp: SG support fixes Ganesh Venkatesan: o ixgb: Documentation/networking/ixgb.txt Ian Campbell: o use datacs in smc91x driver o smc91x: power down PHY on suspend Jay Vosburgh: o bonding: Update/rewrite bonding.txt o bonding: Update kconfig description o bonding: change misleading warning o bonding: use wrappers to change mtu and MAC o net/core: move set MAC into separate function Jeff Garzik: o [wireless hostap] update for new pci_save_state() o [netdrvr 8139cp] TSO support John W. Linville: o sk98lin: add MODULE_DEVICE_TABLE entry Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver JustMan: o atmel_cs: Add support LG LW2100N WLAN PCMCIA card Matt Porter: o Add PPC440SP support to IBM EMAC driver Nicolas Pitre: o smc91x: allow RX of VLAN packets Nishanth Aravamudan: o net/s2io: replace schedule_timeout() with msleep() o net/cosa: replace schedule_timeout() with msleep() o net/airo: replace schedule_timeout() with msleep()/ssleep() o net/cs89x0: replace schedule_timeout() with msleep() Olaf Kirch: o natsemi: long cable, short cable Paul Mackerras: o remove bogus exports in ppp Pavel Machek: o Fix u32 vs. pm_message_t in network device drivers o eepro100 kill obsolete ifdefs Pekka Enberg: o 8139too: use iomap for pio/mmio Ralf Bächle: o Reformat DMASCC driver o Use netdev_priv in baycom_epp driver o Use netdev_priv in baycom_ser_fdx driver o Use netdev_priv in hdlcdrv driver o Use netdev_priv in baycom_ser_hdx driver o Use netdev_priv in baycom_par driver o Use netdev_priv in bpqether driver o Use netdev_priv in mkiss driver o Use netdev_priv in YAM driver o SGI Seeq updates o SB1250 driver updates o S2IO syntax fixes o Meth driver updates o Marvell MV-64340 driver upda o Jazzsonic driver updates o IOC3 driver updates o Remove Baget network driver o Au1000 driver updates Randy Dunlap: o ray_cs: reduce stack usage (sockaddr) o prism54: use NULL for pointer o (v2) arlan: remove gcc warning with CONFIG_PROC_FS=n Rene Herman: o 8139too Interframe Gap Time Scott Feldman: o eepro100: remove ID for 82556 o e100: remove reference to NAPI config option Steffen Klassert: o Add MODULE_VERSION to the 3c515 driver o Use netdev_priv in the 3c515 driver o 8139cp - add netpoll support Stephen Hemminger: o skge driver (0.5) o 8139too: use netdev_priv o 8139cp - module_param Thomas Gleixner: o rtl8139too.c: Fix missing pci_disable_dev o rtl8139too.c: Fix missing pci_disable_dev Tony Lindgren: o Add OMAP support to smc91x Ethernet driver --------------070108020601070901050105-- From jgarzik@pobox.com Wed Feb 23 23:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Feb 2005 23:29:24 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O7TJKQ028724 for ; Wed, 23 Feb 2005 23:29:20 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4DR0-0002wt-LQ; Thu, 24 Feb 2005 07:29:18 +0000 Message-ID: <421D8241.9020608@pobox.com> Date: Thu, 24 Feb 2005 02:29:05 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dominik Brodowski CC: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [8/14] Orinoco driver updates - PCMCIA initialization cleanups References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224065527.GA8931@isilmar.linta.de> In-Reply-To: <20050224065527.GA8931@isilmar.linta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2038 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: 283 Lines: 16 Dominik Brodowski wrote: >>@@ -184,6 +186,7 @@ >> dev_list = link; >> >> client_reg.dev_info = &dev_info; >>+ client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; > > > That's not needed any longer for 2.6. So who wants to send the incremental update patch? :) Jeff From Christian.Tschudin@unibas.ch Thu Feb 24 00:47:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 00:47:53 -0800 (PST) Received: from balu1.urz.unibas.ch (balu1.urz.unibas.ch [131.152.1.51]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O8lkkE002960 for ; Thu, 24 Feb 2005 00:47:47 -0800 Received: from igor.urz.unibas.ch (igor.urz.unibas.ch [131.152.1.3]) by balu1.urz.unibas.ch (8.12.10/8.12.10) with ESMTP id j1O8ldTM014165; Thu, 24 Feb 2005 09:47:40 +0100 Date: Thu, 24 Feb 2005 09:47:39 +0100 (MET) From: Christian Tschudin To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: netdev@oss.sgi.com Subject: Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c In-Reply-To: Message-ID: References: <20050131.172022.93845025.yoshfuji@linux-ipv6.org> <20050131.190157.42878368.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j1O8lkkE002960 X-archive-position: 2039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Christian.Tschudin@unibas.ch Precedence: bulk X-list: netdev Content-Length: 1733 Lines: 65 three weeks ago we had a message exchang on nd_tbl not being a public symbol; I had sent you some code for showing the usage. What do you think now? best, christian. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland On Mon, 31 Jan 2005, Christian Tschudin wrote: > On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > Ok, but basically, we do not export it unless it is really used. > > We may do if it is necessary when you merge it. > > > > BTW, for your purpose, we may export > > ndisc_lookup() > > or something instead of nd_tbl itself. > > > > Anyway, I'd like to know the usage (code). > > Your new ndisc_lookup() would need to distinguish the IP address types > (relating to different tables). > > Here is roughly what we do: > > --- > int netbox_neigh_map(struct net_device *dev, > struct lunartarget_s *host, > char *eth) > { > struct neighbour *neigh = 0; > > if (TARGET_IS_IPV4(host)) > neigh = neigh_lookup_errno(&arp_tbl, (struct in_addr*)&(host->addr.ipv4), dev); > else if (TARGET_IS_IPV6(host)) > neigh = neigh_lookup_errno(&nd_tbl, &host->addr.ipv6, dev); > > if (!IS_ERR(neigh)) { > neigh->parms->delay_probe_time = 0; > NEIGH_UPDATE(neigh, eth, NUD_REACHABLE, 1, 0); > neigh_release(neigh); > } > > return 0; > } > --- > > Our other function netbox_neigh_unmap() is basically the same, > with the flag NUD_REACHABLE replaced by NUD_NONE. > > best, christian > > PS: full code (use guest/guest for username/password) at > https://subversion.cs.unibas.ch/repos/lunar/trunk/lnx/knetbox.c > > > > > --yoshfuji > > > From yoshfuji@linux-ipv6.org Thu Feb 24 01:33:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 01:33:43 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1O9XcXe005247 for ; Thu, 24 Feb 2005 01:33:38 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D006433CC2; Thu, 24 Feb 2005 18:34:59 +0900 (JST) Date: Thu, 24 Feb 2005 18:34:53 +0900 (JST) Message-Id: <20050224.183453.06326363.yoshfuji@linux-ipv6.org> To: Christian.Tschudin@unibas.ch Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20050131.190157.42878368.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2040 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: 408 Lines: 11 In article (at Thu, 24 Feb 2005 09:47:39 +0100 (MET)), Christian Tschudin says: > three weeks ago we had a message exchang on nd_tbl not > being a public symbol; I had sent you some code for showing > the usage. > > What do you think now? I believe you can manage (map/unmap) neighbour entries via netlink. --yoshfuji From herbert@gondor.apana.org.au Thu Feb 24 02:31:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 02:31:18 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OAV9Gg007864 for ; Thu, 24 Feb 2005 02:31:10 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D4GGH-0003mK-00; Thu, 24 Feb 2005 21:30:25 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D4GFj-00068L-00; Thu, 24 Feb 2005 21:29:51 +1100 Date: Thu, 24 Feb 2005 21:29:51 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: [NET] Check skb_header_cloned for TSO packets in ixgb Message-ID: <20050224102951.GA23562@gondor.apana.org.au> References: <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> <20050215103312.6178385f.davem@davemloft.net> <20050215202453.GA4355@gondor.apana.org.au> <20050223195137.1e769c77.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20050223195137.1e769c77.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/722/Wed Feb 23 15:32:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2358 Lines: 95 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 23, 2005 at 07:51:37PM -0800, David S. Miller wrote: > > Also queued to 2.6.12, thanks. Someone should cook up the versions > for other drivers supporting TSO. I only found one other TSO driver that touches the headers, ixgb. Here is the patch which adds an skb_header_cloned check to it. Signed-off-by: Herbert Xu Do you know of any others? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/ixgb/ixgb_main.c 1.33 vs edited ===== --- 1.33/drivers/net/ixgb/ixgb_main.c 2005-01-11 16:03:21 +11:00 +++ edited/drivers/net/ixgb/ixgb_main.c 2005-02-24 21:26:48 +11:00 @@ -1155,7 +1155,7 @@ #define IXGB_TX_FLAGS_VLAN 0x00000002 #define IXGB_TX_FLAGS_TSO 0x00000004 -static inline boolean_t +static inline int ixgb_tso(struct ixgb_adapter *adapter, struct sk_buff *skb) { #ifdef NETIF_F_TSO @@ -1163,8 +1163,15 @@ unsigned int i; uint8_t ipcss, ipcso, tucss, tucso, hdr_len; uint16_t ipcse, tucse, mss; + int err; if(likely(skb_shinfo(skb)->tso_size)) { + if (skb_header_cloned(skb)) { + err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC); + if (err) + return err; + } + hdr_len = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); mss = skb_shinfo(skb)->tso_size; skb->nh.iph->tot_len = 0; @@ -1203,11 +1210,11 @@ if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; - return TRUE; + return 1; } #endif - return FALSE; + return 0; } static inline boolean_t @@ -1378,6 +1385,7 @@ unsigned int tx_flags = 0; unsigned long flags; int vlan_id = 0; + int tso; if(skb->len <= 0) { dev_kfree_skb_any(skb); @@ -1399,7 +1407,13 @@ first = adapter->tx_ring.next_to_use; - if(ixgb_tso(adapter, skb)) + tso = ixgb_tso(adapter, skb); + if (tso < 0) { + dev_kfree_skb_any(skb); + return NETDEV_TX_OK; + } + + if (tso) tx_flags |= IXGB_TX_FLAGS_TSO; else if(ixgb_tx_csum(adapter, skb)) tx_flags |= IXGB_TX_FLAGS_CSUM; --3V7upXqbjpZ4EhLz-- From webmaster@rapidforum.com Thu Feb 24 04:29:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 04:30:02 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1OCTtAl017905 for ; Thu, 24 Feb 2005 04:29:56 -0800 Received: (qmail 1289 invoked by uid 1004); 24 Feb 2005 12:29:55 -0000 Received: from p3ee0650a.dip0.t-ipconnect.de (HELO ?62.224.101.10?) (62.224.101.10) by www.rapidforum.com with SMTP; 24 Feb 2005 12:29:55 -0000 Message-ID: <421DC8C1.60704@rapidforum.com> Date: Thu, 24 Feb 2005 13:29:53 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: John Heffner CC: netdev@oss.sgi.com Subject: Re: Bug-hunting References: <421B4AB7.9030003@rapidforum.com> <20050222104448.31373a99.davem@davemloft.net> <421B8563.9030608@rapidforum.com> <20050222115114.0d0e568e.davem@davemloft.net> <421BBE7B.1050009@rapidforum.com> <20050222193000.404ae6d2.davem@davemloft.net> <421C5AC8.70601@rapidforum.com> <20050223112927.349550d0.davem@davemloft.net> <421CDD95.2020108@rapidforum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1564 Lines: 47 More track-downs: I have watched /proc/net/netstat and it didnt change. I experimented more with vm-parameters as I have understood that Linux is complex enough that bugs aren't obvious enough to simply say its the net-code just because a non-blocking socket suddenly blocks. I found out that changing /proc/sys/vm/min_free_kbytes gives the most drastic differences. I changed it to 1024000 and it suddenly speeded up drastically. I changed back to around 16000 and it suddenly slowed down immediately. Changed back to 1024000 and it speeded up immediately. Does someone know more about this? What does this parameter do? I watched /proc/meminfo but it didnt change anything really.MemFree is always around 10 MB: MemTotal: 8314392 kB MemFree: 10284 kB Buffers: 25644 kB Cached: 7724180 kB SwapCached: 0 kB Active: 991312 kB Inactive: 6977476 kB HighTotal: 6421952 kB HighFree: 640 kB LowTotal: 1892440 kB LowFree: 9644 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 116272 kB Writeback: 0 kB Mapped: 223940 kB Slab: 322652 kB CommitLimit: 4157196 kB Committed_AS: 794200 kB PageTables: 1788 kB VmallocTotal: 114680 kB VmallocUsed: 1200 kB VmallocChunk: 113392 kB John Heffner wrote: > Christian, > > Try looking at /proc/net/netstat while running. If TCPMemoryPressures is > increasing, you are running out of TCP memory, and you would expect to see > your socket buffers shrinking. > > -John > > From davem@davemloft.net Thu Feb 24 11:32:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 11:32:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OJWDA4016500 for ; Thu, 24 Feb 2005 11:32:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D4OhP-0006IX-00; Thu, 24 Feb 2005 11:30:59 -0800 Date: Thu, 24 Feb 2005 11:30:54 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [NET] Check skb_header_cloned for TSO packets in ixgb Message-Id: <20050224113054.51a2020e.davem@davemloft.net> In-Reply-To: <20050224102951.GA23562@gondor.apana.org.au> References: <20050126110043.GA29950@yakov.inr.ac.ru> <20050126222522.GA21670@gondor.apana.org.au> <20050127110946.GA20494@gondor.apana.org.au> <20050127111201.GB20494@gondor.apana.org.au> <20050128202542.GA23670@yakov.inr.ac.ru> <20050129031740.GA6130@gondor.apana.org.au> <20050129032210.GA7424@gondor.apana.org.au> <20050215103312.6178385f.davem@davemloft.net> <20050215202453.GA4355@gondor.apana.org.au> <20050223195137.1e769c77.davem@davemloft.net> <20050224102951.GA23562@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 602 Lines: 19 On Thu, 24 Feb 2005 21:29:51 +1100 Herbert Xu wrote: > On Wed, Feb 23, 2005 at 07:51:37PM -0800, David S. Miller wrote: > > > > Also queued to 2.6.12, thanks. Someone should cook up the versions > > for other drivers supporting TSO. > > I only found one other TSO driver that touches the headers, ixgb. > Here is the patch which adds an skb_header_cloned check to it. > > Signed-off-by: Herbert Xu Applied, thanks. > Do you know of any others? I thought there was another that messed with the headers, but I can't spot it anymore :-) From bunk@stusta.de Thu Feb 24 13:42:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 13:42:39 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1OLgWNJ026477 for ; Thu, 24 Feb 2005 13:42:33 -0800 Received: (qmail 15437 invoked from network); 24 Feb 2005 21:42:26 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 24 Feb 2005 21:42:26 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 633B3BBA24; Thu, 24 Feb 2005 22:42:24 +0100 (CET) Date: Thu, 24 Feb 2005 22:42:24 +0100 From: Adrian Bunk To: netdev@oss.sgi.com, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org Subject: [-mm patch] net/ieee80211/Kconfig: don't describe what gets selected Message-ID: <20050224214223.GJ8651@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1159 Lines: 32 The information what gets selected doesn't belong into the helh text (and at least "make menuconfig" already displays this information). Signed-off-by: Adrian Bunk --- linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig.old 2005-02-24 22:31:07.000000000 +0100 +++ linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig 2005-02-24 22:32:02.000000000 +0100 @@ -5,3 +5,3 @@ This option enables the hardware independent IEEE 802.11 - networking stack. This option will also select NET_RADIO. + networking stack. @@ -38,5 +38,3 @@ Include software based cipher suites in support of IEEE - 802.11's WEP. This is needed for WEP as well as 802.1x. This - selects ARC4 under kernel crypto libraries, and CRC32 under - kernel libraries. + 802.11's WEP. This is needed for WEP as well as 802.1x. @@ -52,4 +50,3 @@ (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled - networks. This selects AES support under kernel crypto - libraries. + networks. @@ -65,4 +62,3 @@ (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled - networks. This selects Michael Mic support under kernel crypto - libraries. + networks. From alexdeucher@gmail.com Thu Feb 24 13:46:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 13:46:40 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OLkYcN027080 for ; Thu, 24 Feb 2005 13:46:35 -0800 Received: by rproxy.gmail.com with SMTP id r35so491286rna for ; Thu, 24 Feb 2005 13:46:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=H56qSHdySV+ugmFARcAW9o9K5KeaiBVgOWWvhMrN33ARfn42+WVIm56HlbMyXTdV8kAcL/w+G4dtJUPMd+pQ7t9RAtcj/mOF9fjKTy5jTG43yC8wPhsysv3IRSYh+952AjgkQhtL+jxbBHAniwC9Pdg3PdBq4TOQDEpMgVBZh9Q= Received: by 10.38.76.59 with SMTP id y59mr52698rna; Thu, 24 Feb 2005 13:46:34 -0800 (PST) Received: by 10.38.24.3 with HTTP; Thu, 24 Feb 2005 13:46:34 -0800 (PST) Message-ID: Date: Thu, 24 Feb 2005 16:46:34 -0500 From: Alex Deucher Reply-To: Alex Deucher To: netdev@oss.sgi.com Subject: Marvell 88W8310 and 88E8050 PCI Express support Cc: linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexdeucher@gmail.com Precedence: bulk X-list: netdev Content-Length: 667 Lines: 16 I've noticed most of the new AMD64 chipsets now include integrated marvell GigE and wifi chips onboard. I haven't been able to find much on the status of linux support for these chips. Apparently the PCIE GigE chip only works with sk98lin and not skge: http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/0010.html Does anyone know if support for the chip is being added to skge? The 88W8310 doesn't seem to be supported at all, at least not that I can see. Does anyone know the status of the 88W8310? Are there any experimental drivers? Is Marvell friendly to opensource? Are the databooks available? Thanks, Alex PS, please CC: me as I'm not subscribed. From shemminger@osdl.org Thu Feb 24 14:35:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 14:35:10 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OMZ5lV030556 for ; Thu, 24 Feb 2005 14:35:05 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1OMYtqi005988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Feb 2005 14:34:56 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1OMYts4015878; Thu, 24 Feb 2005 14:34:55 -0800 Date: Thu, 24 Feb 2005 14:35:09 -0800 From: Stephen Hemminger To: Alex Deucher Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Marvell 88W8310 and 88E8050 PCI Express support Message-ID: <20050224143509.4fe2a6a8@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2046 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: 1075 Lines: 26 On Thu, 24 Feb 2005 16:46:34 -0500 Alex Deucher wrote: > I've noticed most of the new AMD64 chipsets now include integrated > marvell GigE and wifi chips onboard. I haven't been able to find much > on the status of linux support for these chips. Apparently the PCIE > GigE chip only works with sk98lin You need to use the version from SysKonnect. If you look at the source for that, you will see why I started on the skge driver. > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/0010.html > Does anyone know if support for the chip is being added to skge? As soon as I get the hardware (on order), or a donation of a new system. Then I will report the interface from sk98lin. > The > 88W8310 doesn't seem to be supported at all, at least not that I can > see. Does anyone know the status of the 88W8310? Are there any > experimental drivers? Is Marvell friendly to opensource? Are the > databooks available? If you find databook for Yukon 2 chipset let me know. I found the original Yukon and Genesis manuals, but nothing newer. From alexdeucher@gmail.com Thu Feb 24 15:08:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 15:08:56 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ON8p3K032355 for ; Thu, 24 Feb 2005 15:08:51 -0800 Received: by rproxy.gmail.com with SMTP id r35so503136rna for ; Thu, 24 Feb 2005 15:08:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ns9p1WdkMJVpclDRpUMrmsDS9weuEBEwgc+U+IF3F89v8RgbsdqsYqP8uORpmaBkGv2d/f/qEeD08zYhB43cSwzs5kSnQGTlqNtqZKYndWQDOB92C/1lHrm3pTZ4rRqIhzPBzQeA4kq3c6F35+YoFEPdc8OKBQnANPCv/AANb+Y= Received: by 10.38.12.9 with SMTP id 9mr129025rnl; Thu, 24 Feb 2005 15:08:50 -0800 (PST) Received: by 10.38.24.3 with HTTP; Thu, 24 Feb 2005 15:08:50 -0800 (PST) Message-ID: Date: Thu, 24 Feb 2005 18:08:50 -0500 From: Alex Deucher Reply-To: Alex Deucher To: Stephen Hemminger Subject: Re: Marvell 88W8310 and 88E8050 PCI Express support Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, jgarzik@pobox.com In-Reply-To: <20050224143509.4fe2a6a8@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050224143509.4fe2a6a8@dxpl.pdx.osdl.net> X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexdeucher@gmail.com Precedence: bulk X-list: netdev Content-Length: 1378 Lines: 37 On Thu, 24 Feb 2005 14:35:09 -0800, Stephen Hemminger wrote: > On Thu, 24 Feb 2005 16:46:34 -0500 > Alex Deucher wrote: > > > I've noticed most of the new AMD64 chipsets now include integrated > > marvell GigE and wifi chips onboard. I haven't been able to find much > > on the status of linux support for these chips. Apparently the PCIE > > GigE chip only works with sk98lin > > You need to use the version from SysKonnect. If you look at the source > for that, you will see why I started on the skge driver. > > > > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/0010.html > > Does anyone know if support for the chip is being added to skge? > > As soon as I get the hardware (on order), or a donation of a new system. > Then I will report the interface from sk98lin. > > > The > > 88W8310 doesn't seem to be supported at all, at least not that I can > > see. Does anyone know the status of the 88W8310? Are there any > > experimental drivers? Is Marvell friendly to opensource? Are the > > databooks available? > > If you find databook for Yukon 2 chipset let me know. I found the original > Yukon and Genesis manuals, but nothing newer. > Thanks for the info. If I get a board with a yukon 2, I'd be happy to help. I don't suppose you know anything about the wifi chip (88W8310)? Jeff? Thanks, Alex From shemminger@osdl.org Thu Feb 24 15:59:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 15:59:27 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ONxMuV002599 for ; Thu, 24 Feb 2005 15:59:22 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1ONwqqi013035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Feb 2005 15:58:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j1ONwqjc020723; Thu, 24 Feb 2005 15:58:52 -0800 Date: Thu, 24 Feb 2005 15:59:06 -0800 From: Stephen Hemminger To: "David S. Miller" , mostrows@speakeasy.net, Alexey Kuznetsov Cc: netdev@oss.sgi.com Subject: pppoe and receive checksum offload Message-ID: <20050224155906.73890361@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-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 Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2048 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: 673 Lines: 17 Someone reported a problem with skge hardware receive checksumming and PPPOE but it looks like a generic problem. Since PPPOE adds additional header bytes the hardware computed checksum will be wrong. Not sure if this is correct, but shouldn't pppoe be doing the following: ----- diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c --- a/drivers/net/pppoe.c 2005-02-24 15:40:10 -08:00 +++ b/drivers/net/pppoe.c 2005-02-24 15:40:10 -08:00 @@ -339,6 +339,7 @@ int len = ntohs(ph->length); skb_pull(skb, sizeof(struct pppoe_hdr)); skb_trim(skb, len); + skb->ip_summed = CHECKSUM_NONE; ppp_input(&po->chan, skb); } else if (sk->sk_state & PPPOX_RELAY) { From greearb@candelatech.com Thu Feb 24 16:16:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 16:16:40 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1P0GXP5003858 for ; Thu, 24 Feb 2005 16:16:34 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1P0cGLH018753; Thu, 24 Feb 2005 16:38:16 -0800 Message-ID: <421E6E61.3040005@candelatech.com> Date: Thu, 24 Feb 2005 16:16:33 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: linux-kernel Subject: Re: Tulip (DFE-570tx) & keyboard lockup in 2.6.9 and other 2.6 kernels. References: <421CF0BA.1020100@candelatech.com> In-Reply-To: <421CF0BA.1020100@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2049 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: 1056 Lines: 27 Ben Greear wrote: > I finally had some time to debug this one a little more > thoroughly. On two different machines (Shuttle SB61G1) I > get the same results, so I do not believe it is bad hardware... > > The bug is as follows: > > I have 1 4-port tulip NIC in the machine. If I generate traffic > between two interfaces, it runs fine. But, if I start running traffic > on all 4 interfaces, the keyboard quits taking input, and ethernet > traffic stops on at least a few of the interfaces. I can still ssh > into the machine (via the rtl8139 interface), so at least one of the > processors (I'm using SMP on an P4 HT processor) is working. I also > enabled NMI and that does not trigger. This was my bug. I was holding a lock that was required for receiving a packet while calling the hard_start_xmit method. When an IRQ happened while I was in the hard_start_xmit method, the IRQ could not grab the lock, and just sat there spinning... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From akpm@osdl.org Thu Feb 24 16:33:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 16:34:07 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1P0XvOV008423 for ; Thu, 24 Feb 2005 16:33:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1P0Xjqi016941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Feb 2005 16:33:45 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1P0XgA9022881; Thu, 24 Feb 2005 16:33:42 -0800 Date: Thu, 24 Feb 2005 16:38:56 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: olel@ans.pl Subject: Fw: [Bugme-new] [Bug 4249] New: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-Id: <20050224163856.21b82abf.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2050 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: 5940 Lines: 184 Begin forwarded message: Date: Thu, 24 Feb 2005 16:15:32 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4249] New: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) http://bugme.osdl.org/show_bug.cgi?id=4249 Summary: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Kernel Version: 2.6.11-rc4 Status: NEW Severity: high Owner: acme@conectiva.com.br Submitter: olel@ans.pl Distribution: Slackware 10 Hardware Environment: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 4 cpu MHz : 2793.832 cache size : 1024 KB physical id : 0 siblings : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr bogomips : 5505.02 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 4 cpu MHz : 2793.832 cache size : 1024 KB physical id : 0 siblings : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr bogomips : 5570.56 # lspci 00:00.0 Host bridge: Intel Corp. E7220/E7221 Memory Controller Hub (rev 05) 00:01.0 PCI bridge: Intel Corp. E7220/E7221 PCI Express Root Port (rev 05) 00:02.0 VGA compatible controller: Intel Corp. E7221 Integrated Graphics Controller (rev 05) 00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.2 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 Class 0106: Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 PCI bridge: Intel Corp. 6702PXH PCI Express-to-PCI Bridge A (rev 09) 01:00.1 PIC: Intel Corp. 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11) 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11) Software Environment: Linux version 2.6.11-rc4 (root@gw1) (gcc version 3.3.4) #1 SMP Mon Feb 14 06:47:58 CET 2005 # /usr/src/linux-2.6.11-rc4/scripts/ver_linux Linux gw1 2.6.11-rc4 #1 SMP Mon Feb 14 06:47:58 CET 2005 i686 unknown unknown GNU/Linux Gnu C 3.3.4 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12p mount 2.12p module-init-tools 3.1 e2fsprogs 1.35 reiserfsprogs line reiser4progs line quota-tools 3.12. PPP 2.4.2 Linux C Library 2.3.3 Dynamic linker (ldd) 2.3.3 Linux C++ Library 5.0.6 Procps 3.2.3 Net-tools 1.60 Kbd 1.12 Sh-utils 5.2.1 /usr/src/linux-2.6.11-rc4/scripts/ver_linux: line 90: udevinfo: command not found Modules Loaded bonding # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v2.6.1 (October 29, 2004) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Link Failure Count: 3 Permanent HW addr: 00:30:48:XX:XX:XX Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:30:48:XX:XX:XX # cat /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD vlan1 | 1 | bond0 vlan2 | 2 | bond0 vlan6 | 6 | bond0 vlan33 | 33 | bond0 vlan5 | 5 | bond0 Problem Description: I use keepalived for vrrpd. Sometimes, when I restart (kill & start) keepalived daemon kernel logs: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) vlan1: del 01:00:5e:00:00:12 mcast address from master interface The vlan1 device is used for vrrpd communication between two routers. It is created over the bound0 interface (eth0+eth1 in active-backup mode). Anyway, everything seems to work but this message is not very nice. Steps to reproduce: # killall keepalived ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dgibson@ozlabs.org Thu Feb 24 21:03:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 21:03:33 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1P53PkP022886 for ; Thu, 24 Feb 2005 21:03:26 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 7AA8967A70; Fri, 25 Feb 2005 16:03:19 +1100 (EST) Date: Fri, 25 Feb 2005 16:03:10 +1100 From: David Gibson To: Jeff Garzik Cc: Dominik Brodowski , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [Orinoco-devel] Re: [8/14] Orinoco driver updates - PCMCIA initialization cleanups Message-ID: <20050225050310.GF10725@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Dominik Brodowski , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224065527.GA8931@isilmar.linta.de> <421D8241.9020608@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421D8241.9020608@pobox.com> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2052 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1389 Lines: 42 On Thu, Feb 24, 2005 at 02:29:05AM -0500, Jeff Garzik wrote: > Dominik Brodowski wrote: > >>@@ -184,6 +186,7 @@ > >> dev_list = link; > >> > >> client_reg.dev_info = &dev_info; > >>+ client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; > > > > > >That's not needed any longer for 2.6. > > So who wants to send the incremental update patch? :) Guess I will. See below. Any particular reason the field and associated constants haven't been exunged from the tree, since they're no longer used? The client_reg.Attributes field is no longer used. Don't bother setting it. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco_cs.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_cs.c 2005-02-25 15:47:53.098405968 +1100 +++ working-2.6/drivers/net/wireless/orinoco_cs.c 2005-02-25 15:52:56.000000000 +1100 @@ -186,7 +186,6 @@ dev_list = link; client_reg.dev_info = &dev_info; - client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; client_reg.EventMask = CS_EVENT_CARD_INSERTION | CS_EVENT_CARD_REMOVAL | CS_EVENT_RESET_PHYSICAL | CS_EVENT_CARD_RESET | -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Thu Feb 24 21:03:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 21:03:33 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1P53P66022887 for ; Thu, 24 Feb 2005 21:03:26 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 779DB67A71; Fri, 25 Feb 2005 16:03:19 +1100 (EST) Date: Fri, 25 Feb 2005 15:58:54 +1100 From: David Gibson To: Jeff Garzik Cc: Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [Orinoco-devel] Re: [6/14] Orinoco driver updates - cleanup PCI initialization Message-ID: <20050225045854.GE10725@localhost.localdomain> Mail-Followup-To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035355.GA32001@localhost.localdomain> <20050224035445.GB32001@localhost.localdomain> <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <421D5979.5080600@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421D5979.5080600@pobox.com> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2051 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 2692 Lines: 83 On Wed, Feb 23, 2005 at 11:35:05PM -0500, Jeff Garzik wrote: > FYI, pci_set_drvdata() needs to be one of the last functions called > during PCI ->probe(). Ok, here's a patch to correct that (applies on top of the other stack, obviously): As Jeff Garzik has pointed out, pci_set_drvdata() belongs right at the end of PCI initialization. Correct this in the various PCI based orinoco drivers. Signed-off-by: David Gibson Index: working-2.6/drivers/net/wireless/orinoco_plx.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_plx.c 2005-02-25 15:47:53.011419192 +1100 +++ working-2.6/drivers/net/wireless/orinoco_plx.c 2005-02-25 15:45:13.000000000 +1100 @@ -257,7 +257,6 @@ SET_NETDEV_DEV(dev, &pdev->dev); hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 PLX device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, @@ -315,6 +314,8 @@ goto fail; } + pci_set_drvdata(pdev, dev); + return 0; fail: Index: working-2.6/drivers/net/wireless/orinoco_pci.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_pci.c 2005-02-25 15:47:53.282378000 +1100 +++ working-2.6/drivers/net/wireless/orinoco_pci.c 2005-02-25 15:44:50.000000000 +1100 @@ -230,7 +230,6 @@ SET_NETDEV_DEV(dev, &pdev->dev); hermes_struct_init(&priv->hw, pci_ioaddr, HERMES_32BIT_REGSPACING); - pci_set_drvdata(pdev, dev); printk(KERN_DEBUG PFX "Detected device %s, mem:0x%lx-0x%lx, irq %d\n", pci_name(pdev), dev->mem_start, dev->mem_end, pdev->irq); @@ -257,6 +256,8 @@ goto fail; } + pci_set_drvdata(pdev, dev); + return 0; fail: Index: working-2.6/drivers/net/wireless/orinoco_tmd.c =================================================================== --- working-2.6.orig/drivers/net/wireless/orinoco_tmd.c 2005-02-25 15:47:53.011419192 +1100 +++ working-2.6/drivers/net/wireless/orinoco_tmd.c 2005-02-25 15:45:33.000000000 +1100 @@ -166,7 +166,6 @@ SET_NETDEV_DEV(dev, &pdev->dev); hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 TMD device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, @@ -193,6 +192,8 @@ goto fail; } + pci_set_drvdata(pdev, dev); + return 0; fail: -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From brodo@linta.de Thu Feb 24 23:02:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Feb 2005 23:02:39 -0800 (PST) Received: from linta.de (isilmar.linta.de [213.239.214.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1P72YiM029246 for ; Thu, 24 Feb 2005 23:02:35 -0800 Received: (qmail 30546 invoked by uid 1000); 25 Feb 2005 07:02:26 -0000 Date: Fri, 25 Feb 2005 08:02:26 +0100 From: Dominik Brodowski To: Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [Orinoco-devel] Re: [8/14] Orinoco driver updates - PCMCIA initialization cleanups Message-ID: <20050225070226.GA30541@isilmar.linta.de> Mail-Followup-To: Dominik Brodowski , Jeff Garzik , Pavel Roskin , Orinoco Development List , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050224035524.GC32001@localhost.localdomain> <20050224035650.GD32001@localhost.localdomain> <20050224035718.GE32001@localhost.localdomain> <20050224035804.GF32001@localhost.localdomain> <20050224035957.GH32001@localhost.localdomain> <20050224040024.GI32001@localhost.localdomain> <20050224040052.GJ32001@localhost.localdomain> <20050224065527.GA8931@isilmar.linta.de> <421D8241.9020608@pobox.com> <20050225050310.GF10725@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050225050310.GF10725@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@dominikbrodowski.net Precedence: bulk X-list: netdev Content-Length: 677 Lines: 22 On Fri, Feb 25, 2005 at 04:03:10PM +1100, David Gibson wrote: > On Thu, Feb 24, 2005 at 02:29:05AM -0500, Jeff Garzik wrote: > > Dominik Brodowski wrote: > > >>@@ -184,6 +186,7 @@ > > >> dev_list = link; > > >> > > >> client_reg.dev_info = &dev_info; > > >>+ client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; > > > > > > > > >That's not needed any longer for 2.6. > > > > So who wants to send the incremental update patch? :) > > Guess I will. See below. > > Any particular reason the field and associated constants haven't been > exunged from the tree, since they're no longer used? To keep external drivers compiling -- it'll be removed soon, though. Dominik From mark@mtfhpc.demon.co.uk Fri Feb 25 08:40:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 08:40:23 -0800 (PST) Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PGeAM4005830 for ; Fri, 25 Feb 2005 08:40:11 -0800 Received: from mtfhpc.demon.co.uk ([83.104.139.140]) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1D4iVa-000Lsw-8H; Fri, 25 Feb 2005 16:40:08 +0000 Received: from localhost (mark@localhost) by mtfhpc.demon.co.uk (8.9.3/8.9.3) with ESMTP id QAA26292; Fri, 25 Feb 2005 16:40:01 GMT Date: Fri, 25 Feb 2005 16:40:01 +0000 (GMT) From: Mark Fortescue To: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2054 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mark@mtfhpc.demon.co.uk Precedence: bulk X-list: netdev Content-Length: 38427 Lines: 1326 Hi all, I am not sure exactly where to send this email. A have chosen the ip4/ip6 networking as the issues are in this area of the kernel. The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be correct. I had some errors during patching so I generated a diff against a freshly downloaded linux-2.6.10 kernel. See the steps below: 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - 2) cd linux-2.6.8.1 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 This gives a 2.6.8 kernel. 4) bzcat ../patch-2.6.9.bz2 | patch -p1 This should give a 2.6.9 kernel. The patch has two errors: ./net/ipv4/netfilter/ipt_ecn.c.rej ./net/ipv4/netfilter/ipt_tcpmss.c.rej 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f This should give a 2.6.10 kernel. The patch has three erros: ./include/linux/netfilter_ipv4/ipt_connmark.h.rej ./net/ipv4/netfilter/ipt_connmark.c.rej ./net/ipv6/netfilter/ip6t_MARK.c.rej 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err patch-2.6.10.err: ------------------------------------------------------------------------ diff -rupN linux-2.6.10p/include/linux/netfilter_ipv4/ipt_connmark.h.rej linux-2.6.10/include/linux/netfilter_ipv4/ipt_connmark.h.rej --- linux-2.6.10p/include/linux/netfilter_ipv4/ipt_connmark.h.rej 2005-02-25 16:00:01.703125000 +0000 +++ linux-2.6.10/include/linux/netfilter_ipv4/ipt_connmark.h.rej 1970-01-01 00:00:00.000000000 +0000 @@ -1,21 +0,0 @@ -*************** -*** 0 **** ---- 1,18 ---- -+ #ifndef _IPT_CONNMARK_H -+ #define _IPT_CONNMARK_H -+ -+ /* Copyright (C) 2002,2004 MARA Systems AB -+ * by Henrik Nordstrom -+ * -+ * This program is free software; you can redistribute it and/or modify -+ * it under the terms of the GNU General Public License as published by -+ * the Free Software Foundation; either version 2 of the License, or -+ * (at your option) any later version. -+ */ -+ -+ struct ipt_connmark_info { -+ unsigned long mark, mask; -+ u_int8_t invert; -+ }; -+ -+ #endif /*_IPT_CONNMARK_H*/ diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_TCPMSS.c linux-2.6.10/net/ipv4/netfilter/ipt_TCPMSS.c --- linux-2.6.10p/net/ipv4/netfilter/ipt_TCPMSS.c 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_TCPMSS.c 2004-12-24 21:34:48.000000000 +0000 @@ -0,0 +1,262 @@ +/* + * This is a module which is used for setting the MSS option in TCP packets. + * + * Copyright (C) 2000 Marc Boucher + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include + +#include +#include + +#include +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Marc Boucher "); +MODULE_DESCRIPTION("iptables TCP MSS modification module"); + +#if 0 +#define DEBUGP printk +#else +#define DEBUGP(format, args...) +#endif + +static u_int16_t +cheat_check(u_int32_t oldvalinv, u_int32_t newval, u_int16_t oldcheck) +{ + u_int32_t diffs[] = { oldvalinv, newval }; + return csum_fold(csum_partial((char *)diffs, sizeof(diffs), + oldcheck^0xFFFF)); +} + +static inline unsigned int +optlen(const u_int8_t *opt, unsigned int offset) +{ + /* Beware zero-length options: make finite progress */ + if (opt[offset] <= TCPOPT_NOP || opt[offset+1] == 0) return 1; + else return opt[offset+1]; +} + +static unsigned int +ipt_tcpmss_target(struct sk_buff **pskb, + const struct net_device *in, + const struct net_device *out, + unsigned int hooknum, + const void *targinfo, + void *userinfo) +{ + const struct ipt_tcpmss_info *tcpmssinfo = targinfo; + struct tcphdr *tcph; + struct iphdr *iph; + u_int16_t tcplen, newtotlen, oldval, newmss; + unsigned int i; + u_int8_t *opt; + + if (!skb_ip_make_writable(pskb, (*pskb)->len)) + return NF_DROP; + + iph = (*pskb)->nh.iph; + tcplen = (*pskb)->len - iph->ihl*4; + + tcph = (void *)iph + iph->ihl*4; + + /* Since it passed flags test in tcp match, we know it is is + not a fragment, and has data >= tcp header length. SYN + packets should not contain data: if they did, then we risk + running over MTU, sending Frag Needed and breaking things + badly. --RR */ + if (tcplen != tcph->doff*4) { + if (net_ratelimit()) + printk(KERN_ERR + "ipt_tcpmss_target: bad length (%d bytes)\n", + (*pskb)->len); + return NF_DROP; + } + + if(tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) { + if(!(*pskb)->dst) { + if (net_ratelimit()) + printk(KERN_ERR + "ipt_tcpmss_target: no dst?! can't determine path-MTU\n"); + return NF_DROP; /* or IPT_CONTINUE ?? */ + } + + if(dst_pmtu((*pskb)->dst) <= (sizeof(struct iphdr) + sizeof(struct tcphdr))) { + if (net_ratelimit()) + printk(KERN_ERR + "ipt_tcpmss_target: unknown or invalid path-MTU (%d)\n", dst_pmtu((*pskb)->dst)); + return NF_DROP; /* or IPT_CONTINUE ?? */ + } + + newmss = dst_pmtu((*pskb)->dst) - sizeof(struct iphdr) - sizeof(struct tcphdr); + } else + newmss = tcpmssinfo->mss; + + opt = (u_int8_t *)tcph; + for (i = sizeof(struct tcphdr); i < tcph->doff*4; i += optlen(opt, i)){ + if ((opt[i] == TCPOPT_MSS) && + ((tcph->doff*4 - i) >= TCPOLEN_MSS) && + (opt[i+1] == TCPOLEN_MSS)) { + u_int16_t oldmss; + + oldmss = (opt[i+2] << 8) | opt[i+3]; + + if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && + (oldmss <= newmss)) + return IPT_CONTINUE; + + opt[i+2] = (newmss & 0xff00) >> 8; + opt[i+3] = (newmss & 0x00ff); + + tcph->check = cheat_check(htons(oldmss)^0xFFFF, + htons(newmss), + tcph->check); + + DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" + "->%u.%u.%u.%u:%hu changed TCP MSS option" + " (from %u to %u)\n", + NIPQUAD((*pskb)->nh.iph->saddr), + ntohs(tcph->source), + NIPQUAD((*pskb)->nh.iph->daddr), + ntohs(tcph->dest), + oldmss, newmss); + goto retmodified; + } + } + + /* + * MSS Option not found ?! add it.. + */ + if (skb_tailroom((*pskb)) < TCPOLEN_MSS) { + struct sk_buff *newskb; + + newskb = skb_copy_expand(*pskb, skb_headroom(*pskb), + TCPOLEN_MSS, GFP_ATOMIC); + if (!newskb) { + if (net_ratelimit()) + printk(KERN_ERR "ipt_tcpmss_target:" + " unable to allocate larger skb\n"); + return NF_DROP; + } + + kfree_skb(*pskb); + *pskb = newskb; + iph = (*pskb)->nh.iph; + tcph = (void *)iph + iph->ihl*4; + } + + skb_put((*pskb), TCPOLEN_MSS); + + opt = (u_int8_t *)tcph + sizeof(struct tcphdr); + memmove(opt + TCPOLEN_MSS, opt, tcplen - sizeof(struct tcphdr)); + + tcph->check = cheat_check(htons(tcplen) ^ 0xFFFF, + htons(tcplen + TCPOLEN_MSS), tcph->check); + tcplen += TCPOLEN_MSS; + + opt[0] = TCPOPT_MSS; + opt[1] = TCPOLEN_MSS; + opt[2] = (newmss & 0xff00) >> 8; + opt[3] = (newmss & 0x00ff); + + tcph->check = cheat_check(~0, *((u_int32_t *)opt), tcph->check); + + oldval = ((u_int16_t *)tcph)[6]; + tcph->doff += TCPOLEN_MSS/4; + tcph->check = cheat_check(oldval ^ 0xFFFF, + ((u_int16_t *)tcph)[6], tcph->check); + + newtotlen = htons(ntohs(iph->tot_len) + TCPOLEN_MSS); + iph->check = cheat_check(iph->tot_len ^ 0xFFFF, + newtotlen, iph->check); + iph->tot_len = newtotlen; + + DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" + "->%u.%u.%u.%u:%hu added TCP MSS option (%u)\n", + NIPQUAD((*pskb)->nh.iph->saddr), + ntohs(tcph->source), + NIPQUAD((*pskb)->nh.iph->daddr), + ntohs(tcph->dest), + newmss); + + retmodified: + /* We never hw checksum SYN packets. */ + BUG_ON((*pskb)->ip_summed == CHECKSUM_HW); + + (*pskb)->nfcache |= NFC_UNKNOWN | NFC_ALTERED; + return IPT_CONTINUE; +} + +#define TH_SYN 0x02 + +static inline int find_syn_match(const struct ipt_entry_match *m) +{ + const struct ipt_tcp *tcpinfo = (const struct ipt_tcp *)m->data; + + if (strcmp(m->u.kernel.match->name, "tcp") == 0 + && (tcpinfo->flg_cmp & TH_SYN) + && !(tcpinfo->invflags & IPT_TCP_INV_FLAGS)) + return 1; + + return 0; +} + +/* Must specify -p tcp --syn/--tcp-flags SYN */ +static int +ipt_tcpmss_checkentry(const char *tablename, + const struct ipt_entry *e, + void *targinfo, + unsigned int targinfosize, + unsigned int hook_mask) +{ + const struct ipt_tcpmss_info *tcpmssinfo = targinfo; + + if (targinfosize != IPT_ALIGN(sizeof(struct ipt_tcpmss_info))) { + DEBUGP("ipt_tcpmss_checkentry: targinfosize %u != %u\n", + targinfosize, IPT_ALIGN(sizeof(struct ipt_tcpmss_info))); + return 0; + } + + + if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && + ((hook_mask & ~((1 << NF_IP_FORWARD) + | (1 << NF_IP_LOCAL_OUT) + | (1 << NF_IP_POST_ROUTING))) != 0)) { + printk("TCPMSS: path-MTU clamping only supported in FORWARD, OUTPUT and POSTROUTING hooks\n"); + return 0; + } + + if (e->ip.proto == IPPROTO_TCP + && !(e->ip.invflags & IPT_INV_PROTO) + && IPT_MATCH_ITERATE(e, find_syn_match)) + return 1; + + printk("TCPMSS: Only works on TCP SYN packets\n"); + return 0; +} + +static struct ipt_target ipt_tcpmss_reg = { + .name = "TCPMSS", + .target = ipt_tcpmss_target, + .checkentry = ipt_tcpmss_checkentry, + .me = THIS_MODULE, +}; + +static int __init init(void) +{ + return ipt_register_target(&ipt_tcpmss_reg); +} + +static void __exit fini(void) +{ + ipt_unregister_target(&ipt_tcpmss_reg); +} + +module_init(init); +module_exit(fini); diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_connmark.c.rej linux-2.6.10/net/ipv4/netfilter/ipt_connmark.c.rej --- linux-2.6.10p/net/ipv4/netfilter/ipt_connmark.c.rej 2005-02-25 16:06:01.390625000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_connmark.c.rej 1970-01-01 00:00:00.000000000 +0000 @@ -1,84 +0,0 @@ -*************** -*** 0 **** ---- 1,81 ---- -+ /* This kernel module matches connection mark values set by the -+ * CONNMARK target -+ * -+ * Copyright (C) 2002,2004 MARA Systems AB -+ * by Henrik Nordstrom -+ * -+ * This program is free software; you can redistribute it and/or modify -+ * it under the terms of the GNU General Public License as published by -+ * the Free Software Foundation; either version 2 of the License, or -+ * (at your option) any later version. -+ * -+ * This program is distributed in the hope that it will be useful, -+ * but WITHOUT ANY WARRANTY; without even the implied warranty of -+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -+ * GNU General Public License for more details. -+ * -+ * You should have received a copy of the GNU General Public License -+ * along with this program; if not, write to the Free Software -+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -+ */ -+ -+ #include -+ #include -+ -+ MODULE_AUTHOR("Henrik Nordstrom "); -+ MODULE_DESCRIPTION("IP tables connmark match module"); -+ MODULE_LICENSE("GPL"); -+ -+ #include -+ #include -+ #include -+ -+ static int -+ match(const struct sk_buff *skb, -+ const struct net_device *in, -+ const struct net_device *out, -+ const void *matchinfo, -+ int offset, -+ int *hotdrop) -+ { -+ const struct ipt_connmark_info *info = matchinfo; -+ enum ip_conntrack_info ctinfo; -+ struct ip_conntrack *ct = ip_conntrack_get((struct sk_buff *)skb, &ctinfo); -+ if (!ct) -+ return 0; -+ -+ return ((ct->mark & info->mask) == info->mark) ^ info->invert; -+ } -+ -+ static int -+ checkentry(const char *tablename, -+ const struct ipt_ip *ip, -+ void *matchinfo, -+ unsigned int matchsize, -+ unsigned int hook_mask) -+ { -+ if (matchsize != IPT_ALIGN(sizeof(struct ipt_connmark_info))) -+ return 0; -+ -+ return 1; -+ } -+ -+ static struct ipt_match connmark_match = { -+ .name = "connmark", -+ .match = &match, -+ .checkentry = &checkentry, -+ .me = THIS_MODULE -+ }; -+ -+ static int __init init(void) -+ { -+ return ipt_register_match(&connmark_match); -+ } -+ -+ static void __exit fini(void) -+ { -+ ipt_unregister_match(&connmark_match); -+ } -+ -+ module_init(init); -+ module_exit(fini); diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_ecn.c.orig linux-2.6.10/net/ipv4/netfilter/ipt_ecn.c.orig --- linux-2.6.10p/net/ipv4/netfilter/ipt_ecn.c.orig 2005-02-25 15:53:04.375000000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_ecn.c.orig 1970-01-01 00:00:00.000000000 +0000 @@ -1,178 +0,0 @@ -/* iptables module for the IPv4 and TCP ECN bits, Version 1.5 - * - * (C) 2002 by Harald Welte - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * ipt_ECN.c,v 1.5 2002/08/18 19:36:51 laforge Exp -*/ - -#include -#include -#include -#include -#include - -#include -#include - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Harald Welte "); -MODULE_DESCRIPTION("iptables ECN modification module"); - -/* set ECT codepoint from IP header. - * return 0 if there was an error. */ -static inline int -set_ect_ip(struct sk_buff **pskb, const struct ipt_ECN_info *einfo) -{ - if (((*pskb)->nh.iph->tos & IPT_ECN_IP_MASK) - != (einfo->ip_ect & IPT_ECN_IP_MASK)) { - u_int16_t diffs[2]; - - if (!skb_ip_make_writable(pskb, sizeof(struct iphdr))) - return 0; - - diffs[0] = htons((*pskb)->nh.iph->tos) ^ 0xFFFF; - (*pskb)->nh.iph->tos &= ~IPT_ECN_IP_MASK; - (*pskb)->nh.iph->tos |= (einfo->ip_ect & IPT_ECN_IP_MASK); - diffs[1] = htons((*pskb)->nh.iph->tos); - (*pskb)->nh.iph->check - = csum_fold(csum_partial((char *)diffs, - sizeof(diffs), - (*pskb)->nh.iph->check - ^0xFFFF)); - (*pskb)->nfcache |= NFC_ALTERED; - } - return 1; -} - -/* Return 0 if there was an error. */ -static inline int -set_ect_tcp(struct sk_buff **pskb, const struct ipt_ECN_info *einfo, int inward) -{ - struct tcphdr _tcph, *th; - u_int16_t diffs[2]; - - /* Not enought header? */ - th = skb_header_pointer(*pskb, (*pskb)->nh.iph->ihl*4, - sizeof(_tcph), &_tcph); - if (th == NULL) - return 0; - - diffs[0] = ((u_int16_t *)th)[6]; - if (einfo->operation & IPT_ECN_OP_SET_ECE) - th->ece = einfo->proto.tcp.ece; - - if (einfo->operation & IPT_ECN_OP_SET_CWR) - th->cwr = einfo->proto.tcp.cwr; - diffs[1] = ((u_int16_t *)&th)[6]; - - /* Only mangle if it's changed. */ - if (diffs[0] != diffs[1]) { - diffs[0] = diffs[0] ^ 0xFFFF; - if (!skb_ip_make_writable(pskb, - (*pskb)->nh.iph->ihl*4+sizeof(_tcph))) - return 0; - - if (th != &_tcph) - memcpy(&_tcph, th, sizeof(_tcph)); - - if ((*pskb)->ip_summed != CHECKSUM_HW) - _tcph.check = csum_fold(csum_partial((char *)diffs, - sizeof(diffs), - _tcph.check^0xFFFF)); - memcpy((*pskb)->data + (*pskb)->nh.iph->ihl*4, - &_tcph, sizeof(_tcph)); - if ((*pskb)->ip_summed == CHECKSUM_HW) - if (skb_checksum_help(pskb, inward)) - return 0; - (*pskb)->nfcache |= NFC_ALTERED; - } - return 1; -} - -static unsigned int -target(struct sk_buff **pskb, - const struct net_device *in, - const struct net_device *out, - unsigned int hooknum, - const void *targinfo, - void *userinfo) -{ - const struct ipt_ECN_info *einfo = targinfo; - - if (einfo->operation & IPT_ECN_OP_SET_IP) - if (!set_ect_ip(pskb, einfo)) - return NF_DROP; - - if (einfo->operation & (IPT_ECN_OP_SET_ECE | IPT_ECN_OP_SET_CWR) - && (*pskb)->nh.iph->protocol == IPPROTO_TCP) - if (!set_ect_tcp(pskb, einfo, (out == NULL))) - return NF_DROP; - - return IPT_CONTINUE; -} - -static int -checkentry(const char *tablename, - const struct ipt_entry *e, - void *targinfo, - unsigned int targinfosize, - unsigned int hook_mask) -{ - const struct ipt_ECN_info *einfo = (struct ipt_ECN_info *)targinfo; - - if (targinfosize != IPT_ALIGN(sizeof(struct ipt_ECN_info))) { - printk(KERN_WARNING "ECN: targinfosize %u != %Zu\n", - targinfosize, - IPT_ALIGN(sizeof(struct ipt_ECN_info))); - return 0; - } - - if (strcmp(tablename, "mangle") != 0) { - printk(KERN_WARNING "ECN: can only be called from \"mangle\" table, not \"%s\"\n", tablename); - return 0; - } - - if (einfo->operation & IPT_ECN_OP_MASK) { - printk(KERN_WARNING "ECN: unsupported ECN operation %x\n", - einfo->operation); - return 0; - } - if (einfo->ip_ect & ~IPT_ECN_IP_MASK) { - printk(KERN_WARNING "ECN: new ECT codepoint %x out of mask\n", - einfo->ip_ect); - return 0; - } - - if ((einfo->operation & (IPT_ECN_OP_SET_ECE|IPT_ECN_OP_SET_CWR)) - && e->ip.proto != IPPROTO_TCP) { - printk(KERN_WARNING "ECN: cannot use TCP operations on a " - "non-tcp rule\n"); - return 0; - } - - return 1; -} - -static struct ipt_target ipt_ecn_reg = { - .name = "ECN", - .target = target, - .checkentry = checkentry, - .me = THIS_MODULE, -}; - -static int __init init(void) -{ - return ipt_register_target(&ipt_ecn_reg); -} - -static void __exit fini(void) -{ - ipt_unregister_target(&ipt_ecn_reg); -} - -module_init(init); -module_exit(fini); diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_ecn.c.rej linux-2.6.10/net/ipv4/netfilter/ipt_ecn.c.rej --- linux-2.6.10p/net/ipv4/netfilter/ipt_ecn.c.rej 2005-02-25 15:53:04.812500000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_ecn.c.rej 1970-01-01 00:00:00.000000000 +0000 @@ -1,68 +0,0 @@ -*************** -*** 30,60 **** - const struct ipt_ecn_info *einfo, - int *hotdrop) - { -- struct tcphdr tcph; - - /* In practice, TCP match does this, so can't fail. But let's -- be good citizens. */ -- if (skb_copy_bits(skb, skb->nh.iph->ihl*4, &tcph, sizeof(tcph)) < 0) { - *hotdrop = 0; - return 0; - } - - if (einfo->operation & IPT_ECN_OP_MATCH_ECE) { - if (einfo->invert & IPT_ECN_OP_MATCH_ECE) { -- if (tcph.ece == 1) - return 0; - } else { -- if (tcph.ece == 0) - return 0; - } - } - - if (einfo->operation & IPT_ECN_OP_MATCH_CWR) { - if (einfo->invert & IPT_ECN_OP_MATCH_CWR) { -- if (tcph.cwr == 1) - return 0; - } else { -- if (tcph.cwr == 0) - return 0; - } - } ---- 30,63 ---- - const struct ipt_ecn_info *einfo, - int *hotdrop) - { -+ struct tcphdr _tcph, *th; - - /* In practice, TCP match does this, so can't fail. But let's -+ * be good citizens. -+ */ -+ th = skb_header_pointer(skb, skb->nh.iph->ihl * 4, -+ sizeof(_tcph), &_tcph); -+ if (th == NULL) { - *hotdrop = 0; - return 0; - } - - if (einfo->operation & IPT_ECN_OP_MATCH_ECE) { - if (einfo->invert & IPT_ECN_OP_MATCH_ECE) { -+ if (th->ece == 1) - return 0; - } else { -+ if (th->ece == 0) - return 0; - } - } - - if (einfo->operation & IPT_ECN_OP_MATCH_CWR) { - if (einfo->invert & IPT_ECN_OP_MATCH_CWR) { -+ if (th->cwr == 1) - return 0; - } else { -+ if (th->cwr == 0) - return 0; - } - } diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c --- linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c 2005-02-25 16:06:02.000000000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c 1970-01-01 00:00:00.000000000 +0000 @@ -1,262 +0,0 @@ -/* - * This is a module which is used for setting the MSS option in TCP packets. - * - * Copyright (C) 2000 Marc Boucher - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include - -#include -#include - -#include -#include - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Marc Boucher "); -MODULE_DESCRIPTION("iptables TCP MSS modification module"); - -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - -static u_int16_t -cheat_check(u_int32_t oldvalinv, u_int32_t newval, u_int16_t oldcheck) -{ - u_int32_t diffs[] = { oldvalinv, newval }; - return csum_fold(csum_partial((char *)diffs, sizeof(diffs), - oldcheck^0xFFFF)); -} - -static inline unsigned int -optlen(const u_int8_t *opt, unsigned int offset) -{ - /* Beware zero-length options: make finite progress */ - if (opt[offset] <= TCPOPT_NOP || opt[offset+1] == 0) return 1; - else return opt[offset+1]; -} - -static unsigned int -ipt_tcpmss_target(struct sk_buff **pskb, - const struct net_device *in, - const struct net_device *out, - unsigned int hooknum, - const void *targinfo, - void *userinfo) -{ - const struct ipt_tcpmss_info *tcpmssinfo = targinfo; - struct tcphdr *tcph; - struct iphdr *iph; - u_int16_t tcplen, newtotlen, oldval, newmss; - unsigned int i; - u_int8_t *opt; - - if (!skb_ip_make_writable(pskb, (*pskb)->len)) - return NF_DROP; - - iph = (*pskb)->nh.iph; - tcplen = (*pskb)->len - iph->ihl*4; - - tcph = (void *)iph + iph->ihl*4; - - /* Since it passed flags test in tcp match, we know it is is - not a fragment, and has data >= tcp header length. SYN - packets should not contain data: if they did, then we risk - running over MTU, sending Frag Needed and breaking things - badly. --RR */ - if (tcplen != tcph->doff*4) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: bad length (%d bytes)\n", - (*pskb)->len); - return NF_DROP; - } - - if(tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) { - if(!(*pskb)->dst) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: no dst?! can't determine path-MTU\n"); - return NF_DROP; /* or IPT_CONTINUE ?? */ - } - - if(dst_pmtu((*pskb)->dst) <= (sizeof(struct iphdr) + sizeof(struct tcphdr))) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: unknown or invalid path-MTU (%d)\n", dst_pmtu((*pskb)->dst)); - return NF_DROP; /* or IPT_CONTINUE ?? */ - } - - newmss = dst_pmtu((*pskb)->dst) - sizeof(struct iphdr) - sizeof(struct tcphdr); - } else - newmss = tcpmssinfo->mss; - - opt = (u_int8_t *)tcph; - for (i = sizeof(struct tcphdr); i < tcph->doff*4; i += optlen(opt, i)){ - if ((opt[i] == TCPOPT_MSS) && - ((tcph->doff*4 - i) >= TCPOLEN_MSS) && - (opt[i+1] == TCPOLEN_MSS)) { - u_int16_t oldmss; - - oldmss = (opt[i+2] << 8) | opt[i+3]; - - if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && - (oldmss <= newmss)) - return IPT_CONTINUE; - - opt[i+2] = (newmss & 0xff00) >> 8; - opt[i+3] = (newmss & 0x00ff); - - tcph->check = cheat_check(htons(oldmss)^0xFFFF, - htons(newmss), - tcph->check); - - DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" - "->%u.%u.%u.%u:%hu changed TCP MSS option" - " (from %u to %u)\n", - NIPQUAD((*pskb)->nh.iph->saddr), - ntohs(tcph->source), - NIPQUAD((*pskb)->nh.iph->daddr), - ntohs(tcph->dest), - oldmss, newmss); - goto retmodified; - } - } - - /* - * MSS Option not found ?! add it.. - */ - if (skb_tailroom((*pskb)) < TCPOLEN_MSS) { - struct sk_buff *newskb; - - newskb = skb_copy_expand(*pskb, skb_headroom(*pskb), - TCPOLEN_MSS, GFP_ATOMIC); - if (!newskb) { - if (net_ratelimit()) - printk(KERN_ERR "ipt_tcpmss_target:" - " unable to allocate larger skb\n"); - return NF_DROP; - } - - kfree_skb(*pskb); - *pskb = newskb; - iph = (*pskb)->nh.iph; - tcph = (void *)iph + iph->ihl*4; - } - - skb_put((*pskb), TCPOLEN_MSS); - - opt = (u_int8_t *)tcph + sizeof(struct tcphdr); - memmove(opt + TCPOLEN_MSS, opt, tcplen - sizeof(struct tcphdr)); - - tcph->check = cheat_check(htons(tcplen) ^ 0xFFFF, - htons(tcplen + TCPOLEN_MSS), tcph->check); - tcplen += TCPOLEN_MSS; - - opt[0] = TCPOPT_MSS; - opt[1] = TCPOLEN_MSS; - opt[2] = (newmss & 0xff00) >> 8; - opt[3] = (newmss & 0x00ff); - - tcph->check = cheat_check(~0, *((u_int32_t *)opt), tcph->check); - - oldval = ((u_int16_t *)tcph)[6]; - tcph->doff += TCPOLEN_MSS/4; - tcph->check = cheat_check(oldval ^ 0xFFFF, - ((u_int16_t *)tcph)[6], tcph->check); - - newtotlen = htons(ntohs(iph->tot_len) + TCPOLEN_MSS); - iph->check = cheat_check(iph->tot_len ^ 0xFFFF, - newtotlen, iph->check); - iph->tot_len = newtotlen; - - DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" - "->%u.%u.%u.%u:%hu added TCP MSS option (%u)\n", - NIPQUAD((*pskb)->nh.iph->saddr), - ntohs(tcph->source), - NIPQUAD((*pskb)->nh.iph->daddr), - ntohs(tcph->dest), - newmss); - - retmodified: - /* We never hw checksum SYN packets. */ - BUG_ON((*pskb)->ip_summed == CHECKSUM_HW); - - (*pskb)->nfcache |= NFC_UNKNOWN | NFC_ALTERED; - return IPT_CONTINUE; -} - -#define TH_SYN 0x02 - -static inline int find_syn_match(const struct ipt_entry_match *m) -{ - const struct ipt_tcp *tcpinfo = (const struct ipt_tcp *)m->data; - - if (strcmp(m->u.kernel.match->name, "tcp") == 0 - && (tcpinfo->flg_cmp & TH_SYN) - && !(tcpinfo->invflags & IPT_TCP_INV_FLAGS)) - return 1; - - return 0; -} - -/* Must specify -p tcp --syn/--tcp-flags SYN */ -static int -ipt_tcpmss_checkentry(const char *tablename, - const struct ipt_entry *e, - void *targinfo, - unsigned int targinfosize, - unsigned int hook_mask) -{ - const struct ipt_tcpmss_info *tcpmssinfo = targinfo; - - if (targinfosize != IPT_ALIGN(sizeof(struct ipt_tcpmss_info))) { - DEBUGP("ipt_tcpmss_checkentry: targinfosize %u != %u\n", - targinfosize, IPT_ALIGN(sizeof(struct ipt_tcpmss_info))); - return 0; - } - - - if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && - ((hook_mask & ~((1 << NF_IP_FORWARD) - | (1 << NF_IP_LOCAL_OUT) - | (1 << NF_IP_POST_ROUTING))) != 0)) { - printk("TCPMSS: path-MTU clamping only supported in FORWARD, OUTPUT and POSTROUTING hooks\n"); - return 0; - } - - if (e->ip.proto == IPPROTO_TCP - && !(e->ip.invflags & IPT_INV_PROTO) - && IPT_MATCH_ITERATE(e, find_syn_match)) - return 1; - - printk("TCPMSS: Only works on TCP SYN packets\n"); - return 0; -} - -static struct ipt_target ipt_tcpmss_reg = { - .name = "TCPMSS", - .target = ipt_tcpmss_target, - .checkentry = ipt_tcpmss_checkentry, - .me = THIS_MODULE, -}; - -static int __init init(void) -{ - return ipt_register_target(&ipt_tcpmss_reg); -} - -static void __exit fini(void) -{ - ipt_unregister_target(&ipt_tcpmss_reg); -} - -module_init(init); -module_exit(fini); diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c.orig linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c.orig --- linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c.orig 2005-02-25 15:53:05.156250000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c.orig 1970-01-01 00:00:00.000000000 +0000 @@ -1,262 +0,0 @@ -/* - * This is a module which is used for setting the MSS option in TCP packets. - * - * Copyright (C) 2000 Marc Boucher - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include - -#include -#include - -#include -#include - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Marc Boucher "); -MODULE_DESCRIPTION("iptables TCP MSS modification module"); - -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - -static u_int16_t -cheat_check(u_int32_t oldvalinv, u_int32_t newval, u_int16_t oldcheck) -{ - u_int32_t diffs[] = { oldvalinv, newval }; - return csum_fold(csum_partial((char *)diffs, sizeof(diffs), - oldcheck^0xFFFF)); -} - -static inline unsigned int -optlen(const u_int8_t *opt, unsigned int offset) -{ - /* Beware zero-length options: make finite progress */ - if (opt[offset] <= TCPOPT_NOP || opt[offset+1] == 0) return 1; - else return opt[offset+1]; -} - -static unsigned int -ipt_tcpmss_target(struct sk_buff **pskb, - const struct net_device *in, - const struct net_device *out, - unsigned int hooknum, - const void *targinfo, - void *userinfo) -{ - const struct ipt_tcpmss_info *tcpmssinfo = targinfo; - struct tcphdr *tcph; - struct iphdr *iph; - u_int16_t tcplen, newtotlen, oldval, newmss; - unsigned int i; - u_int8_t *opt; - - if (!skb_ip_make_writable(pskb, (*pskb)->len)) - return NF_DROP; - - iph = (*pskb)->nh.iph; - tcplen = (*pskb)->len - iph->ihl*4; - - tcph = (void *)iph + iph->ihl*4; - - /* Since it passed flags test in tcp match, we know it is is - not a fragment, and has data >= tcp header length. SYN - packets should not contain data: if they did, then we risk - running over MTU, sending Frag Needed and breaking things - badly. --RR */ - if (tcplen != tcph->doff*4) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: bad length (%d bytes)\n", - (*pskb)->len); - return NF_DROP; - } - - if(tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) { - if(!(*pskb)->dst) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: no dst?! can't determine path-MTU\n"); - return NF_DROP; /* or IPT_CONTINUE ?? */ - } - - if(dst_pmtu((*pskb)->dst) <= (sizeof(struct iphdr) + sizeof(struct tcphdr))) { - if (net_ratelimit()) - printk(KERN_ERR - "ipt_tcpmss_target: unknown or invalid path-MTU (%d)\n", dst_pmtu((*pskb)->dst)); - return NF_DROP; /* or IPT_CONTINUE ?? */ - } - - newmss = dst_pmtu((*pskb)->dst) - sizeof(struct iphdr) - sizeof(struct tcphdr); - } else - newmss = tcpmssinfo->mss; - - opt = (u_int8_t *)tcph; - for (i = sizeof(struct tcphdr); i < tcph->doff*4; i += optlen(opt, i)){ - if ((opt[i] == TCPOPT_MSS) && - ((tcph->doff*4 - i) >= TCPOLEN_MSS) && - (opt[i+1] == TCPOLEN_MSS)) { - u_int16_t oldmss; - - oldmss = (opt[i+2] << 8) | opt[i+3]; - - if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && - (oldmss <= newmss)) - return IPT_CONTINUE; - - opt[i+2] = (newmss & 0xff00) >> 8; - opt[i+3] = (newmss & 0x00ff); - - tcph->check = cheat_check(htons(oldmss)^0xFFFF, - htons(newmss), - tcph->check); - - DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" - "->%u.%u.%u.%u:%hu changed TCP MSS option" - " (from %u to %u)\n", - NIPQUAD((*pskb)->nh.iph->saddr), - ntohs(tcph->source), - NIPQUAD((*pskb)->nh.iph->daddr), - ntohs(tcph->dest), - oldmss, newmss); - goto retmodified; - } - } - - /* - * MSS Option not found ?! add it.. - */ - if (skb_tailroom((*pskb)) < TCPOLEN_MSS) { - struct sk_buff *newskb; - - newskb = skb_copy_expand(*pskb, skb_headroom(*pskb), - TCPOLEN_MSS, GFP_ATOMIC); - if (!newskb) { - if (net_ratelimit()) - printk(KERN_ERR "ipt_tcpmss_target:" - " unable to allocate larger skb\n"); - return NF_DROP; - } - - kfree_skb(*pskb); - *pskb = newskb; - iph = (*pskb)->nh.iph; - tcph = (void *)iph + iph->ihl*4; - } - - skb_put((*pskb), TCPOLEN_MSS); - - opt = (u_int8_t *)tcph + sizeof(struct tcphdr); - memmove(opt + TCPOLEN_MSS, opt, tcplen - sizeof(struct tcphdr)); - - tcph->check = cheat_check(htons(tcplen) ^ 0xFFFF, - htons(tcplen + TCPOLEN_MSS), tcph->check); - tcplen += TCPOLEN_MSS; - - opt[0] = TCPOPT_MSS; - opt[1] = TCPOLEN_MSS; - opt[2] = (newmss & 0xff00) >> 8; - opt[3] = (newmss & 0x00ff); - - tcph->check = cheat_check(~0, *((u_int32_t *)opt), tcph->check); - - oldval = ((u_int16_t *)tcph)[6]; - tcph->doff += TCPOLEN_MSS/4; - tcph->check = cheat_check(oldval ^ 0xFFFF, - ((u_int16_t *)tcph)[6], tcph->check); - - newtotlen = htons(ntohs(iph->tot_len) + TCPOLEN_MSS); - iph->check = cheat_check(iph->tot_len ^ 0xFFFF, - newtotlen, iph->check); - iph->tot_len = newtotlen; - - DEBUGP(KERN_INFO "ipt_tcpmss_target: %u.%u.%u.%u:%hu" - "->%u.%u.%u.%u:%hu added TCP MSS option (%u)\n", - NIPQUAD((*pskb)->nh.iph->saddr), - ntohs(tcph->source), - NIPQUAD((*pskb)->nh.iph->daddr), - ntohs(tcph->dest), - newmss); - - retmodified: - /* We never hw checksum SYN packets. */ - BUG_ON((*pskb)->ip_summed == CHECKSUM_HW); - - (*pskb)->nfcache |= NFC_UNKNOWN | NFC_ALTERED; - return IPT_CONTINUE; -} - -#define TH_SYN 0x02 - -static inline int find_syn_match(const struct ipt_entry_match *m) -{ - const struct ipt_tcp *tcpinfo = (const struct ipt_tcp *)m->data; - - if (strcmp(m->u.kernel.match->name, "tcp") == 0 - && (tcpinfo->flg_cmp & TH_SYN) - && !(tcpinfo->invflags & IPT_TCP_INV_FLAGS)) - return 1; - - return 0; -} - -/* Must specify -p tcp --syn/--tcp-flags SYN */ -static int -ipt_tcpmss_checkentry(const char *tablename, - const struct ipt_entry *e, - void *targinfo, - unsigned int targinfosize, - unsigned int hook_mask) -{ - const struct ipt_tcpmss_info *tcpmssinfo = targinfo; - - if (targinfosize != IPT_ALIGN(sizeof(struct ipt_tcpmss_info))) { - DEBUGP("ipt_tcpmss_checkentry: targinfosize %u != %u\n", - targinfosize, IPT_ALIGN(sizeof(struct ipt_tcpmss_info))); - return 0; - } - - - if((tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU) && - ((hook_mask & ~((1 << NF_IP_FORWARD) - | (1 << NF_IP_LOCAL_OUT) - | (1 << NF_IP_POST_ROUTING))) != 0)) { - printk("TCPMSS: path-MTU clamping only supported in FORWARD, OUTPUT and POSTROUTING hooks\n"); - return 0; - } - - if (e->ip.proto == IPPROTO_TCP - && !(e->ip.invflags & IPT_INV_PROTO) - && IPT_MATCH_ITERATE(e, find_syn_match)) - return 1; - - printk("TCPMSS: Only works on TCP SYN packets\n"); - return 0; -} - -static struct ipt_target ipt_tcpmss_reg = { - .name = "TCPMSS", - .target = ipt_tcpmss_target, - .checkentry = ipt_tcpmss_checkentry, - .me = THIS_MODULE, -}; - -static int __init init(void) -{ - return ipt_register_target(&ipt_tcpmss_reg); -} - -static void __exit fini(void) -{ - ipt_unregister_target(&ipt_tcpmss_reg); -} - -module_init(init); -module_exit(fini); diff -rupN linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c.rej linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c.rej --- linux-2.6.10p/net/ipv4/netfilter/ipt_tcpmss.c.rej 2005-02-25 16:06:02.078125000 +0000 +++ linux-2.6.10/net/ipv4/netfilter/ipt_tcpmss.c.rej 1970-01-01 00:00:00.000000000 +0000 @@ -1,27 +0,0 @@ -*************** -*** 87,104 **** - info->invert, hotdrop); - } - -- static inline int find_syn_match(const struct ipt_entry_match *m) -- { -- const struct ipt_tcp *tcpinfo = (const struct ipt_tcp *)m->data; -- -- if (strcmp(m->u.kernel.match->name, "tcp") == 0 -- && (tcpinfo->flg_cmp & TH_SYN) -- && !(tcpinfo->invflags & IPT_TCP_INV_FLAGS)) -- return 1; -- -- return 0; -- } -- - static int - checkentry(const char *tablename, - const struct ipt_ip *ip, ---- 87,92 ---- - info->invert, hotdrop); - } - - static int - checkentry(const char *tablename, - const struct ipt_ip *ip, diff -rupN linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.orig linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.orig --- linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.orig 2004-08-14 11:56:25.000000000 +0100 +++ linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.orig 1970-01-01 00:00:00.000000000 +0000 @@ -1,67 +0,0 @@ -/* Kernel module to match NFMARK values. */ - -/* (C) 1999-2001 Marc Boucher - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - - -#include -#include - -#include -#include - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Netfilter Core Team "); -MODULE_DESCRIPTION("ip6tables mark match"); - -static int -match(const struct sk_buff *skb, - const struct net_device *in, - const struct net_device *out, - const void *matchinfo, - int offset, - const void *hdr, - u_int16_t datalen, - int *hotdrop) -{ - const struct ip6t_mark_info *info = matchinfo; - - return ((skb->nfmark & info->mask) == info->mark) ^ info->invert; -} - -static int -checkentry(const char *tablename, - const struct ip6t_ip6 *ip, - void *matchinfo, - unsigned int matchsize, - unsigned int hook_mask) -{ - if (matchsize != IP6T_ALIGN(sizeof(struct ip6t_mark_info))) - return 0; - - return 1; -} - -static struct ip6t_match mark_match = { - .name = "mark", - .match = &match, - .checkentry = &checkentry, - .me = THIS_MODULE, -}; - -static int __init init(void) -{ - return ip6t_register_match(&mark_match); -} - -static void __exit fini(void) -{ - ip6t_unregister_match(&mark_match); -} - -module_init(init); -module_exit(fini); diff -rupN linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej --- linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej 2005-02-25 16:06:04.781250000 +0000 +++ linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej 1970-01-01 00:00:00.000000000 +0000 @@ -1,21 +0,0 @@ -*************** -*** 20,28 **** - - static unsigned int - target(struct sk_buff **pskb, -- unsigned int hooknum, - const struct net_device *in, - const struct net_device *out, - const void *targinfo, - void *userinfo) - { ---- 20,28 ---- - - static unsigned int - target(struct sk_buff **pskb, - const struct net_device *in, - const struct net_device *out, -+ unsigned int hooknum, - const void *targinfo, - void *userinfo) - { ------------------------------------------------------------------------ Regards Mark Fortescue. From parklee_sel@yahoo.com Fri Feb 25 08:47:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 08:47:23 -0800 (PST) Received: from web51509.mail.yahoo.com (web51509.mail.yahoo.com [206.190.38.201]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1PGlJQ3006563 for ; Fri, 25 Feb 2005 08:47:19 -0800 Received: (qmail 67000 invoked by uid 60001); 25 Feb 2005 16:47:09 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=5dy2EKAs7Zy6Uhd7hmWy0+V67ZgyyL4QiV12omPsOlZexXf/nIW2OlxQhgPqmSHymfXMPNU1TkRtQm93TfYFfTQw+7KX8UoiPzhJ5NSaMGI54g8OY7mJau7pTjgSFOu30Osn4SYZzmWYT1SMBg7m4ao7H+7TDXzCHMus4ZE8VyA= ; Message-ID: <20050225164709.66998.qmail@web51509.mail.yahoo.com> Received: from [221.15.137.250] by web51509.mail.yahoo.com via HTTP; Fri, 25 Feb 2005 08:47:09 PST Date: Fri, 25 Feb 2005 08:47:09 -0800 (PST) From: Park Lee Subject: Are there any explanation for struct flowi? To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2055 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 345 Lines: 16 Hi, I'm now learning the net stack of Linux. Would you please tell whether there are any explanation for struct flowi? What it is used for? Thank you. ===== Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rlrevell@joe-job.com Fri Feb 25 08:47:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 08:47:31 -0800 (PST) Received: from mustang.oldcity.dca.net (mustang.oldcity.dca.net [216.158.38.3]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1PGlPGq006600 for ; Fri, 25 Feb 2005 08:47:26 -0800 Received: (qmail 15836 invoked from network); 25 Feb 2005 16:47:25 -0000 Received: from unknown (HELO krustophenia.net) (207.245.115.154) by mustang with SMTP; 25 Feb 2005 16:47:25 -0000 Subject: Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues. From: Lee Revell To: Mark Fortescue Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 25 Feb 2005 11:47:23 -0500 Message-Id: <1109350044.9681.26.camel@krustophenia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rlrevell@joe-job.com Precedence: bulk X-list: netdev Content-Length: 416 Lines: 14 On Fri, 2005-02-25 at 16:40 +0000, Mark Fortescue wrote: > Hi all, > > I am not sure exactly where to send this email. A have chosen the > ip4/ip6 networking as the issues are in this area of the kernel. > > The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be > correct. No, you're doing it wrong. 2.6.8.1 was a bugfix release. The correct patching order is 2.6.8 -> 2.6.9 -> 2.6.10. Lee From parklee_sel@yahoo.com Fri Feb 25 08:52:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 08:52:50 -0800 (PST) Received: from web51502.mail.yahoo.com (web51502.mail.yahoo.com [206.190.38.194]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1PGqkMN007793 for ; Fri, 25 Feb 2005 08:52:46 -0800 Received: (qmail 69378 invoked by uid 60001); 25 Feb 2005 16:52:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=UiOy+FicfasDxByUf3m06zqua1Fi5NqXIi/++52J9K0GyMzXV+q/DEpg//rts/N3iTvY4LWuWJV6Djd5gS6sg3xWVjORNeghRKgVukix5tBHuke90SdsVmDDe15WIDBo0c6bNM2+5aQeHO+/cHa9mMTR/JPhAF+9TsazL3JCWQc= ; Message-ID: <20050225165240.69376.qmail@web51502.mail.yahoo.com> Received: from [221.15.137.250] by web51502.mail.yahoo.com via HTTP; Fri, 25 Feb 2005 08:52:40 PST Date: Fri, 25 Feb 2005 08:52:40 -0800 (PST) From: Park Lee Subject: What's the purpose of ip_route_output_flow()? To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2057 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 345 Lines: 16 Hi, Would you please tell me what the purpose of ip_route_output_flow() is? and What the differences between it and ip_route_output_key() are? Thank you. ===== Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tim@physik3.uni-rostock.de Fri Feb 25 09:12:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 09:13:00 -0800 (PST) Received: from gockel.physik3.uni-rostock.de ([139.30.44.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PHCsZT009085 for ; Fri, 25 Feb 2005 09:12:56 -0800 Received: from gockel.physik3.uni-rostock.de (localhost [127.0.0.1]) by gockel.physik3.uni-rostock.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j1PHCCSu001232; Fri, 25 Feb 2005 18:12:12 +0100 Received: from localhost (tim@localhost) by gockel.physik3.uni-rostock.de (8.12.7/8.12.7/Submit) with ESMTP id j1PHCCj8001229; Fri, 25 Feb 2005 18:12:12 +0100 X-Authentication-Warning: gockel.physik3.uni-rostock.de: tim owned process doing -bs Date: Fri, 25 Feb 2005 18:12:12 +0100 (CET) From: Tim Schmielau To: Mark Fortescue cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, lkml Subject: Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tim@physik3.uni-rostock.de Precedence: bulk X-list: netdev Content-Length: 1517 Lines: 39 On Fri, 25 Feb 2005, Mark Fortescue wrote: > The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be > correct. I had some errors during patching so I generated a diff against a > freshly downloaded linux-2.6.10 kernel. See the steps below: > > 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - > 2) cd linux-2.6.8.1 > 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 > This gives a 2.6.8 kernel. > > 4) bzcat ../patch-2.6.9.bz2 | patch -p1 > This should give a 2.6.9 kernel. The patch has two errors: > ./net/ipv4/netfilter/ipt_ecn.c.rej > ./net/ipv4/netfilter/ipt_tcpmss.c.rej > > 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f > This should give a 2.6.10 kernel. The patch has three erros: > ./include/linux/netfilter_ipv4/ipt_connmark.h.rej > ./net/ipv4/netfilter/ipt_connmark.c.rej > ./net/ipv6/netfilter/ip6t_MARK.c.rej > 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p > 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - > 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err Yes, these steps should work. Actually, I just checked (copy & paste the commands from your mail), and it works for me. Are you sure your files are ok? md5sums for my copies of the files are cffcd2919d9c8ef793ce1ac07a440eda linux-2.6.10.tar.bz2 98f93075c7c24e681eaf7e70783af5e4 linux-2.6.8.1.tar.gz 98b7db13a3f13199a48e89a79d2ee388 patch-2.6.10.bz2 824b7d88ab2fabc031f1a6c1e6e288ee patch-2.6.8.1.bz2 fe744cdcd31b97b803e51ad785520489 patch-2.6.9.bz2 Are you sure your filesystem works ok? Not out of quota? Tim From mark@mtfhpc.demon.co.uk Fri Feb 25 09:53:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 09:53:42 -0800 (PST) Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PHrbEP011453 for ; Fri, 25 Feb 2005 09:53:37 -0800 Received: from mtfhpc.demon.co.uk ([83.104.139.140]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1D4jee-000JRt-LB; Fri, 25 Feb 2005 17:53:32 +0000 Received: from localhost (mark@localhost) by mtfhpc.demon.co.uk (8.9.3/8.9.3) with ESMTP id RAA26450; Fri, 25 Feb 2005 17:53:29 GMT Date: Fri, 25 Feb 2005 17:53:28 +0000 (GMT) From: Mark Fortescue To: Tim Schmielau cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, lkml Subject: Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2059 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mark@mtfhpc.demon.co.uk Precedence: bulk X-list: netdev Content-Length: 2196 Lines: 58 Hi, Sorry for the trouble. I have worked out what is going on. I have been using Cygwin, but I has assumed incorrectly that MS WindowsXP SP2, like MS Windows 2000, honered mixed case filenames correctly. This is not the case making MS WindowsXP SP2 Pro non POSIX complient (what a supprise). A quick google search sugests that I am not the only person to have issues with this. Is there any chance that at some point in the future, the kernel filenames will be changed so that dumb OS like MS Windows don't mess it all up ? Regards Mark Fortescue. On Fri, 25 Feb 2005, Tim Schmielau wrote: > On Fri, 25 Feb 2005, Mark Fortescue wrote: > > > The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be > > correct. I had some errors during patching so I generated a diff against a > > freshly downloaded linux-2.6.10 kernel. See the steps below: > > > > 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - > > 2) cd linux-2.6.8.1 > > 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 > > This gives a 2.6.8 kernel. > > > > 4) bzcat ../patch-2.6.9.bz2 | patch -p1 > > This should give a 2.6.9 kernel. The patch has two errors: > > ./net/ipv4/netfilter/ipt_ecn.c.rej > > ./net/ipv4/netfilter/ipt_tcpmss.c.rej > > > > 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f > > This should give a 2.6.10 kernel. The patch has three erros: > > ./include/linux/netfilter_ipv4/ipt_connmark.h.rej > > ./net/ipv4/netfilter/ipt_connmark.c.rej > > ./net/ipv6/netfilter/ip6t_MARK.c.rej > > 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p > > 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - > > 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err > > Yes, these steps should work. Actually, I just checked (copy & paste the > commands from your mail), and it works for me. > > Are you sure your files are ok? md5sums for my copies of the files are > > cffcd2919d9c8ef793ce1ac07a440eda linux-2.6.10.tar.bz2 > 98f93075c7c24e681eaf7e70783af5e4 linux-2.6.8.1.tar.gz > 98b7db13a3f13199a48e89a79d2ee388 patch-2.6.10.bz2 > 824b7d88ab2fabc031f1a6c1e6e288ee patch-2.6.8.1.bz2 > fe744cdcd31b97b803e51ad785520489 patch-2.6.9.bz2 > > Are you sure your filesystem works ok? Not out of quota? > > Tim > From dima@neterion.com Fri Feb 25 11:18:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 11:18:16 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PJIBjx024322 for ; Fri, 25 Feb 2005 11:18:12 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j1PJI0dG027273; Fri, 25 Feb 2005 14:18:00 -0500 (EST) Received: from beastie ([10.16.16.220]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j1PJHwDD025114; Fri, 25 Feb 2005 14:17:59 -0500 (EST) Subject: Re: UDP optimization From: Dmitry Yusupov To: shabanip Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <46548.69.93.110.242.1109328682.squirrel@69.93.110.242> References: <46548.69.93.110.242.1109328682.squirrel@69.93.110.242> Content-Type: text/plain Organization: Neterion, Inc Date: Fri, 25 Feb 2005 11:17:57 -0800 Message-Id: <1109359077.13087.64.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2060 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dima@neterion.com Precedence: bulk X-list: netdev Content-Length: 572 Lines: 22 As far as UDP HW acceleration is concerned we need to modify/verify that Linux TCP/IP stack capable of: 1) Partial checksumming on receive 2) Checksumming over fragments on transmit And find the NIC which capable of doing that. s2io/neterion hw do supports those features. Regards, Dima Without those two, I doubt you will On Fri, 2005-02-25 at 14:21 +0330, shabanip wrote: > as i know there are many ways to optimize and tune TCP parameters in kernel > but how can i tune and optimize UDp performance? > thanks, > Payam Shabanian > shabanip -at- avapajoohesh.com From jgarzik@pobox.com Fri Feb 25 11:31:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 11:31:18 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PJV6lL002046 for ; Fri, 25 Feb 2005 11:31:06 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4lAz-0008BN-Hk; Fri, 25 Feb 2005 19:31:02 +0000 Message-ID: <421F7CE7.4060507@pobox.com> Date: Fri, 25 Feb 2005 14:30:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev Subject: [BK PATCHES] 2.6.x e1000, ixgb fixes Content-Type: multipart/mixed; boundary="------------050504090709060508080307" X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2061 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: 39379 Lines: 1132 This is a multi-part message in MIME format. --------------050504090709060508080307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See attached. --------------050504090709060508080307 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 - drivers/net/e1000/e1000_hw.c | 86 ++++++------- drivers/net/e1000/e1000_hw.h | 11 + drivers/net/e1000/e1000_main.c | 249 ++++++++++++++++++++++++++++++++++---- drivers/net/ixgb/ixgb.h | 3 drivers/net/ixgb/ixgb_ee.c | 16 +- drivers/net/ixgb/ixgb_ee.h | 3 drivers/net/ixgb/ixgb_ethtool.c | 5 drivers/net/ixgb/ixgb_hw.c | 2 drivers/net/ixgb/ixgb_hw.h | 2 drivers/net/ixgb/ixgb_ids.h | 2 drivers/net/ixgb/ixgb_main.c | 73 ++++++----- drivers/net/ixgb/ixgb_osdep.h | 2 drivers/net/ixgb/ixgb_param.c | 2 15 files changed, 354 insertions(+), 116 deletions(-) through these ChangeSets: : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: use netif_poll_{enable|disable} o e1000: Robert Olsson's fix and refinement o ixgb: Driver version, white space, other stuff o ixgb: Invalidate software cache, when EEPROM write occurs o ixgb: Robert Olsson's fix and refinement to poll o ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq o ixgb: use netif_poll_{enable|disable} --------------050504090709060508080307 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h --- a/drivers/net/e1000/e1000.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/e1000/e1000.h 2005-02-25 14:29:12 -05:00 @@ -138,6 +138,7 @@ #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ #define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0004 #define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE @@ -209,6 +210,7 @@ /* TX */ struct e1000_desc_ring tx_ring; + struct e1000_buffer previous_buffer_info; spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; @@ -222,6 +224,7 @@ uint32_t tx_fifo_size; atomic_t tx_fifo_stall; boolean_t pcix_82544; + boolean_t detect_tx_hung; /* RX */ struct e1000_desc_ring rx_ring; diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2005-02-25 14:29:12 -05:00 @@ -1310,7 +1310,7 @@ struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i; + int i, ret_val; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); @@ -1330,11 +1330,12 @@ rxdr->buffer_info[i].length, PCI_DMA_FROMDEVICE); - if (!e1000_check_lbtest_frame(rxdr->buffer_info[i++].skb, 1024)) - return 0; - } while (i < 64); + ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, + 1024); + i++; + } while (ret_val != 0 && i < 64); - return 13; + return ret_val; } static int diff -Nru a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c --- a/drivers/net/e1000/e1000_hw.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/e1000/e1000_hw.c 2005-02-25 14:29:12 -05:00 @@ -1572,7 +1572,8 @@ if(mii_status_reg & MII_SR_LINK_STATUS) break; msec_delay(100); } - if((i == 0) && (hw->phy_type == e1000_phy_m88)) { + if((i == 0) && + (hw->phy_type == e1000_phy_m88)) { /* We didn't get link. Reset the DSP and wait again for link. */ ret_val = e1000_phy_reset_dsp(hw); if(ret_val) { @@ -2503,7 +2504,7 @@ } } - ret_val = e1000_read_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_read_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2609,7 +2610,7 @@ } } - ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_write_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2955,8 +2956,7 @@ /* Check polarity status */ ret_val = e1000_check_polarity(hw, &polarity); if(ret_val) - return ret_val; - + return ret_val; phy_info->cable_polarity = polarity; ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); @@ -2966,9 +2966,9 @@ phy_info->mdix_mode = (phy_data & M88E1000_PSSR_MDIX) >> M88E1000_PSSR_MDIX_SHIFT; - if(phy_data & M88E1000_PSSR_1000MBS) { - /* Cable Length Estimation and Local/Remote Receiver Informatoion - * are only valid at 1000 Mbps + if ((phy_data & M88E1000_PSSR_SPEED) == M88E1000_PSSR_1000MBS) { + /* Cable Length Estimation and Local/Remote Receiver Information + * are only valid at 1000 Mbps. */ phy_info->cable_length = ((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> M88E1000_PSSR_CABLE_LENGTH_SHIFT); @@ -4639,41 +4639,44 @@ { uint32_t status; - if(hw->mac_type < e1000_82543) { + switch (hw->mac_type) { + case e1000_82542_rev2_0: + case e1000_82542_rev2_1: hw->bus_type = e1000_bus_type_unknown; hw->bus_speed = e1000_bus_speed_unknown; hw->bus_width = e1000_bus_width_unknown; - return; - } - - status = E1000_READ_REG(hw, STATUS); - hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? - e1000_bus_type_pcix : e1000_bus_type_pci; + break; + default: + status = E1000_READ_REG(hw, STATUS); + hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? + e1000_bus_type_pcix : e1000_bus_type_pci; - if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { - hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? - e1000_bus_speed_66 : e1000_bus_speed_120; - } else if(hw->bus_type == e1000_bus_type_pci) { - hw->bus_speed = (status & E1000_STATUS_PCI66) ? - e1000_bus_speed_66 : e1000_bus_speed_33; - } else { - switch (status & E1000_STATUS_PCIX_SPEED) { - case E1000_STATUS_PCIX_SPEED_66: - hw->bus_speed = e1000_bus_speed_66; - break; - case E1000_STATUS_PCIX_SPEED_100: - hw->bus_speed = e1000_bus_speed_100; - break; - case E1000_STATUS_PCIX_SPEED_133: - hw->bus_speed = e1000_bus_speed_133; - break; - default: - hw->bus_speed = e1000_bus_speed_reserved; - break; + if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { + hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? + e1000_bus_speed_66 : e1000_bus_speed_120; + } else if(hw->bus_type == e1000_bus_type_pci) { + hw->bus_speed = (status & E1000_STATUS_PCI66) ? + e1000_bus_speed_66 : e1000_bus_speed_33; + } else { + switch (status & E1000_STATUS_PCIX_SPEED) { + case E1000_STATUS_PCIX_SPEED_66: + hw->bus_speed = e1000_bus_speed_66; + break; + case E1000_STATUS_PCIX_SPEED_100: + hw->bus_speed = e1000_bus_speed_100; + break; + case E1000_STATUS_PCIX_SPEED_133: + hw->bus_speed = e1000_bus_speed_133; + break; + default: + hw->bus_speed = e1000_bus_speed_reserved; + break; + } } + hw->bus_width = (status & E1000_STATUS_BUS64) ? + e1000_bus_width_64 : e1000_bus_width_32; + break; } - hw->bus_width = (status & E1000_STATUS_BUS64) ? - e1000_bus_width_64 : e1000_bus_width_32; } /****************************************************************************** * Reads a value from one of the devices registers using port I/O (as opposed @@ -4738,6 +4741,7 @@ uint16_t agc_value = 0; uint16_t cur_agc, min_agc = IGP01E1000_AGC_LENGTH_TABLE_SIZE; uint16_t i, phy_data; + uint16_t cable_length; DEBUGFUNC("e1000_get_cable_length"); @@ -4749,10 +4753,11 @@ &phy_data); if(ret_val) return ret_val; + cable_length = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >> + M88E1000_PSSR_CABLE_LENGTH_SHIFT; /* Convert the enum value to ranged values */ - switch((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> - M88E1000_PSSR_CABLE_LENGTH_SHIFT) { + switch (cable_length) { case e1000_cable_length_50: *min_length = 0; *max_length = e1000_igp_cable_length_50; @@ -4919,8 +4924,7 @@ return ret_val; hw->speed_downgraded = (phy_data & IGP01E1000_PLHR_SS_DOWNGRADE) ? 1 : 0; - } - else if(hw->phy_type == e1000_phy_m88) { + } else if(hw->phy_type == e1000_phy_m88) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); if(ret_val) diff -Nru a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h --- a/drivers/net/e1000/e1000_hw.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/e1000/e1000_hw.h 2005-02-25 14:29:12 -05:00 @@ -369,6 +369,7 @@ #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 + #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 @@ -1734,6 +1735,9 @@ #define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */ #define PHY_EXT_STATUS 0x0F /* Extended Status Reg */ +#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ +#define MAX_PHY_MULTI_PAGE_REG 0xF /* Registers equal on all pages */ + /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ #define M88E1000_PHY_SPEC_STATUS 0x11 /* PHY Specific Status Register */ @@ -1794,8 +1798,7 @@ #define IGP01E1000_ANALOG_REGS_PAGE 0x20C0 -#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ -#define MAX_PHY_MULTI_PAGE_REG 0xF /*Registers that are equal on all pages*/ + /* PHY Control Register */ #define MII_CR_SPEED_SELECT_MSB 0x0040 /* bits 6,13: 10=1000, 01=100, 00=10 */ #define MII_CR_COLL_TEST_ENABLE 0x0080 /* Collision test enable */ @@ -2098,7 +2101,11 @@ #define IGP01E1000_ANALOG_FUSE_FINE_1 0x0080 #define IGP01E1000_ANALOG_FUSE_FINE_10 0x0500 + /* Bit definitions for valid PHY IDs. */ +/* I = Integrated + * E = External + */ #define M88E1000_E_PHY_ID 0x01410C50 #define M88E1000_I_PHY_ID 0x01410C30 #define M88E1011_I_PHY_ID 0x01410C20 diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/e1000/e1000_main.c 2005-02-25 14:29:12 -05:00 @@ -35,6 +35,14 @@ * - More errlogging support from Jon Mason * - Fix TSO issues on PPC64 machines -- Jon Mason * + * 5.7.1 12/16/04 + * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This + * fix was removed as it caused system instability. The suspected cause of + * this is the called to e1000_irq_disable in e1000_intr. Inlined the + * required piece of e1000_irq_disable into e1000_intr - Anton Blanchard + * 5.7.0 12/10/04 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 5.6.5 11/01/04 * - Enabling NETIF_F_SG without checksum offload is illegal - John Mason @@ -57,7 +65,7 @@ #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.6.10.1-k2"DRIVERNAPI; +char e1000_driver_version[] = "5.7.6-k2"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -81,6 +89,7 @@ INTEL_E1000_ETHERNET_DEVICE(0x1011), INTEL_E1000_ETHERNET_DEVICE(0x1012), INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1014), INTEL_E1000_ETHERNET_DEVICE(0x1015), INTEL_E1000_ETHERNET_DEVICE(0x1016), INTEL_E1000_ETHERNET_DEVICE(0x1017), @@ -308,6 +317,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); +#ifdef CONFIG_E1000_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -321,6 +333,10 @@ del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); + +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); @@ -414,6 +430,7 @@ int i; int err; uint16_t eeprom_data; + uint16_t eeprom_apme_mask = E1000_EEPROM_APME; if((err = pci_enable_device(pdev))) return err; @@ -510,9 +527,6 @@ } #ifdef NETIF_F_TSO - /* Disbaled for now until root-cause is found for - * hangs reported against non-IA archs. TSO can be - * enabled using ethtool -K eth tso on */ if((adapter->hw.mac_type >= e1000_82544) && (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; @@ -584,6 +598,11 @@ case e1000_82542_rev2_1: case e1000_82543: break; + case e1000_82544: + e1000_read_eeprom(&adapter->hw, + EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data); + eeprom_apme_mask = E1000_EEPROM_82544_APM; + break; case e1000_82546: case e1000_82546_rev_3: if((E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_FUNC_1) @@ -598,7 +617,7 @@ EEPROM_INIT_CONTROL3_PORT_A, 1, &eeprom_data); break; } - if(eeprom_data & E1000_EEPROM_APME) + if(eeprom_data & eeprom_apme_mask) adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ @@ -807,6 +826,31 @@ } /** + * e1000_check_64k_bound - check that memory doesn't cross 64kB boundary + * @adapter: address of board private structure + * @begin: address of beginning of memory + * @end: address of end of memory + **/ +static inline boolean_t +e1000_check_64k_bound(struct e1000_adapter *adapter, + void *start, unsigned long len) +{ + unsigned long begin = (unsigned long) start; + unsigned long end = begin + len; + + /* first rev 82545 and 82546 need to not allow any memory + * write location to cross a 64k boundary due to errata 23 */ + if (adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546 ) { + + /* check buffer doesn't cross 64kB */ + return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; + } + + return TRUE; +} + +/** * e1000_setup_tx_resources - allocate Tx resources (Descriptors) * @adapter: board private structure * @@ -824,7 +868,7 @@ txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -836,11 +880,42 @@ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { +setup_tx_desc_die: DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + void *olddesc = txdr->desc; + dma_addr_t olddma = txdr->dma; + DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", + txdr->size, txdr->desc); + /* try again, without freeing the previous */ + txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); + /* failed allocation, critial failure */ + if(!txdr->desc) { + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + goto setup_tx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + /* give up */ + pci_free_consistent(pdev, txdr->size, + txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the Transmit" + " descriptor ring\n"); + vfree(txdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + } + } memset(txdr->desc, 0, txdr->size); txdr->next_to_use = 0; @@ -945,7 +1020,7 @@ rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Recieve descriptor ring\n"); + "Unable to Allocate Memory for the Recieve descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -958,11 +1033,43 @@ rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { +setup_rx_desc_die: DPRINTK(PROBE, ERR, "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + void *olddesc = rxdr->desc; + dma_addr_t olddma = rxdr->dma; + DPRINTK(RX_ERR,ERR, + "rxdr align check failed: %u bytes at %p\n", + rxdr->size, rxdr->desc); + /* try again, without freeing the previous */ + rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); + /* failed allocation, critial failure */ + if(!rxdr->desc) { + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + goto setup_rx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + /* give up */ + pci_free_consistent(pdev, rxdr->size, + rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the" + " Receive descriptor ring\n"); + vfree(rxdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + } + } memset(rxdr->desc, 0, rxdr->size); rxdr->next_to_clean = 0; @@ -1096,6 +1203,7 @@ struct e1000_buffer *buffer_info) { struct pci_dev *pdev = adapter->pdev; + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, @@ -1124,6 +1232,11 @@ /* Free all the Tx ring sk_buffs */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(i = 0; i < tx_ring->count; i++) { buffer_info = &tx_ring->buffer_info[i]; e1000_unmap_and_free_tx_resource(adapter, buffer_info); @@ -1425,7 +1538,6 @@ struct e1000_adapter *adapter = (struct e1000_adapter *) data; struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; uint32_t link; e1000_check_for_link(&adapter->hw); @@ -1505,12 +1617,8 @@ /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period*/ + adapter->detect_tx_hung = TRUE; /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -2151,10 +2259,28 @@ __netif_rx_schedule(netdev); } #else + /* Writing IMC and IMS is needed for 82547. + Due to Hub Link bus being occupied, an interrupt + de-assertion message is not able to be sent. + When an interrupt assertion message is generated later, + two messages are re-ordered and sent out. + That causes APIC to think 82547 is in de-assertion + state, while 82547 is in assertion state, resulting + in dead lock. Writing IMC forces 82547 into + de-assertion state. + */ + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + } + for(i = 0; i < E1000_MAX_INTR; i++) if(unlikely(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter))) break; + + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) + e1000_irq_enable(adapter); #endif return IRQ_HANDLED; @@ -2174,24 +2300,21 @@ int tx_cleaned; int work_done = 0; - if (!netif_carrier_ok(netdev)) - goto quit_polling; - tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - /* if no Rx and Tx cleanup work was done, exit the polling mode */ - if(!tx_cleaned || (work_done < work_to_do) || + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done < work_to_do)) || !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; } - return (work_done >= work_to_do); + return 1; } #endif @@ -2215,11 +2338,34 @@ eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { + /* pre-mature writeback of Tx descriptors */ + /* clear (free buffers and unmap pci_mapping) */ + /* previous_buffer_info */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; + cleaned = (i == eop); + + /* pre-mature writeback of Tx descriptors */ + /* save the cleaning of the this for the */ + /* next iteration */ + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, + 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); + } - e1000_unmap_and_free_tx_resource(adapter, buffer_info); tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; tx_desc->upper.data = 0; @@ -2241,6 +2387,16 @@ netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } @@ -2407,19 +2563,43 @@ struct e1000_rx_desc *rx_desc; struct e1000_buffer *buffer_info; struct sk_buff *skb; - unsigned int i; + unsigned int i, bufsz; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); + bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; + skb = dev_alloc_skb(bufsz); if(unlikely(!skb)) { /* Better luck next round */ break; } + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + struct sk_buff *oldskb = skb; + DPRINTK(RX_ERR,ERR, + "skb align check failed: %u bytes at %p\n", + bufsz, skb->data); + /* try again, without freeing the previous */ + skb = dev_alloc_skb(bufsz); + if (!skb) { + dev_kfree_skb(oldskb); + break; + } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + /* give up */ + dev_kfree_skb(skb); + dev_kfree_skb(oldskb); + break; /* while !buffer_info->skb */ + } else { + /* move on with the new one */ + dev_kfree_skb(oldskb); + } + } + /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -2434,6 +2614,25 @@ skb->data, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + + /* fix for errata 23, cant cross 64kB boundary */ + if(!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR,ERR, + "dma align check failed: %u bytes at %ld\n", + adapter->rx_buffer_len, (unsigned long)buffer_info->dma); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); diff -Nru a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h --- a/drivers/net/ixgb/ixgb.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb.h 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -176,6 +176,7 @@ uint64_t hw_csum_tx_error; uint32_t tx_int_delay; boolean_t tx_int_delay_enable; + boolean_t detect_tx_hung; /* RX */ struct ixgb_desc_ring rx_ring; diff -Nru a/drivers/net/ixgb/ixgb_ee.c b/drivers/net/ixgb/ixgb_ee.c --- a/drivers/net/ixgb/ixgb_ee.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_ee.c 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -372,11 +372,11 @@ * *****************************************************************************/ void -ixgb_write_eeprom(struct ixgb_hw *hw, - uint16_t offset, - uint16_t data) +ixgb_write_eeprom(struct ixgb_hw *hw, uint16_t offset, uint16_t data) { - /* Prepare the EEPROM for writing */ + struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; + + /* Prepare the EEPROM for writing */ ixgb_setup_eeprom(hw); /* Send the 9-bit EWEN (write enable) command to the EEPROM (5-bit opcode @@ -410,6 +410,9 @@ /* Done with writing */ ixgb_cleanup_eeprom(hw); + /* clear the init_ctrl_reg_1 to signify that the cache is invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; + return; } @@ -478,6 +481,9 @@ if (checksum != (uint16_t) EEPROM_SUM) { DEBUGOUT("ixgb_ee: Checksum invalid.\n"); + /* clear the init_ctrl_reg_1 to signify that the cache is + * invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; return (FALSE); } diff -Nru a/drivers/net/ixgb/ixgb_ee.h b/drivers/net/ixgb/ixgb_ee.h --- a/drivers/net/ixgb/ixgb_ee.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_ee.h 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -63,6 +63,7 @@ #define EEPROM_ICW1_SIGNATURE_MASK 0xC000 #define EEPROM_ICW1_SIGNATURE_VALID 0x4000 +#define EEPROM_ICW1_SIGNATURE_CLEAR 0x0000 /* For checksumming, the sum of all words in the EEPROM should equal 0xBABA. */ #define EEPROM_SUM 0xBABA diff -Nru a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c --- a/drivers/net/ixgb/ixgb_ethtool.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_ethtool.c 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -63,6 +63,7 @@ {"tx_dropped", IXGB_STAT(net_stats.tx_dropped)}, {"multicast", IXGB_STAT(net_stats.multicast)}, {"collisions", IXGB_STAT(net_stats.collisions)}, + /* { "rx_length_errors", IXGB_STAT(net_stats.rx_length_errors) }, */ {"rx_over_errors", IXGB_STAT(net_stats.rx_over_errors)}, {"rx_crc_errors", IXGB_STAT(net_stats.rx_crc_errors)}, @@ -98,6 +99,7 @@ ixgb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + ecmd->supported = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->advertising = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->port = PORT_FIBRE; @@ -119,6 +121,7 @@ ixgb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + if(ecmd->autoneg == AUTONEG_ENABLE || ecmd->speed + ecmd->duplex != SPEED_10000 + DUPLEX_FULL) return -EINVAL; diff -Nru a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c --- a/drivers/net/ixgb/ixgb_hw.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_hw.c 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_hw.h b/drivers/net/ixgb/ixgb_hw.h --- a/drivers/net/ixgb/ixgb_hw.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_hw.h 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_ids.h b/drivers/net/ixgb/ixgb_ids.h --- a/drivers/net/ixgb/ixgb_ids.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_ids.h 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c --- a/drivers/net/ixgb/ixgb_main.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_main.c 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -29,6 +29,9 @@ #include "ixgb.h" /* Change Log + * 1.0.88 01/05/05 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 1.0.84 10/26/04 * - reset buffer_info->dma in Tx resource cleanup logic * 1.0.83 10/12/04 @@ -38,13 +41,14 @@ char ixgb_driver_name[] = "ixgb"; char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; + #ifndef CONFIG_IXGB_NAPI #define DRIVERNAPI #else #define DRIVERNAPI "-NAPI" #endif -char ixgb_driver_version[] = "1.0.87-k2"DRIVERNAPI; -char ixgb_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table * @@ -292,6 +296,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); ixgb_irq_enable(adapter); +#ifdef CONFIG_IXGB_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -309,6 +316,9 @@ #endif if(kill_watchdog) del_timer_sync(&adapter->watchdog_timer); +#ifdef CONFIG_IXGB_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); @@ -709,14 +719,8 @@ IXGB_WRITE_REG(hw, TDH, 0); IXGB_WRITE_REG(hw, TDT, 0); - /* don't set up txdctl, it induces performance problems if - * configured incorrectly - txdctl = TXDCTL_PTHRESH_DEFAULT; // prefetch txds below this threshold - txdctl |= (TXDCTL_HTHRESH_DEFAULT // only prefetch if there are this many ready - << IXGB_TXDCTL_HTHRESH_SHIFT); - IXGB_WRITE_REG (hw, TXDCTL, txdctl); - */ - + /* don't set up txdctl, it induces performance problems if configured + * incorrectly */ /* Set the Tx Interrupt Delay register */ IXGB_WRITE_REG(hw, TIDV, adapter->tx_int_delay); @@ -849,10 +853,17 @@ IXGB_WRITE_REG(hw, RDH, 0); IXGB_WRITE_REG(hw, RDT, 0); - /* burst 16 or burst when RXT0*/ - rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT - | RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT - | RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; + /* set up pre-fetching of receive buffers so we get some before we + * run out (default hardware behavior is to run out before fetching + * more). This sets up to fetch if HTHRESH rx descriptors are avail + * and the descriptors in hw cache are below PTHRESH. This avoids + * the hardware behavior of fetching <=512 descriptors in a single + * burst that pre-empts all other activity, usually causing fifo + * overflows. */ + /* use WTHRESH to burst write 16 descriptors or burst when RXT0 */ + rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT | + RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT | + RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; IXGB_WRITE_REG(hw, RXDCTL, rxdctl); /* Enable Receive Checksum Offload for TCP and UDP */ @@ -1094,7 +1105,6 @@ struct ixgb_adapter *adapter = (struct ixgb_adapter *)data; struct net_device *netdev = adapter->netdev; struct ixgb_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; ixgb_check_for_link(&adapter->hw); @@ -1137,12 +1147,8 @@ } } - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(IXGB_READ_REG(&adapter->hw, STATUS) & IXGB_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period */ + adapter->detect_tx_hung = TRUE; /* generate an interrupt to force clean up of any stragglers */ IXGB_WRITE_REG(&adapter->hw, ICS, IXGB_INT_TXDW); @@ -1668,20 +1674,16 @@ int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; - - if (!netif_carrier_ok(netdev)) - goto quit_polling; tx_cleaned = ixgb_clean_tx_irq(adapter); ixgb_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - - /* if no Tx cleanup and not enough Rx work done, exit the polling mode */ - if((!tx_cleaned && (work_done < work_to_do)) || - !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { + netif_rx_complete(netdev); ixgb_irq_enable(adapter); return 0; } @@ -1741,6 +1743,17 @@ netif_wake_queue(netdev); } spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) + && !(IXGB_READ_REG(&adapter->hw, STATUS) & + IXGB_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } diff -Nru a/drivers/net/ixgb/ixgb_osdep.h b/drivers/net/ixgb/ixgb_osdep.h --- a/drivers/net/ixgb/ixgb_osdep.h 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_osdep.h 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c --- a/drivers/net/ixgb/ixgb_param.c 2005-02-25 14:29:12 -05:00 +++ b/drivers/net/ixgb/ixgb_param.c 2005-02-25 14:29:12 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free --------------050504090709060508080307-- From jchapman@katalix.com Fri Feb 25 13:20:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Feb 2005 13:20:19 -0800 (PST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PLKD8H009576 for ; Fri, 25 Feb 2005 13:20:13 -0800 Received: from [84.92.108.75] (helo=[192.168.1.10]) by ptb-relay01.plus.net with esmtp (Exim) id 1D4msY-000PTn-IX; Fri, 25 Feb 2005 21:20:06 +0000 Message-ID: <421F9685.5090109@katalix.com> Date: Fri, 25 Feb 2005 21:20:05 +0000 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Netdev CC: Jeff Garzik Subject: [PATCH: 2.6.11-rc5 netdev-2.6] mii: add GigE support References: <421B466C.4010902@katalix.com> In-Reply-To: <421B466C.4010902@katalix.com> Content-Type: multipart/mixed; boundary="------------090905080402050506000709" X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2062 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 10483 Lines: 263 This is a multi-part message in MIME format. --------------090905080402050506000709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Add support for GigE PHYs in MII support library. This patch allows GigE drivers to use the MII library the same way 10/100 drivers do. Since the MII library is already used by lots of network drivers and the GigE MII register bit definitions were reserved when many 10/100 PHYs were designed, the new GigE registers are accessed only if a driver specifically enables it. Existing 10/100 drivers should see no behavior differences with this change. Signed-off-by: James Chapman --------------090905080402050506000709 Content-Type: text/plain; name="mii.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mii.patch" diff -Nru a/drivers/net/mii.c b/drivers/net/mii.c --- a/drivers/net/mii.c 2005-02-25 21:12:07 +00:00 +++ b/drivers/net/mii.c 2005-02-25 21:12:07 +00:00 @@ -37,6 +37,7 @@ { struct net_device *dev = mii->dev; u32 advert, bmcr, lpa, nego; + u32 advert2 = 0, bmcr2 = 0, lpa2 = 0; ecmd->supported = (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | @@ -54,6 +55,9 @@ ecmd->advertising = ADVERTISED_TP | ADVERTISED_MII; advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); + if (mii->supports_gmii) + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + if (advert & ADVERTISE_10HALF) ecmd->advertising |= ADVERTISED_10baseT_Half; if (advert & ADVERTISE_10FULL) @@ -62,19 +66,31 @@ ecmd->advertising |= ADVERTISED_100baseT_Half; if (advert & ADVERTISE_100FULL) ecmd->advertising |= ADVERTISED_100baseT_Full; + if (advert2 & ADVERTISE_1000HALF) + ecmd->advertising |= ADVERTISED_1000baseT_Half; + if (advert2 & ADVERTISE_1000FULL) + ecmd->advertising |= ADVERTISED_1000baseT_Full; bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); lpa = mii->mdio_read(dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) { + bmcr2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + lpa2 = mii->mdio_read(dev, mii->phy_id, MII_STAT1000); + } if (bmcr & BMCR_ANENABLE) { ecmd->advertising |= ADVERTISED_Autoneg; ecmd->autoneg = AUTONEG_ENABLE; nego = mii_nway_result(advert & lpa); - if (nego == LPA_100FULL || nego == LPA_100HALF) + if ((bmcr2 & (ADVERTISE_1000HALF | ADVERTISE_1000FULL)) & + (lpa2 >> 2)) + ecmd->speed = SPEED_1000; + else if (nego == LPA_100FULL || nego == LPA_100HALF) ecmd->speed = SPEED_100; else ecmd->speed = SPEED_10; - if (nego == LPA_100FULL || nego == LPA_10FULL) { + if ((lpa2 & LPA_1000FULL) || nego == LPA_100FULL || + nego == LPA_10FULL) { ecmd->duplex = DUPLEX_FULL; mii->full_duplex = 1; } else { @@ -84,7 +100,9 @@ } else { ecmd->autoneg = AUTONEG_DISABLE; - ecmd->speed = (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10; + ecmd->speed = ((bmcr2 & BMCR_SPEED1000 && + (bmcr & BMCR_SPEED100) == 0) ? SPEED_1000 : + (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10); ecmd->duplex = (bmcr & BMCR_FULLDPLX) ? DUPLEX_FULL : DUPLEX_HALF; } @@ -97,7 +115,9 @@ { struct net_device *dev = mii->dev; - if (ecmd->speed != SPEED_10 && ecmd->speed != SPEED_100) + if (ecmd->speed != SPEED_10 && + ecmd->speed != SPEED_100 && + ecmd->speed != SPEED_1000) return -EINVAL; if (ecmd->duplex != DUPLEX_HALF && ecmd->duplex != DUPLEX_FULL) return -EINVAL; @@ -109,21 +129,30 @@ return -EINVAL; if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE) return -EINVAL; + if ((ecmd->speed == SPEED_1000) && (!mii->supports_gmii)) + return -EINVAL; /* ignore supported, maxtxpkt, maxrxpkt */ if (ecmd->autoneg == AUTONEG_ENABLE) { u32 bmcr, advert, tmp; + u32 advert2 = 0, tmp2 = 0; if ((ecmd->advertising & (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | ADVERTISED_100baseT_Half | - ADVERTISED_100baseT_Full)) == 0) + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Half | + ADVERTISED_1000baseT_Full)) == 0) return -EINVAL; /* advertise only what has been requested */ advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); tmp = advert & ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (mii->supports_gmii) { + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + tmp2 = advert2 & ~(ADVERTISE_1000HALF | ADVERTISE_1000FULL); + } if (ecmd->advertising & ADVERTISED_10baseT_Half) tmp |= ADVERTISE_10HALF; if (ecmd->advertising & ADVERTISED_10baseT_Full) @@ -132,10 +161,18 @@ tmp |= ADVERTISE_100HALF; if (ecmd->advertising & ADVERTISED_100baseT_Full) tmp |= ADVERTISE_100FULL; + if (mii->supports_gmii) { + if (ecmd->advertising & ADVERTISED_1000baseT_Half) + advert2 |= ADVERTISE_1000HALF; + if (ecmd->advertising & ADVERTISED_1000baseT_Full) + advert2 |= ADVERTISE_1000FULL; + } if (advert != tmp) { mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, tmp); mii->advertising = tmp; } + if ((mii->supports_gmii) && (advert2 != tmp2)) + mii->mdio_write(dev, mii->phy_id, MII_CTRL1000, tmp2); /* turn on autonegotiation, and force a renegotiate */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); @@ -148,8 +185,11 @@ /* turn off auto negotiation, set speed and duplexity */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); - tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX); - if (ecmd->speed == SPEED_100) + tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | + BMCR_SPEED1000 | BMCR_FULLDPLX); + if (ecmd->speed == SPEED_1000) + tmp |= BMCR_SPEED1000; + else if (ecmd->speed == SPEED_100) tmp |= BMCR_SPEED100; if (ecmd->duplex == DUPLEX_FULL) { tmp |= BMCR_FULLDPLX; @@ -207,6 +247,7 @@ { unsigned int old_carrier, new_carrier; int advertise, lpa, media, duplex; + int lpa2 = 0; /* if forced media, go no further */ if (mii->force_media) @@ -243,16 +284,20 @@ mii->advertising = advertise; } lpa = mii->mdio_read(mii->dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) + lpa2 = mii->mdio_read(mii->dev, mii->phy_id, MII_STAT1000); /* figure out media and duplex from advertise and LPA values */ media = mii_nway_result(lpa & advertise); duplex = (media & ADVERTISE_FULL) ? 1 : 0; + if (lpa2 & LPA_1000FULL) + duplex = 1; if (ok_to_print) printk(KERN_INFO "%s: link up, %sMbps, %s-duplex, lpa 0x%04X\n", mii->dev->name, - media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? - "100" : "10", + lpa2 & (LPA_1000FULL | LPA_1000HALF) ? "1000" : + media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? "100" : "10", duplex ? "full" : "half", lpa); diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h 2005-02-25 21:12:07 +00:00 +++ b/include/linux/mii.h 2005-02-25 21:12:07 +00:00 @@ -20,6 +20,8 @@ #define MII_ADVERTISE 0x04 /* Advertisement control reg */ #define MII_LPA 0x05 /* Link partner ability reg */ #define MII_EXPANSION 0x06 /* Expansion register */ +#define MII_CTRL1000 0x09 /* 1000BASE-T control */ +#define MII_STAT1000 0x0a /* 1000BASE-T status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -67,9 +69,9 @@ #define ADVERTISE_100HALF 0x0080 /* Try for 100mbps half-duplex */ #define ADVERTISE_100FULL 0x0100 /* Try for 100mbps full-duplex */ #define ADVERTISE_100BASE4 0x0200 /* Try for 100mbps 4k packets */ -#define ADVERTISE_PAUSE_CAP 0x0400 /* Try for pause */ -#define ADVERTISE_PAUSE_ASYM 0x0800 /* Try for asymetric pause */ -#define ADVERTISE_RESV 0x1c00 /* Unused... */ +#define ADVERTISE_PAUSE_CAP 0x0400 /* Try for pause */ +#define ADVERTISE_PAUSE_ASYM 0x0800 /* Try for asymetric pause */ +#define ADVERTISE_RESV 0x1000 /* Unused... */ #define ADVERTISE_RFAULT 0x2000 /* Say we can detect faults */ #define ADVERTISE_LPACK 0x4000 /* Ack link partners response */ #define ADVERTISE_NPAGE 0x8000 /* Next page bit */ @@ -86,9 +88,9 @@ #define LPA_100HALF 0x0080 /* Can do 100mbps half-duplex */ #define LPA_100FULL 0x0100 /* Can do 100mbps full-duplex */ #define LPA_100BASE4 0x0200 /* Can do 100mbps 4k packets */ -#define LPA_PAUSE_CAP 0x0400 /* Can pause */ -#define LPA_PAUSE_ASYM 0x0800 /* Can pause asymetrically */ -#define LPA_RESV 0x1c00 /* Unused... */ +#define LPA_PAUSE_CAP 0x0400 /* Can pause */ +#define LPA_PAUSE_ASYM 0x0800 /* Can pause asymetrically */ +#define LPA_RESV 0x1000 /* Unused... */ #define LPA_RFAULT 0x2000 /* Link partner faulted */ #define LPA_LPACK 0x4000 /* Link partner acked us */ #define LPA_NPAGE 0x8000 /* Next page bit */ @@ -109,6 +111,15 @@ #define NWAYTEST_LOOPBACK 0x0100 /* Enable loopback for N-way */ #define NWAYTEST_RESV2 0xfe00 /* Unused... */ +/* 1000BASE-T Control register */ +#define ADVERTISE_1000FULL 0x0200 /* Advertise 1000BASE-T full duplex */ +#define ADVERTISE_1000HALF 0x0100 /* Advertise 1000BASE-T half duplex */ + +/* 1000BASE-T Status register */ +#define LPA_1000LOCALRXOK 0x2000 /* Link partner local receiver status */ +#define LPA_1000REMRXOK 0x1000 /* Link partner remote receiver status */ +#define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */ +#define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */ struct mii_if_info { int phy_id; @@ -118,6 +129,7 @@ unsigned int full_duplex : 1; /* is full duplex? */ unsigned int force_media : 1; /* is autoneg. disabled? */ + unsigned int supports_gmii : 1; /* are GMII registers supported? */ struct net_device *dev; int (*mdio_read) (struct net_device *dev, int phy_id, int location); --------------090905080402050506000709-- From jgarzik@pobox.com Sat Feb 26 01:11:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 01:11:33 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1Q9BRBX011716 for ; Sat, 26 Feb 2005 01:11:27 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4xyv-00053X-HS; Sat, 26 Feb 2005 09:11:25 +0000 Message-ID: <42203D2B.6040802@pobox.com> Date: Sat, 26 Feb 2005 04:11:07 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107357415.27197.4.camel@dcbw.boston.redhat.com> In-Reply-To: <1107357415.27197.4.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2063 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 jgarzik@pobox.com Sat Feb 26 01:11:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 01:11:36 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1Q9BVk2011724 for ; Sat, 26 Feb 2005 01:11:32 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D4xz0-00053Z-BD; Sat, 26 Feb 2005 09:11:30 +0000 Message-ID: <42203D35.6090500@pobox.com> Date: Sat, 26 Feb 2005 04:11:17 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver References: <1107357472.27197.5.camel@dcbw.boston.redhat.com> In-Reply-To: <1107357472.27197.5.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2064 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: 36 Lines: 2 applied patches 1-2 in this series From arnaldo.melo@gmail.com Sat Feb 26 01:41:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 01:41:46 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1Q9fdsJ013356 for ; Sat, 26 Feb 2005 01:41:40 -0800 Received: by wproxy.gmail.com with SMTP id 68so596571wri for ; Sat, 26 Feb 2005 01:41:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=W3mwjKJ4xFjGUHlkkI5X6dpk/MSx+6tvKhiasV+l63/NfmSGsz8Hle1SttETQ9FdfBE4CyfJt71kIP18wVleiMQxUVCgJrLFawFWBjCKU9MGGzbAREK+Kt3lRXR6wFECE5jJUCjJbEs+jqNdN55mVvrTHgtLlXf57fOSaokiUVQ= Received: by 10.54.23.51 with SMTP id 51mr20712wrw; Sat, 26 Feb 2005 01:41:34 -0800 (PST) Received: by 10.54.10.28 with HTTP; Sat, 26 Feb 2005 01:41:34 -0800 (PST) Message-ID: <39e6f6c70502260141112f5ab6@mail.gmail.com> Date: Sat, 26 Feb 2005 06:41:34 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Stephen Hemminger Subject: Re: [PATCH] select congestion control with one sysctl Cc: "David S. Miller" , Baruch Even , netdev@oss.sgi.com, linux-net@vger.kernel.org, yee-ting.li@nuim.ie, doug.leith@nuim.ie In-Reply-To: <421D1E66.5090301@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 850 Lines: 26 On Wed, 23 Feb 2005 16:23:02 -0800, Stephen Hemminger wrote: > David S. Miller wrote: > > >For the millionth time, you can't just delete the existing sysctls. > >That is a user visisble interface. > > > >Instead, you have to make them at least appear to select a > >single congestion control algorithm as I stated in the > >following posting: > > > >http://marc.theaimsgroup.com/?l=linux-kernel&m=110909973530321&w=2 > > > > > I am heading in a different direction with making the TCP congestion > protocols > a real infrastructure. After the initial version gets done, then I will > go back > and add compatiablity interface hooks as required. Wheee! Now I just have to finish this client project and see what you come up with to see if it fits what I need for the selectable DCCP congestion control stuff 8) -- - Arnaldo From bunk@stusta.de Sat Feb 26 03:31:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 03:31:39 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1QBVW2q019028 for ; Sat, 26 Feb 2005 03:31:33 -0800 Received: (qmail 7337 invoked from network); 26 Feb 2005 11:31:25 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 26 Feb 2005 11:31:25 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id CDF7EC781E; Sat, 26 Feb 2005 12:31:23 +0100 (CET) Date: Sat, 26 Feb 2005 12:31:23 +0100 From: Adrian Bunk To: Andrew Morton , netdev@oss.sgi.com, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org Subject: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050226113123.GJ3311@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050223014233.6710fd73.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2882 Lines: 84 On Wed, Feb 23, 2005 at 01:42:33AM -0800, Andrew Morton wrote: >... > Changes since 2.6.11-rc3-mm1: >... > bk-netdev.patch >... Some of the options that needlessly wrote in their help text which options they do selct (patch already sent) didn't obey the most important rule of select If you select something, you have to ensure that the dependencies of what you do select are fulfilled. resulting in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 crypto/built-in.o(.init.text+0x31b): In function `aes_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.init.text+0x326): In function `michael_mic_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.exit.text+0x6): In function `aes_fini': : undefined reference to `crypto_unregister_alg' crypto/built-in.o(.exit.text+0x16): In function `michael_mic_exit': : undefined reference to `crypto_unregister_alg' net/built-in.o(.text+0x5ba52): In function `ieee80211_ccmp_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5ba94): In function `ieee80211_ccmp_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5bab7): In function `ieee80211_ccmp_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c5c2): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c5d5): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c623): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c62a): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c65e): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c665): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> This patch adds the missing selects of CRYPTO. --- linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig.old 2005-02-26 12:12:44.000000000 +0100 +++ linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig 2005-02-26 12:13:47.000000000 +0100 @@ -42,10 +42,11 @@ "ieee80211_crypt_wep". config IEEE80211_CRYPT_CCMP tristate "IEEE 802.11i CCMP support" depends on IEEE80211 + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled networks. From zdenek@rcn.com Sat Feb 26 06:15:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 06:15:27 -0800 (PST) Received: from smtp04.mrf.mail.rcn.net (smtp04.mrf.mail.rcn.net [207.172.4.63]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QEFMWw028524 for ; Sat, 26 Feb 2005 06:15:23 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com (HELO funex) (209.150.50.115) by smtp04.mrf.mail.rcn.net with SMTP; 26 Feb 2005 09:15:22 -0500 Message-Id: <3sp35g$62ejk@smtp04.mrf.mail.rcn.net> X-IronPort-AV: i="3.90,118,1107752400"; d="scan'208"; a="6371956:sNHT19379020" X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 26 Feb 2005 09:12:42 -0500 To: netdev@oss.sgi.com, linux-net@vger.kernel.org From: Zdenek Radouch Subject: need help with ip_output Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2068 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 1635 Lines: 54 I am stuck designing a net driver that sits on top of a module performing physical routing layer. The lower layer must switch (route) the outgoing packet to the appropriate physical channel on the same interface. The physical layer does not use an address resolution protocol, the destination physical address is computed dynamically from the next hop IP address. I am coming from BSD-style stacks, where the ip output actually carries the next hop IP address. So there, the code looks [simplified API] something like this: stack code: output(pkt, dst_ip_addr) net driver code: output(pkt, dst_ip_addr) { dest_hw_addr = hw_rt_resolve(dst_ip_addr) // dynamically compute phys dest addr fill_hw_header(pkt, dst_hw_addr) // fill phys layer header hw_tx(pkt) // enqueue pkt for transmission in the lower phys layer module } Now the problem. I can't figure out how to get hold of the destination IP address (next hop) during the output processing! None of the linux netif docs suggests how to do this, but maybe I am missing something. It appears to me that the Ethernet ARP paradigm drives the design of the stack, but I need to implement a general, non-protocol but dynamic address resolution mechanism. Conceptually, I need something like the hard_header() method, except it would have to pass down the IP address, rather than the phys address as it does now. Alternately, if the next hop IP address is somewhere in the skb (there's a undocumented "dst" field;could it be there?), I could fish it out of there. I'd appreciate any pointers to either what I've missed, or how this could be implemented. Thanks. -Zdenek From rich@phekda.gotadsl.co.uk Sat Feb 26 06:51:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 06:52:11 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QEpwjg030297 for ; Sat, 26 Feb 2005 06:51:58 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-104-249.dyn.gotadsl.co.uk [82.133.104.249]) by smtp.nildram.co.uk (Postfix) with ESMTP id 99F7C2BF0DA; Sat, 26 Feb 2005 14:51:54 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id DEB59381DC; Sat, 26 Feb 2005 14:54:05 +0000 (GMT) Message-ID: <42208D83.80803@phekda.gotadsl.co.uk> Date: Sat, 26 Feb 2005 14:53:55 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu , Jon Mason Cc: netdev@oss.sgi.com Subject: [PATCH]: r8169: Expose hardware stats via ethtool Content-Type: multipart/mixed; boundary="------------000308020907060900090902" X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 6956 Lines: 233 This is a multi-part message in MIME format. --------------000308020907060900090902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Francois and Jon! Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver. It's against 2.6.11-rc5. Signed-Off-By: Richard Dawe Basically it's a port of the 8139cp stats routines to r8169. In 8139cp the stats buffer is in the ring buffers' DMA mapping. In this patch for r8169 it has its own DMA mapping. One problem: Bogus stats are generated when I insert the module but don't bring it up. E.g.: if I do this on FC3 (eth0 == r8169): <--(Using 2.6.11-rc5's r8169 driver here)--> service network stop rmmod r8169 insmod /path/to/new/r8169.ko ethtool -S eth0 I get this: NIC statistics: tx_ok: 18446604436244066304 rx_ok: 4096 tx_err: 0 rx_err: 0 rx_fifo: 4 frame_align: 1 tx_ok_1col: 488917820 tx_ok_mcol: 0 rx_ok_phys: 18446604435732824074 rx_ok_bcast: 18446744071565939505 rx_ok_mcast: 0 tx_abort: 18446604435732824064 tx_underrun: 18446604436090647520 If I then bring the interface up ("ifconfig eth0 up"), I get valid stats. Any suggestions on how to fix this? I tried a couple of things: * Return in get_ethtool_stats if !netif_running(). Made no difference. * Zero the stats after creating the DMA mapping with pci_alloc_consistent(). Made no difference. I wonder if 8139cp has the same problem? Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek --------------000308020907060900090902 Content-Type: text/plain; name="r8169-ethtool-stats.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169-ethtool-stats.diff" --- linux-2.6.11-rc5/drivers/net/r8169.c.orig 2005-02-24 16:40:30.000000000 +0000 +++ linux-2.6.11-rc5/drivers/net/r8169.c 2005-02-26 14:28:37.000000000 +0000 @@ -128,6 +128,7 @@ static int multicast_filter_limit = 32; #define RX_BUF_SIZE 1536 /* Rx Buffer size */ #define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc)) #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc)) +#define R8169_STATS_BYTES 64 #define RTL8169_TX_TIMEOUT (6*HZ) #define RTL8169_PHY_TIMEOUT (10*HZ) @@ -187,6 +188,8 @@ static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ MAR0 = 8, /* Multicast filter. */ + StatsAddrLow = 0x10, + StatsAddrHigh = 0x14, TxDescStartAddrLow = 0x20, TxDescStartAddrHigh = 0x24, TxHDescStartAddrLow = 0x28, @@ -255,6 +258,9 @@ enum RTL8169_register_content { Cfg9346_Lock = 0x00, Cfg9346_Unlock = 0xC0, + /* StatsAddr register */ + DumpStats = (1 << 3), + /* rx_mode_bits */ AcceptErr = 0x20, AcceptRunt = 0x10, @@ -380,6 +386,22 @@ struct ring_info { u8 __pad[sizeof(void *) - sizeof(u32)]; }; +struct rtl8169_stats { + u64 tx_ok; + u64 rx_ok; + u64 tx_err; + u32 rx_err; + u16 rx_fifo; + u16 frame_align; + u32 tx_ok_1col; + u32 tx_ok_mcol; + u64 rx_ok_phys; + u64 rx_ok_bcast; + u32 rx_ok_mcast; + u16 tx_abort; + u16 tx_underrun; +} __attribute__((packed)); + struct rtl8169_private { void __iomem *mmio_addr; /* memory map physical address */ struct pci_dev *pci_dev; /* Index of PCI device */ @@ -404,6 +426,8 @@ struct rtl8169_private { u16 intr_mask; int phy_auto_nego_reg; int phy_1000_ctrl_reg; + struct rtl8169_stats *nic_stats; + dma_addr_t nic_stats_addr; #ifdef CONFIG_R8169_VLAN struct vlan_group *vlgrp; #endif @@ -871,6 +895,68 @@ static void rtl8169_get_regs(struct net_ spin_unlock_irqrestore(&tp->lock, flags); } +static const char rtl8169_gstrings_stats[][ETH_GSTRING_LEN] = { + "tx_ok", "rx_ok", "tx_err", "rx_err", + "rx_fifo", "frame_align", "tx_ok_1col", "tx_ok_mcol", + "rx_ok_phys", "rx_ok_bcast", "rx_ok_mcast", "tx_abort", + "tx_underrun", +}; +#define RTL8169_STATS_LEN sizeof(rtl8169_gstrings_stats) / ETH_GSTRING_LEN + +static int rtl8169_get_stats_count(struct net_device *dev) +{ + return RTL8169_STATS_LEN; +} + +static void rtl8169_get_strings(struct net_device *netdev, u32 stringset, u8 *data) +{ + switch(stringset) { + case ETH_SS_STATS: + memcpy(data, *rtl8169_gstrings_stats, sizeof(rtl8169_gstrings_stats)); + break; + } +} + +static void rtl8169_get_ethtool_stats(struct net_device *netdev, + struct ethtool_stats *stats, u64 *data) +{ + struct rtl8169_private *tp = netdev_priv(netdev); + void __iomem *ioaddr = tp->mmio_addr; + int work = 100; + int i; + + /* begin NIC statistics dump */ + RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); + RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | DumpStats); + RTL_R32(StatsAddrLow); + + while (work-- > 0) { + if ((RTL_R32(StatsAddrLow) & DumpStats) == 0) + break; + cpu_relax(); + } + + if (RTL_R32(StatsAddrLow) & DumpStats) + return; /* no stats - took too long */ + + i = 0; + data[i++] = le64_to_cpu(tp->nic_stats->tx_ok); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok); + data[i++] = le64_to_cpu(tp->nic_stats->tx_err); + data[i++] = le32_to_cpu(tp->nic_stats->rx_err); + data[i++] = le16_to_cpu(tp->nic_stats->rx_fifo); + data[i++] = le16_to_cpu(tp->nic_stats->frame_align); + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_1col); + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_mcol); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_phys); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_bcast); + data[i++] = le32_to_cpu(tp->nic_stats->rx_ok_mcast); + data[i++] = le16_to_cpu(tp->nic_stats->tx_abort); + data[i++] = le16_to_cpu(tp->nic_stats->tx_underrun); + if (i != RTL8169_STATS_LEN) + BUG(); +} + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, .get_regs_len = rtl8169_get_regs_len, @@ -886,6 +972,9 @@ static struct ethtool_ops rtl8169_ethtoo .get_tso = ethtool_op_get_tso, .set_tso = ethtool_op_set_tso, .get_regs = rtl8169_get_regs, + .get_strings = rtl8169_get_strings, + .get_stats_count = rtl8169_get_stats_count, + .get_ethtool_stats = rtl8169_get_ethtool_stats, }; static void rtl8169_write_gmii_reg_bit(void __iomem *ioaddr, int reg, int bitnum, @@ -1531,6 +1620,11 @@ static int rtl8169_open(struct net_devic if (retval < 0) goto err_free_rx; + tp->nic_stats = pci_alloc_consistent(pdev, R8169_STATS_BYTES, + &tp->nic_stats_addr); + if (!tp->nic_stats) + goto err_free_nic_stats; + INIT_WORK(&tp->task, NULL, dev); rtl8169_hw_start(dev); @@ -1541,6 +1635,10 @@ static int rtl8169_open(struct net_devic out: return retval; +err_free_nic_stats: + pci_free_consistent(pdev, R8169_STATS_BYTES, tp->nic_stats, + tp->nic_stats_addr); + err_free_rx: pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, tp->RxPhyAddr); --------------000308020907060900090902-- From jgarzik@pobox.com Sat Feb 26 07:57:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 07:57:33 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QFvLrl000324 for ; Sat, 26 Feb 2005 07:57:22 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D54Jj-0005hD-6g; Sat, 26 Feb 2005 15:57:19 +0000 Message-ID: <42209C4E.6000800@pobox.com> Date: Sat, 26 Feb 2005 10:57:02 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Dawe CC: Francois Romieu , Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> In-Reply-To: <42208D83.80803@phekda.gotadsl.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2070 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: 2381 Lines: 80 Richard Dawe wrote: > Hi Francois and Jon! > > Please find attached a patch that adds the hardware statistics ethtool > operations to the r8169 driver. It's against 2.6.11-rc5. > > Signed-Off-By: Richard Dawe > > Basically it's a port of the 8139cp stats routines to r8169. In 8139cp > the stats buffer is in the ring buffers' DMA mapping. In this patch for > r8169 it has its own DMA mapping. > > One problem: Bogus stats are generated when I insert the module but > don't bring it up. E.g.: if I do this on FC3 (eth0 == r8169): > > <--(Using 2.6.11-rc5's r8169 driver here)--> > service network stop > rmmod r8169 > insmod /path/to/new/r8169.ko > ethtool -S eth0 > > I get this: > > NIC statistics: > tx_ok: 18446604436244066304 > rx_ok: 4096 > tx_err: 0 > rx_err: 0 > rx_fifo: 4 > frame_align: 1 > tx_ok_1col: 488917820 > tx_ok_mcol: 0 > rx_ok_phys: 18446604435732824074 > rx_ok_bcast: 18446744071565939505 > rx_ok_mcast: 0 > tx_abort: 18446604435732824064 > tx_underrun: 18446604436090647520 > > If I then bring the interface up ("ifconfig eth0 up"), I get valid stats. > > Any suggestions on how to fix this? I tried a couple of things: > > * Return in get_ethtool_stats if !netif_running(). Made no difference. > > * Zero the stats after creating the DMA mapping with > pci_alloc_consistent(). Made no difference. > > I wonder if 8139cp has the same problem? No idea.. Worth checking. > +static const char rtl8169_gstrings_stats[][ETH_GSTRING_LEN] = { > + "tx_ok", "rx_ok", "tx_err", "rx_err", > + "rx_fifo", "frame_align", "tx_ok_1col", "tx_ok_mcol", > + "rx_ok_phys", "rx_ok_bcast", "rx_ok_mcast", "tx_abort", > + "tx_underrun", > +}; Don't needlessly reformat copied code. It's one-string-per-line intentionally, for ease of maintenance and ease of adding new strings. Also, I don't see why you renamed this from ethtool_stats_keys[]. > + /* begin NIC statistics dump */ > + RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); > + RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | DumpStats); > + RTL_R32(StatsAddrLow); This last RTL_R32() can be removed [from 8139cp too], because a flush immediately follows anyway: > + while (work-- > 0) { > + if ((RTL_R32(StatsAddrLow) & DumpStats) == 0) > + break; > + cpu_relax(); > + } From olh@suse.de Sat Feb 26 08:18:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 08:18:52 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QGIh7q001378 for ; Sat, 26 Feb 2005 08:18:43 -0800 Received: from hermes.suse.de (hermes-ext.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 7BC5B15083D2 for ; Sat, 26 Feb 2005 17:18:37 +0100 (CET) Date: Sat, 26 Feb 2005 17:18:36 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: tg3 access hangs on system shutdown with 2.6.11-rc5, tg3_stop_block timed out Message-ID: <20050226161836.GA15277@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 31928 Lines: 612 my JS20 blades hang on system reboot with current Linus tree. I think it started after rc3. Maybe this line in dmesg gives a hint: tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 It does not happen every time, and I dont have a simple test case. ip S 000000000ff4a668 12160 9595 9590 (NOTLB) Call Trace: [c00000000d947230] [c00000000009778c] .__alloc_pages+0x11c/0x5fc (unreliable) [c00000000d947400] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000d947490] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000d9475b0] [c0000000003fde80] .schedule_timeout+0x118/0x120 [c00000000d947690] [c00000000034a46c] .skb_recv_datagram+0x210/0x2f4 [c00000000d9477d0] [c00000000036f310] .netlink_recvmsg+0x7c/0x2cc [c00000000d9478c0] [c000000000340264] .sock_recvmsg+0x174/0x1c0 [c00000000d947ad0] [c000000000342aa0] .sys_recvmsg+0x154/0x350 [c00000000d947d00] [c000000000362084] .compat_sys_recvmsg+0x1c/0x34 [c00000000d947d80] [c000000000362b9c] .compat_sys_socketcall+0xf8/0x278 [c00000000d947e30] [c00000000000d500] syscall_exit+0x0/0x18 0000:00:00.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=11, subordinate=20, sec-latency=0 I/O behind bridge: 00200000-003fffff Memory behind bridge: c0000000-dfffffff Expansion ROM at 00200000 [disabled] [size=2M] Capabilities: [a0] Capabilities: [b8] #08 [8011] 0000:00:03.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=21, subordinate=30, sec-latency=0 I/O behind bridge: 00008000-0000ffff Memory behind bridge: e0000000-ebffffff Expansion ROM at 00008000 [disabled] [size=32K] Capabilities: [c0] #08 [0083] Capabilities: [f0] #08 [8031] 0000:00:04.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) (prog-if 8f [Master SecP SecO PriP PriO]) Flags: bus master, medium devsel, latency 74, IRQ 32 I/O ports at 7400 I/O ports at 6c00 [size=4] I/O ports at 7800 [size=8] I/O ports at 7000 [size=4] I/O ports at 7c00 [size=16] 0000:00:1f.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=10, sec-latency=0 I/O behind bridge: 00100000-001fffff Memory behind bridge: 80000000-bfffffff Expansion ROM at 00100000 [disabled] [size=1M] Capabilities: [a0] Capabilities: [b8] #08 [8000] Capabilities: [c0] #08 [005f] 0000:11:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03) Subsystem: IBM: Unknown device 029c Flags: bus master, 66Mhz, medium devsel, latency 144, IRQ 44 Memory at c0030000 (64-bit, non-prefetchable) Memory at c0020000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 0000:11:01.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03) Subsystem: IBM: Unknown device 029c Flags: bus master, 66Mhz, medium devsel, latency 144, IRQ 45 Memory at c0010000 (64-bit, non-prefetchable) Memory at c0000000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 0000:21:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 72, IRQ 35 Memory at e0001000 (32-bit, non-prefetchable) 0000:21:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 72, IRQ 35 Memory at e0000000 (32-bit, non-prefetchable) PID TTY STAT TIME COMMAND 1 ? S 0:00 init [6] 2 ? S 0:07 [migration/0] 3 ? SN 0:16 [ksoftirqd/0] 4 ? S 0:06 [migration/1] 5 ? SN 0:03 [ksoftirqd/1] 6 ? S< 0:05 [events/0] 7 ? S< 0:00 [events/1] 8 ? S< 0:00 [khelper] 13 ? S< 0:00 [kthread] 42 ? S< 0:00 \_ [kblockd/0] 43 ? S< 0:00 \_ [kblockd/1] 112 ? S 2:53 \_ [pdflush] 114 ? S< 0:00 \_ [aio/0] 115 ? S< 0:00 \_ [aio/1] 709 ? S< 0:00 \_ [khvcd] 941 ? S< 0:44 \_ [reiserfs/0] 942 ? S< 0:32 \_ [reiserfs/1] 22416 ? S 1:36 \_ [pdflush] 51 ? S 0:00 [khubd] 75 ? S 0:00 [rtasd] 113 ? S 2:08 [kswapd0] 711 ? S 0:00 [kseriod] 2444 ? S 0:00 [hwscand] 2461 ? Ss 0:00 /sbin/dhcpcd -R -G -N -Y -t 999999 -h linux eth1 11835 ? Ss 0:00 sshd: root@pts/0 11837 pts/0 Ss 0:08 \_ -bash 10383 pts/0 S+ 0:00 \_ -bash 10385 pts/0 R+ 0:00 \_ ps axf 8971 ? Ss 0:00 /bin/bash /etc/init.d/rc 6 9438 ? S 0:00 \_ /bin/bash /etc/init.d/rc5.d/K17network stop 9565 ? S 0:00 \_ /bin/bash /sbin/ifdown eth1 -o rc onboot 9590 ? S 0:00 \_ /bin/bash scripts/ifdown-connection eth-bus-pci-0000:11:01.1 eth1 -o rc onboot 9595 ? S 0:00 \_ ip link list eth1 8986 ? Ss 0:01 /sbin/blogd /dev/hvc0 10162 ? Ss 0:00 /sbin/dhcpcd -H -D -t 999999 -h linux eth0 10331 ? Ss 0:00 /usr/lib/postfix/master 10339 ? S 0:00 \_ pickup -l -t fifo -u 10340 ? S 0:00 \_ qmgr -l -t fifo -u 10350 ? S 0:00 \_ trivial-rewrite -n rewrite -t unix -u 10351 ? S 0:00 \_ smtp -t unix -u 10352 ? S 0:00 \_ smtp -t unix -u 10353 ? S 0:00 \_ smtp -t unix -u 10354 ? S 0:00 \_ smtp -t unix -u 10355 ? S 0:00 \_ smtp -t unix -u 10359 ? S 0:00 \_ showq -t unix -u 10360 ? S 0:00 \_ bounce -z -n defer -t unix -u 10361 ? S 0:00 \_ bounce -z -n defer -t unix -u 10362 ? S 0:00 \_ smtp -t unix -u 10363 ? S 0:00 \_ smtp -t unix -u 10364 ? S 0:00 \_ smtp -t unix -u 10365 ? S 0:00 \_ smtp -t unix -u 10366 ? S 0:00 \_ smtp -t unix -u 10368 ? S 0:00 \_ smtp -t unix -u 10369 ? S 0:00 \_ smtp -t unix -u 10377 ? S 0:00 \_ cleanup -z -t unix -u Found initrd at 0xc000000002600000:0xc000000002738000 firmware_features = 0x55f Partition configured for 2 cpus. Starting Linux PPC64 2.6.11-rc4-bk10-200502230747-usbtest ----------------------------------------------------- ppc64_pft_size = 0x17 ppc64_debug_switch = 0x0 ppc64_interrupt_controller = 0x2 systemcfg = 0xc000000000005000 systemcfg->platform = 0x101 systemcfg->processorCount = 0x2 systemcfg->physicalMemorySize = 0x1e000000 ppc64_caches.dcache_line_size = 0x80 ppc64_caches.icache_line_size = 0x80 htab_address = 0x0000000000000000 htab_hash_mask = 0xffff ----------------------------------------------------- [boot]0100 MM Init [boot]0100 MM Init Done Linux version 2.6.11-rc4-bk10-200502230747-usbtest (abuild@pomegranate) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 SMP Wed Feb 23 07:52:43 UTC 2005 [boot]0012 Setup Arch Top of RAM: 0x1e000000, Total RAM: 0x1e000000 Memory hole size: 0MB PPC64 nvram contains 16384 bytes Using default idle loop On node 0 totalpages: 122880 DMA zone: 122880 pages, LIFO batch:16 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 [boot]0015 Setup Done Built 1 zonelists Kernel command line: root=/dev/hda3 kdb=on quiet selinux=0 elevator=cfq [boot]0020 XICS Init xics: no ISA interrupt controller [boot]0021 XICS Done PID hash table entries: 2048 (order: 11, 65536 bytes) time_init: decrementer frequency = 199.839387 MHz time_init: processor frequency = 1600.000000 MHz Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) freeing bootmem node 0 Memory: 463936k/491520k available (4108k kernel code, 27244k reserved, 2052k data, 1362k bss, 252k init) Calibrating delay loop... 398.33 BogoMIPS (lpj=199168) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 256 (order: 0, 4096 bytes) Processor 1 found. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 00000000,00000000,00000000,00000001 groups: 00000000,00000000,00000000,00000001 domain 1: span 00000000,00000000,00000000,00000003 groups: 00000000,00000000,00000000,00000001 00000000,00000000,00000000,00000002 domain 2: span 00000000,00000000,00000000,00000003 groups: 00000000,00000000,00000000,00000003 CPU1 attaching sched-domain: domain 0: span 00000000,00000000,00000000,00000002 groups: 00000000,00000000,00000000,00000002 domain 1: span 00000000,00000000,00000000,00000003 groups: 00000000,00000000,00000000,00000002 00000000,00000000,00000000,00000001 domain 2: span 00000000,00000000,00000000,00000003 groups: 00000000,00000000,00000000,00000003 checking if image is initramfs... it is Freeing initrd memory: 1248k freed NET: Registered protocol family 16 PCI: Probing PCI hardware IDE Fixup IRQ: Can't find IO-APIC ! IOMMU table initialized, virtual merging enabled mapping IO 100f4000000 -> e000000000000000, size: 400000 PCI: Probing PCI hardware done usbcore: registered new driver usbfs usbcore: registered new driver hub TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca) i/pSeries Real Time Clock Driver v1.1 RTAS daemon started RTAS: event: 1, Type: Unknown, Severity: 2 probe_bus_pseries: processing c00000001dffd228 probe_bus_pseries: processing c00000001dffd398 probe_bus_pseries: processing c00000001dffd510 audit: initializing netlink socket (disabled) audit(1109197456.282:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Initializing Cryptographic API pci_hotplug: PCI Hot Plug PCI Core version: 0.5 rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpadlpar_io_init: partition not DLPAR capable vio_register_driver: driver hvc_console registering HVSI: registered 0 devices Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled pmac_zilog: 0.6 (Benjamin Herrenschmidt ) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Floppy drive(s): fd0 is 2.88M RAMDISK driver initialized: 16 RAM disks of 123456K size 1024 blocksize input: Macintosh mouse button emulation Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx AMD8111: IDE controller at PCI slot 0000:00:04.1 AMD8111: chipset revision 3 AMD8111: 0000:00:04.1 (rev 03) UDMA133 controller AMD8111: 100% native mode on irq 32 ide0: BM-DMA at 0x7c00-0x7c07, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x7c08-0x7c0f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: TOSHIBA MK4019GAXB, ATA DISK drive Unhandled interrupt 20, disabled ide0 at 0x7400-0x7407,0x6c02 on irq 32 Probing IDE interface ide1... Probing IDE interface ide1... hda: max request size: 128KiB hda: 78140160 sectors (40007 MB), CHS=65535/16/63, UDMA(33) hda: cache flushes supported hda: hda1 hda2 hda3 ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd 0000:21:00.0: OHCI Host Controller ohci_hcd 0000:21:00.0: irq 35, pci mem 0x100e0001000 ohci_hcd 0000:21:00.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd 0000:21:00.1: OHCI Host Controller ohci_hcd 0000:21:00.1: irq 35, pci mem 0x100e0000000 ohci_hcd 0000:21:00.1: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 oprofile: using ppc64/970 performance monitoring. NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 32Kbytes TCP established hash table entries: 16384 (order: 6, 262144 bytes) TCP bind hash table entries: 16384 (order: 6, 262144 bytes) TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Freeing unused kernel memory: 252k freed ReiserFS: hda3: found reiserfs format "3.6" with standard journal ReiserFS: hda3: using ordered data mode ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda3: checking transaction log (hda3) ReiserFS: hda3: Using r5 hash to sort names ioctl32(showconsole:970): Unknown cmd fd(0) cmd(40045432){00} arg(ffffea78) on /dev/console Adding 919792k swap on /dev/hda2. Priority:42 extents:1 ioctl32(showconsole:1087): Unknown cmd fd(0) cmd(40045432){00} arg(ffffe9d8) on /dev/console md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com ioctl32(showconsole:1290): Unknown cmd fd(0) cmd(40045432){00} arg(ffffea08) on /dev/console ioctl32(showconsole:1361): Unknown cmd fd(0) cmd(40045432){00} arg(ffffea18) on /dev/console ioctl32(showconsole:1551): Unknown cmd fd(0) cmd(40045432){00} arg(ffffea58) on /dev/console tg3.c:v3.23 (February 15, 2005) PCI: Enabling device: (0000:11:01.0), cmd 142 eth0: Tigon3 [partno(none) rev 2003 PHY(serdes)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:1e:09:de eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] PCI: Enabling device: (0000:11:01.1), cmd 142 eth1: Tigon3 [partno(none) rev 2003 PHY(serdes)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:1e:09:df eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] tg3: eth0: Link is up at 1000 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is off for TX and off for RX. SCSI subsystem initialized sg: Unknown symbol scsi_do_req sg: Unknown symbol scsi_device_get sg: Unknown symbol scsi_command_normalize_sense sg: Unknown symbol scsi_ioctl_send_command sg: Unknown symbol scsi_release_request sg: Unknown symbol scsi_print_req_sense sg: Unknown symbol scsi_allocate_request sg: Unknown symbol scsi_device_put sg: Unknown symbol scsi_logging_level sg: Unknown symbol scsi_ioctl sg: Unknown symbol scsi_block_when_processing_errors sg: Unknown symbol scsi_register_interface sg: Unknown symbol scsi_reset_provider NET: Registered protocol family 10 Disabled Privacy Extensions on device c0000000005b89b8(lo) IPv6 over IPv4 tunneling driver Disabled Privacy Extensions on device c0000000070e9180(sit0) eth1: no IPv6 routers present nfs warning: mount version older than kernel st: Version 20041025, fixed bufsize 32768, s/g segs 256 ioctl32(hwscan:10451): Unknown cmd fd(3) cmd(40045432){00} arg(ffffe804) on /dev/console nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel ioctl32(showconsole:8975): Unknown cmd fd(0) cmd(40045432){00} arg(ffffea48) on /dev/console tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 SysRq : Show State sibling task PC pid father child younger older init S 0000000010018fc4 6848 1 0 2 (NOTLB) Call Trace: [c000000002a1f6d0] [c000000002a1f6f0] 0xc000000002a1f6f0 (unreliable) [c000000002a1f8a0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002a1f930] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002a1fa50] [c0000000003fde08] .schedule_timeout+0xa0/0x120 [c000000002a1fb30] [c0000000000e0090] .do_select+0x3a0/0x4dc [c000000002a1fc80] [c0000000000fe3fc] .compat_sys_select+0x4e0/0x824 [c000000002a1fdb0] [c00000000001dd0c] .ppc32_select+0x1c/0x34 [c000000002a1fe30] [c00000000000d500] syscall_exit+0x0/0x18 migration/0 S 0000000000000000 13328 2 1 3 (L-TLB) Call Trace: [c0000000013aba40] [7265677368657265] 0x7265677368657265 (unreliable) [c0000000013abc10] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000013abca0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000013abdc0] [c000000000059950] .migration_thread+0x344/0x3dc [c0000000013abed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000013abf90] [c0000000000147e8] .kernel_thread+0x4c/0x6c ksoftirqd/0 S 0000000000000000 13664 3 1 4 2 (L-TLB) Call Trace: [c0000000013afaa0] [c00000001c632a08] 0xc00000001c632a08 (unreliable) [c0000000013afc70] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000013afd00] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000013afe20] [c0000000000678b0] .ksoftirqd+0x19c/0x1a4 [c0000000013afed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000013aff90] [c0000000000147e8] .kernel_thread+0x4c/0x6c migration/1 S 0000000000000000 13328 4 1 5 3 (L-TLB) Call Trace: [c0000000013b3c10] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000013b3ca0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000013b3dc0] [c000000000059950] .migration_thread+0x344/0x3dc [c0000000013b3ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000013b3f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c ksoftirqd/1 S 0000000000000000 13664 5 1 6 4 (L-TLB) Call Trace: [c0000000013b7aa0] [c0000000013b7da0] 0xc0000000013b7da0 (unreliable) [c0000000013b7c70] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000013b7d00] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000013b7e20] [c0000000000678b0] .ksoftirqd+0x19c/0x1a4 [c0000000013b7ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000013b7f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c events/0 S 0000000000000000 11176 6 1 7 5 (L-TLB) Call Trace: [c0000000013bba20] [0000000001c00000] 0x1c00000 (unreliable) [c0000000013bbbf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000013bbc80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000013bbda0] [c000000000077904] .worker_thread+0x174/0x330 [c0000000013bbed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000013bbf90] [c0000000000147e8] .kernel_thread+0x4c/0x6c events/1 S 0000000000000000 10688 7 1 8 6 (L-TLB) Call Trace: [c0000000026c3a20] [000000000000000a] 0xa (unreliable) [c0000000026c3bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000026c3c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000026c3da0] [c000000000077904] .worker_thread+0x174/0x330 [c0000000026c3ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000026c3f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c khelper S 0000000000000000 11232 8 1 13 7 (L-TLB) Call Trace: [c00000001df9ba20] [c000000000056de0] .activate_task+0x84/0x104 (unreliable) [c00000001df9bbf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000001df9bc80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000001df9bda0] [c000000000077904] .worker_thread+0x174/0x330 [c00000001df9bed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c00000001df9bf90] [c0000000000147e8] .kernel_thread+0x4c/0x6c kthread S 0000000000000000 11888 13 1 42 51 8 (L-TLB) Call Trace: [c000000002653a20] [c000000000056de0] .activate_task+0x84/0x104 (unreliable) [c000000002653bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002653c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002653da0] [c000000000077904] .worker_thread+0x174/0x330 [c000000002653ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002653f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c kblockd/0 S 0000000000000000 12472 42 13 43 (L-TLB) Call Trace: [c0000000026a3a20] [c000000000036ae0] .xics_enable_irq+0xbc/0xd8 (unreliable) [c0000000026a3bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c0000000026a3c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c0000000026a3da0] [c000000000077904] .worker_thread+0x174/0x330 [c0000000026a3ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c0000000026a3f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c kblockd/1 S 0000000000000000 12424 43 13 112 42 (L-TLB) Call Trace: [c000000002657a20] [c000000000036ae0] .xics_enable_irq+0xbc/0xd8 (unreliable) [c000000002657bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002657c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002657da0] [c000000000077904] .worker_thread+0x174/0x330 [c000000002657ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002657f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c khubd S 0000000000000000 13504 51 1 75 13 (L-TLB) Call Trace: [c000000002b13a80] [c00000000058e448] r_file_operations+0x28/0xd8 (unreliable) [c000000002b13c50] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002b13ce0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002b13e00] [c0000000002fdd00] .hub_thread+0x204/0xc7c [c000000002b13f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c rtasd R running task 13240 75 1 113 51 (L-TLB) pdflush S 0000000000000000 7648 112 13 114 43 (L-TLB) Call Trace: [c000000002b5fa70] [c00000000015de4c] .do_journal_end+0x2cc/0x1214 (unreliable) [c000000002b5fc40] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002b5fcd0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002b5fdf0] [c0000000000996b0] .pdflush+0xfc/0x25c [c000000002b5fed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002b5ff90] [c0000000000147e8] .kernel_thread+0x4c/0x6c kswapd0 S 0000000000000000 10544 113 1 711 75 (L-TLB) Call Trace: [c000000002b63a70] [0000000000200200] 0x200200 (unreliable) [c000000002b63c40] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002b63cd0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002b63df0] [c0000000000a34b8] .kswapd+0x478/0x51c [c000000002b63f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c aio/0 S 0000000000000000 14624 114 13 115 112 (L-TLB) Call Trace: [c000000002b67bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002b67c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002b67da0] [c000000000077904] .worker_thread+0x174/0x330 [c000000002b67ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002b67f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c aio/1 S 0000000000000000 14624 115 13 709 114 (L-TLB) Call Trace: [c000000002b77bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002b77c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002b77da0] [c000000000077904] .worker_thread+0x174/0x330 [c000000002b77ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002b77f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c khvcd S 0000000000000000 12992 709 13 941 115 (L-TLB) Call Trace: [c000000002bcfac0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002bcfb50] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002bcfc70] [c0000000003fde08] .schedule_timeout+0xa0/0x120 [c000000002bcfd50] [c00000000006de50] .msleep_interruptible+0x60/0x88 [c000000002bcfde0] [c000000000279d54] .khvcd+0x368/0x3c4 [c000000002bcfed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000002bcff90] [c0000000000147e8] .kernel_thread+0x4c/0x6c kseriod S 0000000000000000 14848 711 1 2444 113 (L-TLB) Call Trace: [c00000001dcafcd0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000001dcafd60] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000001dcafe80] [c00000000027cdd4] .serio_thread+0x2b0/0x2f8 [c00000001dcaff90] [c0000000000147e8] .kernel_thread+0x4c/0x6c reiserfs/0 S 0000000000000000 9536 941 13 942 709 (L-TLB) Call Trace: [c00000000fca7a20] [0000000001a1f9f0] 0x1a1f9f0 (unreliable) [c00000000fca7bf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000fca7c80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000fca7da0] [c000000000077904] .worker_thread+0x174/0x330 [c00000000fca7ed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c00000000fca7f90] [c0000000000147e8] .kernel_thread+0x4c/0x6c reiserfs/1 S 0000000000000000 9376 942 13 22416 941 (L-TLB) Call Trace: [c00000000fc8ba20] [0000000001a1f9f0] 0x1a1f9f0 (unreliable) [c00000000fc8bbf0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000fc8bc80] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000fc8bda0] [c000000000077904] .worker_thread+0x174/0x330 [c00000000fc8bed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c00000000fc8bf90] [c0000000000147e8] .kernel_thread+0x4c/0x6c hwscand S 000000000ff7dec4 9808 2444 1 2461 711 (NOTLB) Call Trace: [c000000002c7f860] [c000000002c7f8b0] 0xc000000002c7f8b0 (unreliable) [c000000002c7fa30] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000002c7fac0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000002c7fbe0] [c0000000001dcba8] .sys_msgrcv+0x3ec/0x488 [c000000002c7fcf0] [c0000000001daf54] .compat_sys_msgrcv+0xd8/0x1a8 [c000000002c7fdb0] [c00000000001ce9c] .sys32_ipc+0x16c/0x210 [c000000002c7fe30] [c00000000000d500] syscall_exit+0x0/0x18 dhcpcd S 000000000ff4b2dc 12168 2461 1 8971 2444 (NOTLB) Call Trace: [c00000000168f930] [c00000000006d8ac] .del_timer+0x40/0xe4 (unreliable) [c00000000168fb00] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000168fb90] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000168fcb0] [c0000000003fde08] .schedule_timeout+0xa0/0x120 [c00000000168fd90] [c000000000088620] .compat_sys_nanosleep+0xc8/0x1a4 [c00000000168fe30] [c00000000000d500] syscall_exit+0x0/0x18 sshd S 000000000fb8b608 8112 11835 1 11837 9000 (NOTLB) Call Trace: [c0000000173576d0] [c000000017357780] 0xc000000017357780 (unreliable) [c0000000173578a0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000017357930] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000017357a50] [c0000000003fde80] .schedule_timeout+0x118/0x120 [c000000017357b30] [c0000000000e0090] .do_select+0x3a0/0x4dc [c000000017357c80] [c0000000000fe3fc] .compat_sys_select+0x4e0/0x824 [c000000017357db0] [c00000000001dd0c] .ppc32_select+0x1c/0x34 [c000000017357e30] [c00000000000d500] syscall_exit+0x0/0x18 bash R running task 8112 11837 11835 (NOTLB) pdflush S 0000000000000000 6928 22416 13 942 (L-TLB) Call Trace: [c000000001e2ba70] [c00000000015de4c] .do_journal_end+0x2cc/0x1214 (unreliable) [c000000001e2bc40] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000001e2bcd0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000001e2bdf0] [c0000000000996b0] .pdflush+0xfc/0x25c [c000000001e2bed0] [c00000000007ef60] .kthread+0x18c/0x1e0 [c000000001e2bf90] [c0000000000147e8] .kernel_thread+0x4c/0x6c rc S 000000000fe3bc9c 8112 8971 1 9438 8986 2461 (NOTLB) Call Trace: [c00000001671f8d0] [0000136eafb0b001] 0x136eafb0b001 (unreliable) [c00000001671faa0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000001671fb30] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000001671fc50] [c000000000063e1c] .do_wait+0xe5c/0x11f4 [c00000001671fdb0] [c00000000001c4c4] .sys32_waitpid+0x20/0x38 [c00000001671fe30] [c00000000000d500] syscall_exit+0x0/0x18 blogd S 000000000ff30654 11024 8986 1 9000 8971 (NOTLB) Call Trace: [c00000000cec38a0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000cec3930] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000cec3a50] [c0000000003fde08] .schedule_timeout+0xa0/0x120 [c00000000cec3b30] [c0000000000e0090] .do_select+0x3a0/0x4dc [c00000000cec3c80] [c0000000000fe3fc] .compat_sys_select+0x4e0/0x824 [c00000000cec3db0] [c00000000001dd0c] .ppc32_select+0x1c/0x34 [c00000000cec3e30] [c00000000000d500] syscall_exit+0x0/0x18 blogd S 000000000ffc42dc 10816 9000 1 11835 8986 (NOTLB) Call Trace: [c00000001a7eb790] [c00000001a7eb840] 0xc00000001a7eb840 (unreliable) [c00000001a7eb960] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000001a7eb9f0] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000001a7ebb10] [c0000000003fde08] .schedule_timeout+0xa0/0x120 [c00000001a7ebbf0] [c000000000080c60] .do_futex+0x558/0x784 [c00000001a7ebd60] [c000000000089690] .compat_sys_futex+0xac/0x144 [c00000001a7ebe30] [c00000000000d500] syscall_exit+0x0/0x18 K17network S 000000000fe3bc9c 8176 9438 8971 9565 (NOTLB) Call Trace: [c0000000074338d0] [00004be47e859001] 0x4be47e859001 (unreliable) [c000000007433aa0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000007433b30] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000007433c50] [c000000000063e1c] .do_wait+0xe5c/0x11f4 [c000000007433db0] [c00000000001c4c4] .sys32_waitpid+0x20/0x38 [c000000007433e30] [c00000000000d500] syscall_exit+0x0/0x18 ifdown S 000000000fe3bc9c 11800 9565 9438 9590 (NOTLB) Call Trace: [c000000008fb78d0] [000097098ea97001] 0x97098ea97001 (unreliable) [c000000008fb7aa0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c000000008fb7b30] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c000000008fb7c50] [c000000000063e1c] .do_wait+0xe5c/0x11f4 [c000000008fb7db0] [c00000000001c4c4] .sys32_waitpid+0x20/0x38 [c000000008fb7e30] [c00000000000d500] syscall_exit+0x0/0x18 ifdown-connec S 000000000fe3bc9c 11800 9590 9565 9595 (NOTLB) Call Trace: [c00000000f1b78d0] [000028a7de9d8001] 0x28a7de9d8001 (unreliable) [c00000000f1b7aa0] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000f1b7b30] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000f1b7c50] [c000000000063e1c] .do_wait+0xe5c/0x11f4 [c00000000f1b7db0] [c00000000001c4c4] .sys32_waitpid+0x20/0x38 [c00000000f1b7e30] [c00000000000d500] syscall_exit+0x0/0x18 ip S 000000000ff4a668 12160 9595 9590 (NOTLB) Call Trace: [c00000000d947230] [c00000000009778c] .__alloc_pages+0x11c/0x5fc (unreliable) [c00000000d947400] [c0000000000126f4] .__switch_to+0xa4/0xf0 [c00000000d947490] [c0000000003fcd24] .schedule+0x3b8/0xc98 [c00000000d9475b0] [c0000000003fde80] .schedule_timeout+0x118/0x120 [c00000000d947690] [c00000000034a46c] .skb_recv_datagram+0x210/0x2f4 [c00000000d9477d0] [c00000000036f310] .netlink_recvmsg+0x7c/0x2cc [c00000000d9478c0] [c000000000340264] .sock_recvmsg+0x174/0x1c0 [c00000000d947ad0] [c000000000342aa0] .sys_recvmsg+0x154/0x350 [c00000000d947d00] [c000000000362084] .compat_sys_recvmsg+0x1c/0x34 [c00000000d947d80] [c000000000362b9c] .compat_sys_socketcall+0xf8/0x278 [c00000000d947e30] [c00000000000d500] syscall_exit+0x0/0x18 tg3: eth0: Link is down. tg3: eth0: Link is up at 1000 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. From jdmason@us.ibm.com Sat Feb 26 09:32:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 09:32:49 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QHWap6007209 for ; Sat, 26 Feb 2005 09:32:43 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1QHWUMN105184 for ; Sat, 26 Feb 2005 12:32:30 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1QHWUTk136252 for ; Sat, 26 Feb 2005 10:32:30 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1QHWUCk001534 for ; Sat, 26 Feb 2005 10:32:30 -0700 Received: from sig-9-65-35-105.mts.ibm.com (sig-9-65-35-105.mts.ibm.com [9.65.35.105]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1QHWUen001521; Sat, 26 Feb 2005 10:32:30 -0700 From: Jon Mason Organization: IBM To: Richard Dawe Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Date: Sat, 26 Feb 2005 11:32:29 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <42208D83.80803@phekda.gotadsl.co.uk> In-Reply-To: <42208D83.80803@phekda.gotadsl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502261132.29261.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7289 Lines: 203 On Saturday 26 February 2005 08:53 am, Richard Dawe wrote: > Hi Francois and Jon! > > Please find attached a patch that adds the hardware statistics ethtool > operations to the r8169 driver. It's against 2.6.11-rc5. Good Work! I'll give it a try here in a little bit. [...] > If I then bring the interface up ("ifconfig eth0 up"), I get valid stats. > > Any suggestions on how to fix this? I tried a couple of things: > > * Return in get_ethtool_stats if !netif_running(). Made no difference. > > * Zero the stats after creating the DMA mapping with > pci_alloc_consistent(). Made no difference. Can you confirm that the registers are outputting these bogus values? See comments below. --- linux-2.6.11-rc5/drivers/net/r8169.c.orig 2005-02-24 16:40:30.000000000 +0000 +++ linux-2.6.11-rc5/drivers/net/r8169.c 2005-02-26 14:28:37.000000000 +0000 @@ -128,6 +128,7 @@ static int multicast_filter_limit = 32; #define RX_BUF_SIZE 1536 /* Rx Buffer size */ #define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc)) #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc)) +#define R8169_STATS_BYTES 64 #define RTL8169_TX_TIMEOUT (6*HZ) #define RTL8169_PHY_TIMEOUT (10*HZ) @@ -187,6 +188,8 @@ static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ MAR0 = 8, /* Multicast filter. */ + StatsAddrLow = 0x10, + StatsAddrHigh = 0x14, TxDescStartAddrLow = 0x20, TxDescStartAddrHigh = 0x24, TxHDescStartAddrLow = 0x28, @@ -255,6 +258,9 @@ enum RTL8169_register_content { Cfg9346_Lock = 0x00, Cfg9346_Unlock = 0xC0, + /* StatsAddr register */ + DumpStats = (1 << 3), + Wouldn't this be better as "0x08"? Also, RTL8169_register_content could do with a bit of tidying (values are expressed in decimal and hex, some are aligned and others not, etc). I'll try and come-up with a patch here in a bit. /* rx_mode_bits */ AcceptErr = 0x20, AcceptRunt = 0x10, @@ -380,6 +386,22 @@ struct ring_info { u8 __pad[sizeof(void *) - sizeof(u32)]; }; +struct rtl8169_stats { + u64 tx_ok; + u64 rx_ok; + u64 tx_err; + u32 rx_err; + u16 rx_fifo; + u16 frame_align; + u32 tx_ok_1col; + u32 tx_ok_mcol; + u64 rx_ok_phys; + u64 rx_ok_bcast; + u32 rx_ok_mcast; + u16 tx_abort; + u16 tx_underrun; +} __attribute__((packed)); + These could all be u64's. It would take-up more memory (and a bit more code in the register dump), but the values would be more accurate. Just an idea. struct rtl8169_private { void __iomem *mmio_addr; /* memory map physical address */ struct pci_dev *pci_dev; /* Index of PCI device */ @@ -404,6 +426,8 @@ struct rtl8169_private { u16 intr_mask; int phy_auto_nego_reg; int phy_1000_ctrl_reg; + struct rtl8169_stats *nic_stats; + dma_addr_t nic_stats_addr; #ifdef CONFIG_R8169_VLAN struct vlan_group *vlgrp; #endif @@ -871,6 +895,68 @@ static void rtl8169_get_regs(struct net_ spin_unlock_irqrestore(&tp->lock, flags); } +static const char rtl8169_gstrings_stats[][ETH_GSTRING_LEN] = { + "tx_ok", "rx_ok", "tx_err", "rx_err", + "rx_fifo", "frame_align", "tx_ok_1col", "tx_ok_mcol", + "rx_ok_phys", "rx_ok_bcast", "rx_ok_mcast", "tx_abort", + "tx_underrun", +}; +#define RTL8169_STATS_LEN sizeof(rtl8169_gstrings_stats) / ETH_GSTRING_LEN + +static int rtl8169_get_stats_count(struct net_device *dev) +{ + return RTL8169_STATS_LEN; +} + +static void rtl8169_get_strings(struct net_device *netdev, u32 stringset, u8 *data) +{ + switch(stringset) { + case ETH_SS_STATS: + memcpy(data, *rtl8169_gstrings_stats, sizeof(rtl8169_gstrings_stats)); + break; + } +} + +static void rtl8169_get_ethtool_stats(struct net_device *netdev, + struct ethtool_stats *stats, u64 *data) +{ + struct rtl8169_private *tp = netdev_priv(netdev); + void __iomem *ioaddr = tp->mmio_addr; + int work = 100; + int i; + + /* begin NIC statistics dump */ + RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); + RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | DumpStats); + RTL_R32(StatsAddrLow); + + while (work-- > 0) { + if ((RTL_R32(StatsAddrLow) & DumpStats) == 0) + break; + cpu_relax(); + } + + if (RTL_R32(StatsAddrLow) & DumpStats) + return; /* no stats - took too long */ + + i = 0; + data[i++] = le64_to_cpu(tp->nic_stats->tx_ok); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok); + data[i++] = le64_to_cpu(tp->nic_stats->tx_err); + data[i++] = le32_to_cpu(tp->nic_stats->rx_err); + data[i++] = le16_to_cpu(tp->nic_stats->rx_fifo); + data[i++] = le16_to_cpu(tp->nic_stats->frame_align); + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_1col); + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_mcol); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_phys); + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_bcast); + data[i++] = le32_to_cpu(tp->nic_stats->rx_ok_mcast); + data[i++] = le16_to_cpu(tp->nic_stats->tx_abort); + data[i++] = le16_to_cpu(tp->nic_stats->tx_underrun); + if (i != RTL8169_STATS_LEN) + BUG(); +} + It seems to me that 'i' could be re-used, instead of having both 'i' and 'work'. Also, 'u32' or 'unsigned int' is prefered to int (see http://www.kroah.com/linux/talks/portable_kernel_code_talk_2001_10_02/mgp00022.html). Also, changes will need to be made if it is decided to use u64 (see above) static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, .get_regs_len = rtl8169_get_regs_len, @@ -886,6 +972,9 @@ static struct ethtool_ops rtl8169_ethtoo .get_tso = ethtool_op_get_tso, .set_tso = ethtool_op_set_tso, .get_regs = rtl8169_get_regs, + .get_strings = rtl8169_get_strings, + .get_stats_count = rtl8169_get_stats_count, + .get_ethtool_stats = rtl8169_get_ethtool_stats, }; static void rtl8169_write_gmii_reg_bit(void __iomem *ioaddr, int reg, int bitnum, @@ -1531,6 +1620,11 @@ static int rtl8169_open(struct net_devic if (retval < 0) goto err_free_rx; + tp->nic_stats = pci_alloc_consistent(pdev, R8169_STATS_BYTES, + &tp->nic_stats_addr); + if (!tp->nic_stats) + goto err_free_nic_stats; + INIT_WORK(&tp->task, NULL, dev); rtl8169_hw_start(dev); @@ -1541,6 +1635,10 @@ static int rtl8169_open(struct net_devic out: return retval; +err_free_nic_stats: + pci_free_consistent(pdev, R8169_STATS_BYTES, tp->nic_stats, + tp->nic_stats_addr); + err_free_rx: pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, tp->RxPhyAddr); From jgarzik@pobox.com Sat Feb 26 10:03:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 10:03:19 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QI37Vf008572 for ; Sat, 26 Feb 2005 10:03:07 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D56HM-0008Vo-V9; Sat, 26 Feb 2005 18:03:01 +0000 Message-ID: <4220B9C6.1010106@pobox.com> Date: Sat, 26 Feb 2005 13:02:46 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: Richard Dawe , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> In-Reply-To: <200502261132.29261.jdmason@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2073 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: 5432 Lines: 156 Jon Mason wrote: > On Saturday 26 February 2005 08:53 am, Richard Dawe wrote: > >>Hi Francois and Jon! >> >>Please find attached a patch that adds the hardware statistics ethtool >>operations to the r8169 driver. It's against 2.6.11-rc5. > > > Good Work! I'll give it a try here in a little bit. > > [...] > >>If I then bring the interface up ("ifconfig eth0 up"), I get valid stats. >> >>Any suggestions on how to fix this? I tried a couple of things: >> >>* Return in get_ethtool_stats if !netif_running(). Made no difference. >> >>* Zero the stats after creating the DMA mapping with >>pci_alloc_consistent(). Made no difference. > > > Can you confirm that the registers are outputting these bogus values? > > See comments below. > > > > --- linux-2.6.11-rc5/drivers/net/r8169.c.orig 2005-02-24 16:40:30.000000000 +0000 > +++ linux-2.6.11-rc5/drivers/net/r8169.c 2005-02-26 14:28:37.000000000 +0000 > @@ -128,6 +128,7 @@ static int multicast_filter_limit = 32; > #define RX_BUF_SIZE 1536 /* Rx Buffer size */ > #define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc)) > #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc)) > +#define R8169_STATS_BYTES 64 > > #define RTL8169_TX_TIMEOUT (6*HZ) > #define RTL8169_PHY_TIMEOUT (10*HZ) > @@ -187,6 +188,8 @@ static int use_dac; > enum RTL8169_registers { > MAC0 = 0, /* Ethernet hardware address. */ > MAR0 = 8, /* Multicast filter. */ > + StatsAddrLow = 0x10, > + StatsAddrHigh = 0x14, > TxDescStartAddrLow = 0x20, > TxDescStartAddrHigh = 0x24, > TxHDescStartAddrLow = 0x28, > @@ -255,6 +258,9 @@ enum RTL8169_register_content { > Cfg9346_Lock = 0x00, > Cfg9346_Unlock = 0xC0, > > + /* StatsAddr register */ > + DumpStats = (1 << 3), > + > > Wouldn't this be better as "0x08"? Also, RTL8169_register_content could do with a bit of tidying (values are expressed in decimal and hex, some are aligned and others not, etc). I'll try and come-up with a patch here in a bit. The form "(1 << n)" is preferred, since that form makes plain the bit number, with zero neural transformation required. Use the more readable form. Cleanup patches accepted. > /* rx_mode_bits */ > AcceptErr = 0x20, > AcceptRunt = 0x10, > @@ -380,6 +386,22 @@ struct ring_info { > u8 __pad[sizeof(void *) - sizeof(u32)]; > }; > > +struct rtl8169_stats { > + u64 tx_ok; > + u64 rx_ok; > + u64 tx_err; > + u32 rx_err; > + u16 rx_fifo; > + u16 frame_align; > + u32 tx_ok_1col; > + u32 tx_ok_mcol; > + u64 rx_ok_phys; > + u64 rx_ok_bcast; > + u32 rx_ok_mcast; > + u16 tx_abort; > + u16 tx_underrun; > +} __attribute__((packed)); > + > > > These could all be u64's. It would take-up more memory (and a bit more code in the register dump), but the values would be more accurate. Just an idea. No, this is the representation of the hardware DMA structure. It is defined by the hardware, not the programmer. > +static void rtl8169_get_ethtool_stats(struct net_device *netdev, > + struct ethtool_stats *stats, u64 *data) > +{ > + struct rtl8169_private *tp = netdev_priv(netdev); > + void __iomem *ioaddr = tp->mmio_addr; > + int work = 100; > + int i; > + > + /* begin NIC statistics dump */ > + RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); > + RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | DumpStats); > + RTL_R32(StatsAddrLow); > + > + while (work-- > 0) { > + if ((RTL_R32(StatsAddrLow) & DumpStats) == 0) > + break; > + cpu_relax(); > + } > + > + if (RTL_R32(StatsAddrLow) & DumpStats) > + return; /* no stats - took too long */ > + > + i = 0; > + data[i++] = le64_to_cpu(tp->nic_stats->tx_ok); > + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok); > + data[i++] = le64_to_cpu(tp->nic_stats->tx_err); > + data[i++] = le32_to_cpu(tp->nic_stats->rx_err); > + data[i++] = le16_to_cpu(tp->nic_stats->rx_fifo); > + data[i++] = le16_to_cpu(tp->nic_stats->frame_align); > + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_1col); > + data[i++] = le32_to_cpu(tp->nic_stats->tx_ok_mcol); > + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_phys); > + data[i++] = le64_to_cpu(tp->nic_stats->rx_ok_bcast); > + data[i++] = le32_to_cpu(tp->nic_stats->rx_ok_mcast); > + data[i++] = le16_to_cpu(tp->nic_stats->tx_abort); > + data[i++] = le16_to_cpu(tp->nic_stats->tx_underrun); > + if (i != RTL8169_STATS_LEN) > + BUG(); > +} > + > > It seems to me that 'i' could be re-used, instead of having both 'i' and 'work'. No. That's a completely useless pseudo-optimization. Write readable code, and let the compiler do the rest. Any modern compiler will see where the live range of 'work' ends, and 'i' begins. Also, 'u32' or 'unsigned int' is prefered to int (see http://www.kroah.com/linux/talks/portable_kernel_code_talk_2001_10_02/mgp00022.html). Also, changes will need to be made if it is decided to use u64 (see above) True, but irrelevant in this case. The code generated by the compiler is the same. Jeff From jgarzik@pobox.com Sat Feb 26 10:03:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 10:04:03 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QI3vIp008832 for ; Sat, 26 Feb 2005 10:03:57 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D56IG-00005E-C9; Sat, 26 Feb 2005 18:03:56 +0000 Message-ID: <4220B9FE.6040304@pobox.com> Date: Sat, 26 Feb 2005 13:03:42 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: Richard Dawe , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> <4220B9C6.1010106@pobox.com> In-Reply-To: <4220B9C6.1010106@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2074 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: 57 Lines: 6 Also, please turn on word wrap in your mailer. Jeff From romieu@fr.zoreil.com Sat Feb 26 10:16:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 10:16:14 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QIG2h7009899 for ; Sat, 26 Feb 2005 10:16:03 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1QICJV6013517; Sat, 26 Feb 2005 19:12:19 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1QICDGN013516; Sat, 26 Feb 2005 19:12:13 +0100 Date: Sat, 26 Feb 2005 19:12:13 +0100 From: Francois Romieu To: Jeff Garzik Cc: Jon Mason , Richard Dawe , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Message-ID: <20050226181213.GA13230@electric-eye.fr.zoreil.com> References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> <4220B9C6.1010106@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4220B9C6.1010106@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2075 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: 1428 Lines: 47 Jeff Garzik : [...] > >+static void rtl8169_get_ethtool_stats(struct net_device *netdev, > >+ struct ethtool_stats *stats, u64 *data) > >+{ > >+ struct rtl8169_private *tp = netdev_priv(netdev); > >+ void __iomem *ioaddr = tp->mmio_addr; > >+ int work = 100; > >+ int i; > >+ > >+ /* begin NIC statistics dump */ > >+ RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); > >+ RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | > >DumpStats); > >+ RTL_R32(StatsAddrLow); > >+ > >+ while (work-- > 0) { > >+ if ((RTL_R32(StatsAddrLow) & DumpStats) == 0) > >+ break; > >+ cpu_relax(); > >+ } > >+ > >+ if (RTL_R32(StatsAddrLow) & DumpStats) > >+ return; /* no stats - took too long */ > >+ > >+ i = 0; > >+ data[i++] = le64_to_cpu(tp->nic_stats->tx_ok); [...] > >+ data[i++] = le16_to_cpu(tp->nic_stats->tx_underrun); > >+ if (i != RTL8169_STATS_LEN) > >+ BUG(); > >+} > >+ > > > >It seems to me that 'i' could be re-used, instead of having both 'i' and > >'work'. > > No. That's a completely useless pseudo-optimization. Write readable > code, and let the compiler do the rest. Btw I'd simply remove the 'work' variable and schedule in an interruptible way until the dump is done. BUG() is a bit exagerated imho. -- Ueimor From romieu@fr.zoreil.com Sat Feb 26 10:28:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 10:28:12 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QIRx1s010859 for ; Sat, 26 Feb 2005 10:28:00 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1QIR72r013792; Sat, 26 Feb 2005 19:27:08 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1QIQwiv013791; Sat, 26 Feb 2005 19:26:58 +0100 Date: Sat, 26 Feb 2005 19:26:58 +0100 From: Francois Romieu To: Richard Dawe Cc: Jon Mason , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Message-ID: <20050226182658.GB13230@electric-eye.fr.zoreil.com> References: <42208D83.80803@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42208D83.80803@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2076 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: 1188 Lines: 51 Richard Dawe : [...] > @@ -1531,6 +1620,11 @@ static int rtl8169_open(struct net_devic > if (retval < 0) > goto err_free_rx; > > + tp->nic_stats = pci_alloc_consistent(pdev, R8169_STATS_BYTES, > + &tp->nic_stats_addr); > + if (!tp->nic_stats) > + goto err_free_nic_stats; > + > INIT_WORK(&tp->task, NULL, dev); > > rtl8169_hw_start(dev); > @@ -1541,6 +1635,10 @@ static int rtl8169_open(struct net_devic > out: > return retval; > > +err_free_nic_stats: > + pci_free_consistent(pdev, R8169_STATS_BYTES, tp->nic_stats, > + tp->nic_stats_addr); > + You don't want to free it it was not allocated. Please undo the previous step (init_ring probably) and: 1) use the form "goto err_descriptive_name_for_the_release_work"; 2) if you feel it does not protect against wrong ordering as: if (...) goto err_foo; if (...) goto err_bar; [...] err_foo: ... err_bar: ... then add extra numbering: if (...) goto err_foo_0; if (...) goto err_bar_1; [...] err_bar_1: ... err_foo_0: ... It is not perfect but it is error proof (something the "goto err_1" way alone can not claim btw). -- Ueimor From jdmason@us.ibm.com Sat Feb 26 10:36:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 10:36:28 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QIaOf5011617 for ; Sat, 26 Feb 2005 10:36:24 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1QIaIMN429560 for ; Sat, 26 Feb 2005 13:36:18 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1QIaIjF132822 for ; Sat, 26 Feb 2005 11:36:18 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1QIaIvk014884 for ; Sat, 26 Feb 2005 11:36:18 -0700 Received: from sig-9-65-35-105.mts.ibm.com (sig-9-65-35-105.mts.ibm.com [9.65.35.105]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1QIaHPp014878; Sat, 26 Feb 2005 11:36:18 -0700 From: Jon Mason Organization: IBM To: Jeff Garzik Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Date: Sat, 26 Feb 2005 12:36:17 -0600 User-Agent: KMail/1.7.2 Cc: Richard Dawe , Francois Romieu , netdev@oss.sgi.com References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> <4220B9C6.1010106@pobox.com> In-Reply-To: <4220B9C6.1010106@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502261236.17332.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1931 Lines: 59 On Saturday 26 February 2005 12:02 pm, Jeff Garzik wrote: [...] > > @@ -255,6 +258,9 @@ enum RTL8169_register_content { > > Cfg9346_Lock = 0x00, > > Cfg9346_Unlock = 0xC0, > > > > + /* StatsAddr register */ > > + DumpStats = (1 << 3), > > + > > > > Wouldn't this be better as "0x08"? Also, RTL8169_register_content could > > do with a bit of tidying (values are expressed in decimal and hex, some > > are aligned and others not, etc). I'll try and come-up with a patch here > > in a bit. > > The form "(1 << n)" is preferred, since that form makes plain the bit > number, with zero neural transformation required. > > Use the more readable form. Cleanup patches accepted. My suggestion was based on code uniformity (as the rest of the values are defined as dex or decimal numbers). Which takes presidense, uniformity or readablity? If it is the latter, should the rest of thse values be redefined? > > > /* rx_mode_bits */ > > AcceptErr = 0x20, > > AcceptRunt = 0x10, > > @@ -380,6 +386,22 @@ struct ring_info { > > u8 __pad[sizeof(void *) - sizeof(u32)]; > > }; > > > > +struct rtl8169_stats { > > + u64 tx_ok; > > + u64 rx_ok; > > + u64 tx_err; > > + u32 rx_err; > > + u16 rx_fifo; > > + u16 frame_align; > > + u32 tx_ok_1col; > > + u32 tx_ok_mcol; > > + u64 rx_ok_phys; > > + u64 rx_ok_bcast; > > + u32 rx_ok_mcast; > > + u16 tx_abort; > > + u16 tx_underrun; > > +} __attribute__((packed)); > > + > > > > > > These could all be u64's. It would take-up more memory (and a bit more code in the register dump), but the values would be more accurate. Just an idea. > > No, this is the representation of the hardware DMA structure. > > It is defined by the hardware, not the programmer. Sorry, didn't see that on the first pass. My apologies. Jon From rich@phekda.gotadsl.co.uk Sat Feb 26 11:19:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 11:19:09 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QJJ2ww013403 for ; Sat, 26 Feb 2005 11:19:02 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (81-6-225-151.dyn.gotadsl.co.uk [81.6.225.151]) by smtp.nildram.co.uk (Postfix) with ESMTP id 92AA22C25D5; Sat, 26 Feb 2005 19:18:57 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 1A56C381DC; Sat, 26 Feb 2005 17:11:03 +0000 (GMT) Message-ID: <4220ADA6.2040506@phekda.gotadsl.co.uk> Date: Sat, 26 Feb 2005 17:11:02 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH]: r8169: Message level support Content-Type: multipart/mixed; boundary="------------050907010104070002090802" X-Virus-Scanned: ClamAV 0.83/728/Sat Feb 26 02:22:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2078 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 17611 Lines: 527 This is a multi-part message in MIME format. --------------050907010104070002090802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. The attached patch against 2.6.11-rc5 adds support for setting the message level, which controls which messages are actually printk()'d. Changes: * A module option "debug". This option is a bitfield of message options, like 8139cp's "debug" parameter. * Support "ethtool -s ... msglvl". This sets the bitfield. * Various debug messages are now enabled on NETIF_MSG_HW and are printed using KERN_DEBUG. * Messages are printed when the interface goes up or down. There seems to be a mixture of drivers using a bitfield and a level. Which is the currently preferred mechanism? Bye, Rich =] Signed-Off-By: Richard Dawe --------------050907010104070002090802 Content-Type: text/plain; name="r8169-netif-msg.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169-netif-msg.diff" --- linux-2.6.11-rc5/drivers/net/r8169.c.orig 2005-02-24 16:40:30.000000000 +0000 +++ linux-2.6.11-rc5/drivers/net/r8169.c 2005-02-26 16:49:16.000000000 +0000 @@ -79,12 +79,14 @@ VERSION 2.2LK <2005/01/25> printk( "Assertion failed! %s,%s,%s,line=%d\n", \ #expr,__FILE__,__FUNCTION__,__LINE__); \ } -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0) #else #define assert(expr) do {} while (0) -#define dprintk(fmt, args...) do {} while (0) #endif /* RTL8169_DEBUG */ +#define DPRINTK(nlevel, klevel, fmt, args...) \ + (void)((NETIF_MSG_##nlevel & tp->msg_enable) && \ + printk(KERN_##klevel PFX "%s: " fmt, dev->name, ## args)) + #define TX_BUFFS_AVAIL(tp) \ (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx - 1) @@ -132,6 +134,10 @@ static int multicast_filter_limit = 32; #define RTL8169_TX_TIMEOUT (6*HZ) #define RTL8169_PHY_TIMEOUT (10*HZ) +#define RTL8169_DEF_MSG_ENABLE (NETIF_MSG_DRV | \ + NETIF_MSG_PROBE | \ + NETIF_MSG_LINK) + /* write/read MMIO register */ #define RTL_W8(reg, val8) writeb ((val8), ioaddr + (reg)) #define RTL_W16(reg, val16) writew ((val16), ioaddr + (reg)) @@ -407,6 +413,7 @@ struct rtl8169_private { #ifdef CONFIG_R8169_VLAN struct vlan_group *vlgrp; #endif + u32 msg_enable; int (*set_speed)(struct net_device *, u8 autoneg, u16 speed, u8 duplex); void (*get_settings)(struct net_device *, struct ethtool_cmd *); void (*phy_reset_enable)(void __iomem *); @@ -421,6 +428,9 @@ module_param_array(media, int, &num_medi module_param(rx_copybreak, int, 0); module_param(use_dac, int, 0); MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); +static int debug = RTL8169_DEF_MSG_ENABLE; +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, "Bitmapped message enable number"); MODULE_LICENSE("GPL"); MODULE_VERSION(RTL8169_VERSION); @@ -433,10 +443,10 @@ static void rtl8169_hw_start(struct net_ static int rtl8169_close(struct net_device *dev); static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev); static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, void __iomem *); -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu); static void rtl8169_down(struct net_device *dev); #ifdef CONFIG_R8169_NAPI @@ -543,14 +553,15 @@ static void rtl8169_check_link_status(st spin_lock_irqsave(&tp->lock, flags); if (tp->link_ok(ioaddr)) { netif_carrier_on(dev); - printk(KERN_INFO PFX "%s: link up\n", dev->name); + DPRINTK(LINK, INFO, "link up\n"); } else netif_carrier_off(dev); spin_unlock_irqrestore(&tp->lock, flags); } -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) +static void rtl8169_link_option(struct net_device *dev, int idx, u8 *autoneg, u16 *speed, u8 *duplex) { + struct rtl8169_private *tp = netdev_priv(dev); struct { u16 speed; u8 duplex; @@ -570,7 +581,7 @@ static void rtl8169_link_option(int idx, option = ((idx < MAX_UNITS) && (idx >= 0)) ? media[idx] : 0xff; if ((option != 0xff) && !idx) - printk(KERN_WARNING PFX "media option is deprecated.\n"); + DPRINTK(DRV, WARNING, "media option is deprecated.\n"); for (p = link_settings; p->media != 0xff; p++) { if (p->media == option) @@ -611,9 +622,8 @@ static int rtl8169_set_speed_tbi(struct } else if (autoneg == AUTONEG_ENABLE) RTL_W32(TBICSR, reg | TBINwEnable | TBINwRestart); else { - printk(KERN_WARNING PFX - "%s: incorrect speed setting refused in TBI mode\n", - dev->name); + DPRINTK(LINK, WARNING, + "incorrect speed setting refused in TBI mode\n"); ret = -EOPNOTSUPP; } @@ -871,6 +881,18 @@ static void rtl8169_get_regs(struct net_ spin_unlock_irqrestore(&tp->lock, flags); } +static u32 r8169_get_msglevel(struct net_device *dev) +{ + struct rtl8169_private *tp = netdev_priv(dev); + return tp->msg_enable; +} + +static void r8169_set_msglevel(struct net_device *dev, u32 value) +{ + struct rtl8169_private *tp = netdev_priv(dev); + tp->msg_enable = value; +} + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, .get_regs_len = rtl8169_get_regs_len, @@ -886,6 +908,8 @@ static struct ethtool_ops rtl8169_ethtoo .get_tso = ethtool_op_get_tso, .set_tso = ethtool_op_set_tso, .get_regs = rtl8169_get_regs, + .get_msglevel = r8169_get_msglevel, + .set_msglevel = r8169_set_msglevel, }; static void rtl8169_write_gmii_reg_bit(void __iomem *ioaddr, int reg, int bitnum, @@ -932,12 +956,15 @@ static void rtl8169_print_mac_version(st for (p = mac_print; p->msg; p++) { if (tp->mac_version == p->version) { - dprintk("mac_version == %s (%04d)\n", p->msg, - p->version); + if (netif_msg_hw(tp)) + printk(KERN_DEBUG + "mac_version == %s (%04d)\n", + p->msg, p->version); return; } } - dprintk("mac_version == Unknown\n"); + if (netif_msg_hw(tp)) + printk(KERN_DEBUG "mac_version == Unknown\n"); } static void rtl8169_get_phy_version(struct rtl8169_private *tp, void __iomem *ioaddr) @@ -976,11 +1003,15 @@ static void rtl8169_print_phy_version(st for (p = phy_print; p->msg; p++) { if (tp->phy_version == p->version) { - dprintk("phy_version == %s (%04x)\n", p->msg, p->reg); + if (netif_msg_hw(tp)) + printk(KERN_DEBUG + "phy_version == %s (%04x)\n", + p->msg, p->reg); return; } } - dprintk("phy_version == Unknown\n"); + if (netif_msg_hw(tp)) + printk(KERN_DEBUG "phy_version == Unknown\n"); } static void rtl8169_hw_phy_config(struct net_device *dev) @@ -1027,8 +1058,8 @@ static void rtl8169_hw_phy_config(struct if (tp->phy_version >= RTL_GIGA_PHY_VER_H) return; - dprintk("MAC version != 0 && PHY version == 0 or 1\n"); - dprintk("Do final_reg2.cfg\n"); + DPRINTK(HW, DEBUG, "MAC version != 0 && PHY version == 0 or 1\n"); + DPRINTK(HW, DEBUG, "Do final_reg2.cfg\n"); /* Shazam ! */ @@ -1091,7 +1122,7 @@ static void rtl8169_phy_timer(unsigned l if (tp->link_ok(ioaddr)) goto out_unlock; - printk(KERN_WARNING PFX "%s: PHY reset until link up\n", dev->name); + DPRINTK(LINK, WARNING, "PHY reset until link up\n"); tp->phy_reset_enable(ioaddr); @@ -1169,7 +1200,8 @@ rtl8169_init_board(struct pci_dev *pdev, /* dev zeroed in alloc_etherdev */ dev = alloc_etherdev(sizeof (*tp)); if (dev == NULL) { - printk(KERN_ERR PFX "unable to alloc new ethernet\n"); + if (debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "unable to alloc new ethernet\n"); goto err_out; } @@ -1177,10 +1209,15 @@ rtl8169_init_board(struct pci_dev *pdev, SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); + tp->msg_enable = debug; + /* enable device (incl. PCI PM wakeup and hotplug setup) */ rc = pci_enable_device(pdev); if (rc) { - printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "%s: enable failure\n", + pdev->slot_name); goto err_out_free_dev; } @@ -1196,29 +1233,35 @@ rtl8169_init_board(struct pci_dev *pdev, pci_read_config_word(pdev, pm_cap + PCI_PM_CTRL, &pwr_command); acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK; } else { - printk(KERN_ERR PFX - "Cannot find PowerManagement capability, aborting.\n"); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "Cannot find PowerManagement capability, aborting.\n"); goto err_out_mwi; } /* make sure PCI base addr 1 is MMIO */ if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) { - printk(KERN_ERR PFX - "region #1 not an MMIO resource, aborting\n"); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "region #1 not an MMIO resource, aborting\n"); rc = -ENODEV; goto err_out_mwi; } /* check for weird/broken PCI region reporting */ if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) { - printk(KERN_ERR PFX "Invalid PCI region size(s), aborting\n"); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "Invalid PCI region size(s), aborting\n"); rc = -ENODEV; goto err_out_mwi; } rc = pci_request_regions(pdev, MODULENAME); if (rc) { - printk(KERN_ERR PFX "%s: could not request regions.\n", - pdev->slot_name); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "%s: could not request regions.\n", + pdev->slot_name); goto err_out_mwi; } @@ -1231,7 +1274,9 @@ rtl8169_init_board(struct pci_dev *pdev, } else { rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc < 0) { - printk(KERN_ERR PFX "DMA configuration failed.\n"); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX + "DMA configuration failed.\n"); goto err_out_free_res; } } @@ -1241,7 +1286,8 @@ rtl8169_init_board(struct pci_dev *pdev, /* ioremap MMIO region */ ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE); if (ioaddr == NULL) { - printk(KERN_ERR PFX "cannot remap MMIO, aborting\n"); + if (netif_msg_probe(tp)) + printk(KERN_ERR PFX "cannot remap MMIO, aborting\n"); rc = -EIO; goto err_out_free_res; } @@ -1272,9 +1318,10 @@ rtl8169_init_board(struct pci_dev *pdev, } if (i < 0) { /* Unknown chip: assume array element #0, original RTL-8169 */ - printk(KERN_DEBUG PFX - "PCI device %s: unknown chip version, assuming %s\n", - pci_name(pdev), rtl_chip_info[0].name); + if (netif_msg_probe(tp)) + printk(KERN_DEBUG PFX + "PCI device %s: unknown chip version, assuming %s\n", + pci_name(pdev), rtl_chip_info[0].name); i++; } tp->chipset = i; @@ -1391,39 +1438,40 @@ rtl8169_init_one(struct pci_dev *pdev, c return rc; } - printk(KERN_DEBUG "%s: Identified chip type is '%s'.\n", dev->name, - rtl_chip_info[tp->chipset].name); + DPRINTK(PROBE, DEBUG, + "Identified chip type is '%s'.\n", + rtl_chip_info[tp->chipset].name); pci_set_drvdata(pdev, dev); - printk(KERN_INFO "%s: %s at 0x%lx, " - "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " - "IRQ %d\n", - dev->name, - rtl_chip_info[ent->driver_data].name, - dev->base_addr, - dev->dev_addr[0], dev->dev_addr[1], - dev->dev_addr[2], dev->dev_addr[3], - dev->dev_addr[4], dev->dev_addr[5], dev->irq); + DPRINTK(PROBE, INFO, + "%s at 0x%lx, " + "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " + "IRQ %d\n", + rtl_chip_info[ent->driver_data].name, + dev->base_addr, + dev->dev_addr[0], dev->dev_addr[1], + dev->dev_addr[2], dev->dev_addr[3], + dev->dev_addr[4], dev->dev_addr[5], dev->irq); rtl8169_hw_phy_config(dev); - dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); + DPRINTK(HW, DEBUG, "Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); RTL_W8(0x82, 0x01); if (tp->mac_version < RTL_GIGA_MAC_VER_E) { - dprintk("Set PCI Latency=0x40\n"); + DPRINTK(HW, DEBUG, "Set PCI Latency=0x40\n"); pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40); } if (tp->mac_version == RTL_GIGA_MAC_VER_D) { - dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); + DPRINTK(HW, DEBUG, "Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); RTL_W8(0x82, 0x01); - dprintk("Set PHY Reg 0x0bh = 0x00h\n"); + DPRINTK(HW, DEBUG, "Set PHY Reg 0x0bh = 0x00h\n"); mdio_write(ioaddr, 0x0b, 0x0000); //w 0x0b 15 0 0 } - rtl8169_link_option(board_idx, &autoneg, &speed, &duplex); + rtl8169_link_option(dev, board_idx, &autoneg, &speed, &duplex); rtl8169_set_speed(dev, autoneg, speed, duplex); @@ -1504,6 +1552,8 @@ static int rtl8169_open(struct net_devic struct pci_dev *pdev = tp->pci_dev; int retval; + DPRINTK(IFUP, DEBUG, "enabling interface\n"); + rtl8169_set_rxbufsize(tp, dev); retval = @@ -1602,7 +1652,8 @@ rtl8169_hw_start(struct net_device *dev) if ((tp->mac_version == RTL_GIGA_MAC_VER_D) || (tp->mac_version == RTL_GIGA_MAC_VER_E)) { - dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " + DPRINTK(HW, DEBUG, + "Set MAC Reg C+CR Offset 0xE0. " "Bit-3 and bit-14 MUST be 1\n"); tp->cp_cmd |= (1 << 14) | PCIMulRW; RTL_W16(CPlusCmd, tp->cp_cmd); @@ -1857,8 +1908,12 @@ static void rtl8169_reinit_task(void *_d ret = rtl8169_open(dev); if (unlikely(ret < 0)) { if (net_ratelimit()) { - printk(PFX KERN_ERR "%s: reinit failure (status = %d)." - " Rescheduling.\n", dev->name, ret); + struct rtl8169_private *tp = netdev_priv(dev); + + DPRINTK(TIMER, ERR, + "reinit failure (status = %d)." + " Rescheduling.\n", + ret); } rtl8169_schedule_work(dev, rtl8169_reinit_task); } @@ -1883,8 +1938,7 @@ static void rtl8169_reset_task(void *_da netif_wake_queue(dev); } else { if (net_ratelimit()) { - printk(PFX KERN_EMERG "%s: Rx buffers shortage\n", - dev->name); + DPRINTK(TX_ERR, EMERG, "Rx buffers shortage\n"); } rtl8169_schedule_work(dev, rtl8169_reset_task); } @@ -1970,8 +2024,7 @@ static int rtl8169_start_xmit(struct sk_ int ret = 0; if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) { - printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", - dev->name); + DPRINTK(TX_ERR, ERR, "BUG! Tx Ring full when queue awake!\n"); goto err_stop; } @@ -2046,8 +2099,9 @@ static void rtl8169_pcierr_interrupt(str pci_read_config_word(pdev, PCI_COMMAND, &pci_cmd); pci_read_config_word(pdev, PCI_STATUS, &pci_status); - printk(KERN_ERR PFX "%s: PCI error (cmd = 0x%04x, status = 0x%04x).\n", - dev->name, pci_cmd, pci_status); + DPRINTK(INTR, ERR, + "PCI error (cmd = 0x%04x, status = 0x%04x).\n", + pci_cmd, pci_status); /* * The recovery sequence below admits a very elaborated explanation: @@ -2066,7 +2120,7 @@ static void rtl8169_pcierr_interrupt(str /* The infamous DAC f*ckup only happens at boot time */ if ((tp->cp_cmd & PCIDAC) && !tp->dirty_rx && !tp->cur_rx) { - printk(KERN_INFO PFX "%s: disabling PCI DAC.\n", dev->name); + DPRINTK(INTR, INFO, "disabling PCI DAC.\n"); tp->cp_cmd &= ~PCIDAC; RTL_W16(CPlusCmd, tp->cp_cmd); dev->features &= ~NETIF_F_HIGHDMA; @@ -2182,7 +2236,7 @@ rtl8169_rx_interrupt(struct net_device * if (status & DescOwn) break; if (status & RxRES) { - printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); + DPRINTK(RX_ERR, INFO, "Rx ERROR!!!\n"); tp->stats.rx_errors++; if (status & (RxRWT | RxRUNT)) tp->stats.rx_length_errors++; @@ -2231,7 +2285,7 @@ rtl8169_rx_interrupt(struct net_device * delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); if (!delta && count) - printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); + DPRINTK(RX_ERR, INFO, "no Rx buffer allocated\n"); tp->dirty_rx += delta; /* @@ -2242,7 +2296,7 @@ rtl8169_rx_interrupt(struct net_device * * - how do others driver handle this condition (Uh oh...). */ if (tp->dirty_rx + NUM_RX_DESC == tp->cur_rx) - printk(KERN_EMERG "%s: Rx buffers exhausted\n", dev->name); + DPRINTK(RX_ERR, EMERG, "Rx buffers exhausted\n"); return count; } @@ -2294,8 +2348,9 @@ rtl8169_interrupt(int irq, void *dev_ins if (likely(netif_rx_schedule_prep(dev))) __netif_rx_schedule(dev); else { - printk(KERN_INFO "%s: interrupt %04x taken in poll\n", - dev->name, status); + DPRINTK(INTR, INFO, + "interrupt %04x taken in poll\n", + status); } break; #else @@ -2312,8 +2367,7 @@ rtl8169_interrupt(int irq, void *dev_ins } while (boguscnt > 0); if (boguscnt <= 0) { - printk(KERN_WARNING "%s: Too much work at interrupt!\n", - dev->name); + DPRINTK(INTR, WARNING, "Too much work at interrupt!\n"); /* Clear all interrupt sources. */ RTL_W16(IntrStatus, 0xffff); } @@ -2408,6 +2462,8 @@ static int rtl8169_close(struct net_devi struct rtl8169_private *tp = netdev_priv(dev); struct pci_dev *pdev = tp->pci_dev; + DPRINTK(IFDOWN, DEBUG, "disabling interface\n"); + rtl8169_down(dev); free_irq(dev->irq, dev); @@ -2436,8 +2492,7 @@ rtl8169_set_rx_mode(struct net_device *d if (dev->flags & IFF_PROMISC) { /* Unconditionally log net taps. */ - printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", - dev->name); + DPRINTK(DRV, NOTICE, "Promiscuous mode enabled.\n"); rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys | AcceptAllPhys; --------------050907010104070002090802-- From romieu@fr.zoreil.com Sat Feb 26 12:36:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 12:36:08 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QKa17p019109 for ; Sat, 26 Feb 2005 12:36:02 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1QKZOE0015261; Sat, 26 Feb 2005 21:35:24 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1QKZIDf015260; Sat, 26 Feb 2005 21:35:18 +0100 Date: Sat, 26 Feb 2005 21:35:18 +0100 From: Francois Romieu To: Richard Dawe Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH]: r8169: Message level support Message-ID: <20050226203518.GA14688@electric-eye.fr.zoreil.com> References: <4220ADA6.2040506@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4220ADA6.2040506@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/728/Sat Feb 26 02:22:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2079 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: 5356 Lines: 163 Jeff, can you send a ack/nack if you disagree with the remarks below ? Richard Dawe : [...] > There seems to be a mixture of drivers using a bitfield and a level. > Which is the currently preferred mechanism? They do not offer exactly the same range. I prefer to keep both as the module option is not that expensive. [...] > --- linux-2.6.11-rc5/drivers/net/r8169.c.orig 2005-02-24 16:40:30.000000000 +0000 > +++ linux-2.6.11-rc5/drivers/net/r8169.c 2005-02-26 16:49:16.000000000 +0000 > @@ -79,12 +79,14 @@ VERSION 2.2LK <2005/01/25> > printk( "Assertion failed! %s,%s,%s,line=%d\n", \ > #expr,__FILE__,__FUNCTION__,__LINE__); \ > } > -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0) > #else > #define assert(expr) do {} while (0) > -#define dprintk(fmt, args...) do {} while (0) > #endif /* RTL8169_DEBUG */ > > +#define DPRINTK(nlevel, klevel, fmt, args...) \ > + (void)((NETIF_MSG_##nlevel & tp->msg_enable) && \ > + printk(KERN_##klevel PFX "%s: " fmt, dev->name, ## args)) > + 1 - I am not fond of shouting macro. Everything starts turnings caps. Any reason to not use "dprintk" ? 2 - Imho the driver should not poke its nose into the guts of netif_msg_xxx(). It defeats its whole purpose. Any objection to not use it explicitely ? 3 - If PFX is included, we'll have a mix of printk and dprintk. My personal taste would be to not include it in the definition of the macro. > #define TX_BUFFS_AVAIL(tp) \ > (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx - 1) > > @@ -132,6 +134,10 @@ static int multicast_filter_limit = 32; > #define RTL8169_TX_TIMEOUT (6*HZ) > #define RTL8169_PHY_TIMEOUT (10*HZ) > > +#define RTL8169_DEF_MSG_ENABLE (NETIF_MSG_DRV | \ > + NETIF_MSG_PROBE | \ > + NETIF_MSG_LINK) It's up to you but I'd rather see: #define RTL8169_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) [...] @@ -433,10 +443,10 @@ static void rtl8169_hw_start(struct net_ static int rtl8169_close(struct net_device *dev); static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev); static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, void __iomem *); -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu); static void rtl8169_down(struct net_device *dev); #ifdef CONFIG_R8169_NAPI Separate patch please. @@ -543,14 +553,15 @@ static void rtl8169_check_link_status(st spin_lock_irqsave(&tp->lock, flags); if (tp->link_ok(ioaddr)) { netif_carrier_on(dev); - printk(KERN_INFO PFX "%s: link up\n", dev->name); + DPRINTK(LINK, INFO, "link up\n"); } else netif_carrier_off(dev); spin_unlock_irqrestore(&tp->lock, flags); } -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) +static void rtl8169_link_option(struct net_device *dev, int idx, u8 *autoneg, u16 *speed, u8 *duplex) { + struct rtl8169_private *tp = netdev_priv(dev); struct { u16 speed; u8 duplex; Why not give a struct rtl8169_private * as argument to this function ? [...] > @@ -871,6 +881,18 @@ static void rtl8169_get_regs(struct net_ > spin_unlock_irqrestore(&tp->lock, flags); > } > > +static u32 r8169_get_msglevel(struct net_device *dev) > +{ > + struct rtl8169_private *tp = netdev_priv(dev); > + return tp->msg_enable; > +} Variable declaration and code are always separated by an empty line in the current driver. Please keep it this way. > > for (p = mac_print; p->msg; p++) { > if (tp->mac_version == p->version) { > - dprintk("mac_version == %s (%04d)\n", p->msg, > - p->version); > + if (netif_msg_hw(tp)) > + printk(KERN_DEBUG > + "mac_version == %s (%04d)\n", No need to add a line: you are allowed to use the whole 80 cols range. [...] > @@ -1091,7 +1122,7 @@ static void rtl8169_phy_timer(unsigned l > if (tp->link_ok(ioaddr)) > goto out_unlock; > > - printk(KERN_WARNING PFX "%s: PHY reset until link up\n", dev->name); > + DPRINTK(LINK, WARNING, "PHY reset until link up\n"); > > tp->phy_reset_enable(ioaddr); > > @@ -1169,7 +1200,8 @@ rtl8169_init_board(struct pci_dev *pdev, > /* dev zeroed in alloc_etherdev */ > dev = alloc_etherdev(sizeof (*tp)); > if (dev == NULL) { > - printk(KERN_ERR PFX "unable to alloc new ethernet\n"); > + if (debug & NETIF_MSG_PROBE) > + printk(KERN_ERR PFX "unable to alloc new ethernet\n"); > goto err_out; > } > Can you do something like: struct { u32 msg_enable; } debug; This way it will be possible to issue netif_msg_probe(&debug). > @@ -1177,10 +1209,15 @@ rtl8169_init_board(struct pci_dev *pdev, > SET_NETDEV_DEV(dev, &pdev->dev); > tp = netdev_priv(dev); > > + tp->msg_enable = debug; > + > /* enable device (incl. PCI PM wakeup and hotplug setup) */ > rc = pci_enable_device(pdev); > if (rc) { > - printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); > + if (netif_msg_probe(tp)) > + printk(KERN_ERR PFX > + "%s: enable failure\n", > + pdev->slot_name); Use dprintk ? -- Ueimor From jgarzik@pobox.com Sat Feb 26 13:21:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 13:21:21 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QLLDU4020728 for ; Sat, 26 Feb 2005 13:21:14 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D59N4-0003nY-H8; Sat, 26 Feb 2005 21:21:06 +0000 Message-ID: <4220E82B.6080309@pobox.com> Date: Sat, 26 Feb 2005 16:20:43 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Richard Dawe , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Message level support References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> In-Reply-To: <20050226203518.GA14688@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/728/Sat Feb 26 02:22:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2080 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: 738 Lines: 26 Francois Romieu wrote: > Jeff, can you send a ack/nack if you disagree with the remarks below ? > > Richard Dawe : > [...] > >>There seems to be a mixture of drivers using a bitfield and a level. >>Which is the currently preferred mechanism? > > > They do not offer exactly the same range. I prefer to keep both as the > module option is not that expensive. * The preferred mechanism is to have an integer verbosity level 'debug', which is converted using netif_msg_init() into a bitmap. * PFX should only be used in probe paths. In all other cases, dev->name should be used. * I strongly agree with the comment "Imho the driver should not poke its nose into the guts of netif_msg_xxx()" Jeff From idallen@idallen.ca Sat Feb 26 15:37:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Feb 2005 15:37:15 -0800 (PST) Received: from home.idallen.ca (cpu1808.adsl.bellglobal.com [206.47.37.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1QNb83v024971 for ; Sat, 26 Feb 2005 15:37:08 -0800 Received: by elm.home.idallen.ca (Postfix, from userid 777) id A92976CC033; Sat, 26 Feb 2005 18:37:07 -0500 (EST) Date: Sat, 26 Feb 2005 18:37:07 -0500 From: "Ian! D. Allen" To: netdev@oss.sgi.com Subject: rp_filter interaction with netfilter SNAT/un-SNAT Message-ID: <20050226233707.GA11802@elm.home.idallen.ca> References: <20050226161836.GA15277@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050226161836.GA15277@suse.de> X-Operating-System: Linux Organization: Ian! D. Allen, Ottawa, Ontario, CANADA - http://www.idallen.com/ User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.83/728/Sat Feb 26 02:22:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2081 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: idallen@idallen.ca Precedence: bulk X-list: netdev Content-Length: 4662 Lines: 92 I am using netfilter to mark packets that have a given session id (--sid-owner). I then SNAT the marked packets to have an eth2 source address 66.11.175.98. I use iproute2 to divert these fwmark marked packets out eth2 instead of the default eth0. Tcpdump confirms that the packets leave eth2 with the correct source address. Return packets come back with the correct eth2 destination address. Then, the 2.6.10 kernel rp_filter mysteriously rejects the returning packets as martians with a bad source address. For example: # ping google.ca PING google.ca (216.239.59.104) 56(84) bytes of data. --- google.ca ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms The ping packets as seen by tcpdump going out/in on eth2 (66.11.175.98): 15:46:46.058033 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) 66.11.175.98 > 216.239.59.104: icmp 64: echo request seq 1 15:46:46.215603 IP (tos 0x0, ttl 239, id 0, offset 0, flags [DF], length: 84) 216.239.59.104 > 66.11.175.98: icmp 64: echo reply seq 1 15:46:47.057421 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], length: 84) 66.11.175.98 > 216.239.59.104: icmp 64: echo request seq 2 15:46:47.223310 IP (tos 0x0, ttl 239, id 1, offset 0, flags [DF], length: 84) 216.239.59.104 > 66.11.175.98: icmp 64: echo reply seq 2 What the kernel (2.6.10) objects to: Feb 23 15:46:46 elm kernel: martian source 192.168.9.250 from 216.239.59.104, on dev eth2 Feb 23 15:46:47 elm kernel: martian source 192.168.9.250 from 216.239.59.104, on dev eth2 192.168.9.250 is the old pre-SNAT source address (eth0) of these packets. The kernel is objecting to packets with the wrong source address on eth2; but, they don't have the wrong source address because they were SNATd specifically for eth2 and left and returned with the correct address. If I set the source address at the application level in ping (no SNAT needed on these), things work fine: # ping -I eth2 google.ca PING google.ca (216.239.39.104) from 66.11.175.98 eth2: 56(84) bytes 64 bytes from 216.239.39.104: icmp_seq=1 ttl=243 time=53.2 ms 64 bytes from 216.239.39.104: icmp_seq=2 ttl=243 time=54.7 ms 64 bytes from 216.239.39.104: icmp_seq=3 ttl=243 time=55.1 ms Here's what tcpdump sees for these packets going out/in eth2: 16:05:22.446901 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) 66.11.175.98 > 216.239.39.104: icmp 64: echo request seq 1 16:05:22.500097 IP (tos 0x0, ttl 243, id 0, offset 0, flags [DF], length: 84) 216.239.39.104 > 66.11.175.98: icmp 64: echo reply seq 1 16:05:23.448149 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], length: 84) 66.11.175.98 > 216.239.39.104: icmp 64: echo request seq 2 16:05:23.502901 IP (tos 0x0, ttl 243, id 1, offset 0, flags [DF], length: 84) 216.239.39.104 > 66.11.175.98: icmp 64: echo reply seq 2 These above "working" packets from the above session look no different to tcpdump on eth2 than the non-working packets from the previous session. The packets are leaving with the correct source address for eth2 and are returing correctly. Shouldn't both sets of packets be treated the same way? I think that rp_filter checks are a good thing; but, shouldn't the martian check take place closer to the wire where the packets are coming in? The kernel is apparently checking for martians *after* the corresponding un-SNAT rule for the echo reply changes the incoming destination address from 66.11.175.98 back to 192.168.9.250. I think people use rp_filter to prevent spoofed packets coming in over *the wire*, not to prevent SNAT rules from working. The martian check should be on the packets as received *over the wire* from eth2, not after the un-SNAT rule internally mangles the packet destination. If I'm looking for spoofed packets, I want to check the packets where the danger is - out at the wire where the spoofed packets arrive - not somewhere in the middle of the network stack mangling. I could (must) disable source validation for all packets (rp_filter=0); but, I'd rather have the kernel not complain about packets on eth2 that really and truly did arrive with the correct eth2 address. Am I misunderstanding the intent of rp_filter? Is there a work-around that doesn't involve disabling it entirely on the interface? -- -IAN! Ian! D. Allen Ottawa, Ontario, Canada EMail: idallen@idallen.ca WWW: http://www.idallen.com/ College professor (Linux) via: http://teaching.idallen.com/ Support free and open public digital rights: http://eff.org/ From Info@Quantum-Sci.com Sun Feb 27 07:28:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 07:28:52 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RFSkfb006759 for ; Sun, 27 Feb 2005 07:28:47 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5QLg-00061Z-Ru for netdev@oss.sgi.com; Sun, 27 Feb 2005 15:28:48 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 09:28:44 -0600 User-Agent: KMail/1.7.1 helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502270928.44402.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2083 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev Content-Length: 2175 Lines: 49 After a week of intensive research and full-time study, it's become clear that IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively non-functional. I have a properly working firewall, but it appears there is no stateful filtering nor connection tracking in the IPV6 stack. I send out an echo-request, but have to open icmpv6-129 in order to get the response back. Same with http. We can't open all our incoming ports. There is no IP6_NF_CONNTRACK nor IP6_NF_MATCH_STATE in the kernel. And if this functionality is supposed to be inherent in IPV6, it is not working. The native IPV6 stack seems to come from oss.sgi.com . Subscribing to your mailing list yields: List context changed to 'netdev' by following command. >> appsub netdev Info@Quantum-Sci.com 4221DB53:15AB.1:argqri Subscribed. --- Ecartis v1.0.0 - job execution complete. AH! But wait... there's no indication of what the list's address is. Going to www.oss.sgi.com gives no indication of where the mailing lists are either. So this email is addressed to a guess. OK, so I subscribed to USAGI. It was recommended on that list that I install the USAGI kernel, but I want to only patch the Debian kernel. So I DLed usagi.snap.split-tool-s20050214.tar.bz2 ... however this has no kernel patch within. So I DLed usagi.snap.kit-linux26-s20050214.tar.bz2 ... and no kernel patch here either. Only the kernel and tools. I would have to run a USAGI-specific kernel, in order to have proper IPV6 support. I must stay with the Debian kernel. I can't believe the native kernel's IPV6 is so primitive. I can't believe any kernel developers are actually using IPV6. And I can't believe that anyone is actually using IPV6 with the Debian kernel. The Debian IPV6 mailing list is full of spam, and brought viruses and scams to my door when I subscribed. No one I've asked questions of has mentioned any of this at all, so if there is an answer, it is clearly a secret. So is there something I'm missing? Am I completely fscked-up when I say that it doesn't work in practice, because there is no stateful packet filtering nor connection tracking? Carl Cook From itkes@fat.imec.msu.ru Sun Feb 27 08:00:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 08:00:41 -0800 (PST) Received: from fat.imec.msu.ru (postfix@fat.imec.msu.ru [193.232.114.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RG0Z0H007997 for ; Sun, 27 Feb 2005 08:00:36 -0800 Received: from mx.imec.msu.ru (localhost.localdomain [127.0.0.1]) by fat.imec.msu.ru (Postfix) with ESMTP id BF8B4318 for ; Sun, 27 Feb 2005 19:00:29 +0300 (MSK) Received: from 80.249.146.137 (SquirrelMail authenticated user itkes) by mx.imec.msu.ru with HTTP; Sun, 27 Feb 2005 19:00:29 +0300 (MSK) Message-ID: <1125.80.249.146.137.1109520029.squirrel@mx.imec.msu.ru> Date: Sun, 27 Feb 2005 19:00:29 +0300 (MSK) Subject: A bug in the Kernel? From: itkes@fat.imec.msu.ru To: netdev@oss.sgi.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050227190029_84044" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2084 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itkes@fat.imec.msu.ru Precedence: bulk X-list: netdev Content-Length: 4505 Lines: 83 ------=_20050227190029_84044 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello. I think I have found a bug in the Linux Kernel. Although Netlink is not a reliable protocol, the kernel must do everything to transmit the correct information about networking subsystem state. For example, if an application reuqests the routing table dump, the kernel must send at least all the routes that had not been modified, added or deleted during the dump operation. Let us suppose the application to request the routing tabled dump. I heve found that in some conditions, this application may not receive some unchanged routes, if some other routes was deleted. I have fixed the bug of routing tables dump, but same errors may occure in process of net interfaces dump, routing rules dump etc. The patch to kernel 2.6.11-rc5 is attached. I ask you to include it to the next kernel release. If you will add my code to the kernel, could I try to correct other bugs of this type? I have almost finished correcting the routing rules dump. Alex Itkes (Moscow State University). P.S. After I have finished the patch, I found another bug in the Routing Tables Dump. In function fn_hash_dump_bucket in fib_hash.c there is a construction: if (i; Sun, 27 Feb 2005 08:09:13 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E9E8F33CC2; Mon, 28 Feb 2005 01:10:38 +0900 (JST) Date: Mon, 28 Feb 2005 01:10:38 +0900 (JST) Message-Id: <20050228.011038.129063054.yoshfuji@linux-ipv6.org> To: Info@Quantum-Sci.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Kernel 2.6 IPV6 Busted From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200502270928.44402.Info@Quantum-Sci.com> References: <200502270928.44402.Info@Quantum-Sci.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2085 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: 1920 Lines: 52 In article <200502270928.44402.Info@Quantum-Sci.com> (at Sun, 27 Feb 2005 09:28:44 -0600), Quantum Scientific says: > After a week of intensive research and full-time study, it's become clear that > IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively > non-functional. Sigh... It is defenetely functional for me. > usagi.snap.split-tool-s20050214.tar.bz2 > ... however this has no kernel patch within. > > So I DLed > usagi.snap.kit-linux26-s20050214.tar.bz2 > ... and no kernel patch here either. Only the kernel and tools. I would have > to run a USAGI-specific kernel, in order to have proper IPV6 support. I must > stay with the Debian kernel. I believe you should cry at debian-ipv6 list. And, you can find usagi kernel patch in split directory, and you can even find (unsupported) daily kernel snapshot (diff). > I can't believe the native kernel's IPV6 is so primitive. I can't believe any > kernel developers are actually using IPV6. And I can't believe that anyone > is actually using IPV6 with the Debian kernel. The Debian IPV6 mailing list > is full of spam, and brought viruses and scams to my door when I subscribed. > No one I've asked questions of has mentioned any of this at all, so if there > is an answer, it is clearly a secret. Sigh... Even you can't believe, I actually use IPv6 in my daily life. I use Debian kernel at first, but in most cases, I upgrade it to latest usagi tree ASAP. In this means, I don't usually use Debian IPv6 kernel. (sorry.) > So is there something I'm missing? Am I completely fscked-up when I say that > it doesn't work in practice, because there is no stateful packet filtering > nor connection tracking? FYI, I hope nf_conntrack, which supports both ipv4 and ipv6, will be integrated in 2.6.12 time frame. Note: nf_conntrack framework is designed and written by Kozakai-san. --yoshfuji From kaber@trash.net Sun Feb 27 08:26:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 08:26:43 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RGQbas012894 for ; Sun, 27 Feb 2005 08:26:37 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D5RFc-0005GJ-P6; Sun, 27 Feb 2005 17:26:36 +0100 Message-ID: <4221F4BC.1080409@trash.net> Date: Sun, 27 Feb 2005 17:26:36 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: itkes@fat.imec.msu.ru CC: netdev@oss.sgi.com Subject: Re: A bug in the Kernel? References: <1125.80.249.146.137.1109520029.squirrel@mx.imec.msu.ru> In-Reply-To: <1125.80.249.146.137.1109520029.squirrel@mx.imec.msu.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1220 Lines: 36 itkes@fat.imec.msu.ru wrote: > Let us suppose the application to request the routing tabled dump. I heve > found that in some conditions, this application may not receive some > unchanged routes, if some other routes was deleted. Could you describe this condition in more detail ? In your patch you change the type of "args" to void *, which results in a bigger patch and it shouldn't be done anyway. If you need to store a pointer simply cast it to long. Please send a plain (not gzipped) patch without this change and without the EXTRAVERSION change. > P.S. After I have finished the patch, I found another bug in the Routing > Tables Dump. In function fn_hash_dump_bucket in fib_hash.c there is a > construction: > if (i continue; > ... > i++; > If the first "if" is true in first moment, "i" will never be increased and > some routes will be lost. My patch fixes this bug, too. Good catch, this bug was introduced when switching to hlist_for_each_entry(). - for (i=0; f; i++, f=f->fn_next) { - if (i < s_i) continue; + i = 0; + hlist_for_each_entry(f, node, head, fn_hash) { + struct fib_alias *fa; + + list_for_each_entry(fa, &f->fn_alias, fa_list) { + if (i < s_i) + continue; Regards Patrick From Info@Quantum-Sci.com Sun Feb 27 08:29:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 08:29:08 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RGT5qk013410 for ; Sun, 27 Feb 2005 08:29:05 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5RI3-0000iv-Gj for netdev@oss.sgi.com; Sun, 27 Feb 2005 16:29:07 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 10:29:02 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <20050228.011038.129063054.yoshfuji@linux-ipv6.org> In-Reply-To: <20050228.011038.129063054.yoshfuji@linux-ipv6.org> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200502271029.02532.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1RGT5qk013410 X-archive-position: 2087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev Content-Length: 1363 Lines: 33 On Sunday 27 February 2005 10:10, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > > usagi.snap.split-tool-s20050214.tar.bz2 > > ... however this has no kernel patch within. > > > > So I DLed > > usagi.snap.kit-linux26-s20050214.tar.bz2 > > ... and no kernel patch here either. Only the kernel and tools. I would have > > to run a USAGI-specific kernel, in order to have proper IPV6 support. I must > > stay with the Debian kernel. > > I believe you should cry at debian-ipv6 list. > > And, you can find usagi kernel patch in split directory, and > you can even find (unsupported) daily kernel snapshot (diff). I have 'cried' to the Debian list, and no response. (except viruses) And I have looked at every single file in the Split directory, and there are absolutely no .diff files. .diff files are how patch files are identified in *nix, of course. I thought, maybe I should copy the kernel files into my kernel tree by hand, for building. But this doesn't make sense because the only file under usagi-split/kernel/usagi/net/ipv6 is utils.c . This is not an IPV6 stack, nor ip6tables. I see lots of apps, which likely have the USAGI improvements, but no kernel stack, patch, ipv6filters, etc. And no mention of patching a non-USAGI kernel. Split 20050214 appears to be utilities only. Please show where could I be going wrong? Carl Cook From yoshfuji@linux-ipv6.org Sun Feb 27 09:27:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 09:27:08 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RHR2bY015465 for ; Sun, 27 Feb 2005 09:27:02 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8A0BE33CC2; Mon, 28 Feb 2005 02:28:28 +0900 (JST) Date: Mon, 28 Feb 2005 02:28:28 +0900 (JST) Message-Id: <20050228.022828.120983354.yoshfuji@linux-ipv6.org> To: Info@Quantum-Sci.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Kernel 2.6 IPV6 Busted From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200502271029.02532.Info@Quantum-Sci.com> References: <200502270928.44402.Info@Quantum-Sci.com> <20050228.011038.129063054.yoshfuji@linux-ipv6.org> <200502271029.02532.Info@Quantum-Sci.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2088 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: 953 Lines: 17 In article <200502271029.02532.Info@Quantum-Sci.com> (at Sun, 27 Feb 2005 10:29:02 -0600), Quantum Scientific says: > And I have looked at every single file in the Split directory, and there are > absolutely no .diff files. .diff files are how patch files are identified in > *nix, of course. I thought, maybe I should copy the kernel files into my > kernel tree by hand, for building. But this doesn't make sense because the > only file under usagi-split/kernel/usagi/net/ipv6 is utils.c . This is not > an IPV6 stack, nor ip6tables. I see lots of apps, which likely have the > USAGI improvements, but no kernel stack, patch, ipv6filters, etc. And no > mention of patching a non-USAGI kernel. Split 20050214 appears to be > utilities only. Don't you find diff files?! e.g: ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-linux26-s20050214-2.6.11-rc3.diff.bz2 is patch against linux-2.6.11-rc3. --yoshfuji From andre@tomt.net Sun Feb 27 09:40:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 09:40:13 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RHe9nw016147 for ; Sun, 27 Feb 2005 09:40:09 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id E8DC2884E2; Sun, 27 Feb 2005 18:40:06 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 92F59884CF; Sun, 27 Feb 2005 18:40:04 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id D8DC1229CD; Sun, 27 Feb 2005 18:40:04 +0100 (CET) Message-ID: <422205F7.4080401@tomt.net> Date: Sun, 27 Feb 2005 18:40:07 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quantum Scientific Cc: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> In-Reply-To: <200502270928.44402.Info@Quantum-Sci.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 2089 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 2064 Lines: 43 Quantum Scientific wrote: > After a week of intensive research and full-time study, it's become clear that > IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively > non-functional. > > I have a properly working firewall, but it appears there is no stateful > filtering nor connection tracking in the IPV6 stack. I send out an > echo-request, but have to open icmpv6-129 in order to get the response back. > Same with http. We can't open all our incoming ports. There is no > IP6_NF_CONNTRACK nor IP6_NF_MATCH_STATE in the kernel. And if this > functionality is supposed to be inherent in IPV6, it is not working. Connection tracking (as in stateful firewalling) do not a useful ipv6 stack make.. The stack works fine, at least the stack provided in 2.6 kernels. The 2.4 stack is severely out of date, however, but should "work". Connection tracking is on the way, currently a implementation exists in the netfilter.org patch-o-matic svn. > I must stay with the Debian kernel. Debian ships 2.6.8 with ipv6 enabled in Sarge. Not sure about Woody, but its ought to be rather outdated by now ;-) > I can't believe the native kernel's IPV6 is so primitive. I can't believe any > kernel developers are actually using IPV6. And I can't believe that anyone > is actually using IPV6 with the Debian kernel. The Debian IPV6 mailing list > is full of spam, and brought viruses and scams to my door when I subscribed. > No one I've asked questions of has mentioned any of this at all, so if there > is an answer, it is clearly a secret. > So is there something I'm missing? Am I completely fscked-up when I say that > it doesn't work in practice, because there is no stateful packet filtering > nor connection tracking? You seem to be fixed on the idea that a ipv6 stack has to have stateful firewalling, or else its utter crap, correct? :-) Not all hosts need firewalling at all, or firewalling is provided by routers/firewalls for them. I use ipv6 in production networks, on Linux, without special patches. From Info@Quantum-Sci.com Sun Feb 27 10:09:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 10:09:06 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RI92ic017176 for ; Sun, 27 Feb 2005 10:09:02 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5Sqm-0007kv-0b for netdev@oss.sgi.com; Sun, 27 Feb 2005 18:09:04 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 12:08:52 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <200502271029.02532.Info@Quantum-Sci.com> <20050228.022828.120983354.yoshfuji@linux-ipv6.org> In-Reply-To: <20050228.022828.120983354.yoshfuji@linux-ipv6.org> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200502271208.52936.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1RI92ic017176 X-archive-position: 2090 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev Content-Length: 666 Lines: 18 On Sunday 27 February 2005 11:28, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > Don't you find diff files?! e.g: > ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-linux26-s20050214-2.6.11-rc3.diff.bz2 > is patch against linux-2.6.11-rc3. I see. I was talking about the downloadable split and kit archives, and you were talking about what's on FTP, which I didn't expect to be different. I'm hoping some of my vociferous effort to make this go, will help improve things down the line. IPV6 is extremely difficult to implement at the moment. Here's hoping the USAGI linux-2.6.10-rc3 diff fits in Debian kernel-source-2.6.10-5. Back to work... Carl Cook From jgarzik@pobox.com Sun Feb 27 10:12:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 10:12:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RICTTW017765 for ; Sun, 27 Feb 2005 10:12:30 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5Su4-0008Dg-6e; Sun, 27 Feb 2005 18:12:28 +0000 Message-ID: <42220D7E.3000104@pobox.com> Date: Sun, 27 Feb 2005 13:12:14 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quantum Scientific CC: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> In-Reply-To: <200502270928.44402.Info@Quantum-Sci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2091 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: 716 Lines: 21 Quantum Scientific wrote: > After a week of intensive research and full-time study, it's become clear that > IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively > non-functional. Strange how I use this non-functional support every day. > I have a properly working firewall, but it appears there is no stateful > filtering nor connection tracking in the IPV6 stack. I send out an > So is there something I'm missing? Am I completely fscked-up when I say that > it doesn't work in practice, because there is no stateful packet filtering > nor connection tracking? Yes. IPv6 does not need NAT'ing. Everyone should have a global address. Connection tracking is not needed. Jeff From Info@quantum-sci.com Sun Feb 27 10:20:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 10:20:16 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RIKC2e018372 for ; Sun, 27 Feb 2005 10:20:12 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5T1Y-0001Wr-KF for netdev@oss.sgi.com; Sun, 27 Feb 2005 18:20:13 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 12:20:06 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <422205F7.4080401@tomt.net> In-Reply-To: <422205F7.4080401@tomt.net> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502271220.06560.Info@quantum-sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2092 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev Content-Length: 1634 Lines: 44 On Sunday 27 February 2005 11:40, Andre Tomt wrote: > Connection tracking (as in stateful firewalling) do not a useful ipv6 > stack make.. The stack works fine, at least the stack provided in 2.6 > kernels. ... > You seem to be fixed on the idea that a ipv6 stack has to have stateful > firewalling, or else its utter crap, correct? :-) No, I'll try to say this clearer. The stack works fine in. And out. But for a useful virtual circuit you must have something like connection tracking. Remember what my issue is: - I have a very tight firewall, - I ping6 out, - The firewall blocks the reply back, because the connection is stateless! - Same with http, etc. This means that I have to open for incoming, virtually every port I send outgoing to, or else I do not get any replies. This is what I call non-functional, because one does not open incoming ports, for the most part. Why are you not having this problem? > Connection tracking is on the way, currently a implementation exists in > the netfilter.org patch-o-matic svn. Is this reasonably solid? Does this operate on Layer 3, rather than Layer 2? > Not all hosts need firewalling at all, or firewalling is provided by > routers/firewalls for them. I use ipv6 in production networks, on Linux, > without special patches. Sorry, I disagree. The whole point of IPV6 is ubiquitous addressing. So every single node must have a good firewall. In fact my router is firewalling as well, so my LAN nodes are double-firewalled. It is irresponsible to not firewall all nodes, as they are supposed to be universally available with this paradigm. Carl Cook From jgarzik@pobox.com Sun Feb 27 10:59:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 10:59:56 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RIxqvT019459 for ; Sun, 27 Feb 2005 10:59:52 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5Tdt-00019F-4Y; Sun, 27 Feb 2005 18:59:49 +0000 Message-ID: <42221897.4000704@pobox.com> Date: Sun, 27 Feb 2005 13:59:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quantum Scientific CC: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> <422205F7.4080401@tomt.net> <200502271220.06560.Info@quantum-sci.com> In-Reply-To: <200502271220.06560.Info@quantum-sci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2093 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: 1098 Lines: 37 Quantum Scientific wrote: > On Sunday 27 February 2005 11:40, Andre Tomt wrote: > >>Connection tracking (as in stateful firewalling) do not a useful ipv6 >>stack make.. The stack works fine, at least the stack provided in 2.6 >>kernels. > > ... > >>You seem to be fixed on the idea that a ipv6 stack has to have stateful >>firewalling, or else its utter crap, correct? :-) > > > No, I'll try to say this clearer. > > The stack works fine in. And out. But for a useful virtual circuit you must > have something like connection tracking. > > Remember what my issue is: > - I have a very tight firewall, > - I ping6 out, > - The firewall blocks the reply back, because the connection is stateless! > - Same with http, etc. > > This means that I have to open for incoming, virtually every port I send > outgoing to, or else I do not get any replies. This is what I call > non-functional, because one does not open incoming ports, for the most part. > > Why are you not having this problem? Connection tracking doesn't scale. It's impossible to hash the entire Internet. Jeff From Info@quantum-sci.com Sun Feb 27 11:11:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 11:11:07 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RJB3Ck020190 for ; Sun, 27 Feb 2005 11:11:03 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5Too-0005Yo-JT for netdev@oss.sgi.com; Sun, 27 Feb 2005 19:11:06 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 13:10:59 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <200502271220.06560.Info@quantum-sci.com> <42221897.4000704@pobox.com> In-Reply-To: <42221897.4000704@pobox.com> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502271310.59682.Info@quantum-sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2094 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev Content-Length: 290 Lines: 11 On Sunday 27 February 2005 12:59, Jeff Garzik wrote: > Connection tracking doesn't scale. It's impossible to hash the entire > Internet. I have read this. And I've seen inferences that IPV6 takes care of this problem somehow automatically. But no one seems to know how. Carl Cook From jdmason@us.ibm.com Sun Feb 27 11:28:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 11:29:00 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RJSo15020912 for ; Sun, 27 Feb 2005 11:28:56 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1RJShMN530730 for ; Sun, 27 Feb 2005 14:28:43 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1RJShXo143472 for ; Sun, 27 Feb 2005 12:28:43 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1RJSh1N029386 for ; Sun, 27 Feb 2005 12:28:43 -0700 Received: from sig-9-65-48-170.mts.ibm.com (sig-9-65-48-170.mts.ibm.com [9.65.48.170]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1RJSghG029382; Sun, 27 Feb 2005 12:28:42 -0700 From: Jon Mason Organization: IBM To: Richard Dawe Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Date: Sun, 27 Feb 2005 13:28:41 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <42208D83.80803@phekda.gotadsl.co.uk> In-Reply-To: <42208D83.80803@phekda.gotadsl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502271328.41747.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2095 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 494 Lines: 15 On Saturday 26 February 2005 08:53 am, Richard Dawe wrote: > Hi Francois and Jon! > > Please find attached a patch that adds the hardware statistics ethtool > operations to the r8169 driver. It's against 2.6.11-rc5. I tested it on my amd64 system and it works great. I saw the same error if stats were gathered with the interface was down. As a sanity check, I preformed the same test on e1000 and it does not have this error. Not sure the significance of that. Thanks Richard! Jon From davem@davemloft.net Sun Feb 27 11:34:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 11:34:35 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RJYStT021492 for ; Sun, 27 Feb 2005 11:34:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D5UA1-0001JB-00; Sun, 27 Feb 2005 11:33:01 -0800 Date: Sun, 27 Feb 2005 11:33:01 -0800 From: "David S. Miller" To: Patrick McHardy Cc: itkes@fat.imec.msu.ru, netdev@oss.sgi.com Subject: Re: A bug in the Kernel? Message-Id: <20050227113301.44b49e6b.davem@davemloft.net> In-Reply-To: <4221F4BC.1080409@trash.net> References: <1125.80.249.146.137.1109520029.squirrel@mx.imec.msu.ru> <4221F4BC.1080409@trash.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2096 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 284 Lines: 10 On Sun, 27 Feb 2005 17:26:36 +0100 Patrick McHardy wrote: > Good catch, this bug was introduced when switching to > hlist_for_each_entry(). What a dumb bug. I'll just put a "next:" label before the "i++;" and have the continue instead be a "goto next;". Thanks. From jgarzik@pobox.com Sun Feb 27 11:59:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 11:59:19 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RJxEk3022392 for ; Sun, 27 Feb 2005 11:59:15 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5UZN-0002bj-IW; Sun, 27 Feb 2005 19:59:13 +0000 Message-ID: <42222670.3090002@pobox.com> Date: Sun, 27 Feb 2005 14:58:40 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quantum Scientific CC: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> <200502271220.06560.Info@quantum-sci.com> <42221897.4000704@pobox.com> <200502271310.59682.Info@quantum-sci.com> In-Reply-To: <200502271310.59682.Info@quantum-sci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2097 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: 466 Lines: 21 Quantum Scientific wrote: > On Sunday 27 February 2005 12:59, Jeff Garzik wrote: > >>Connection tracking doesn't scale. It's impossible to hash the entire >>Internet. > > > I have read this. > > And I've seen inferences that IPV6 takes care of this problem somehow > automatically. But no one seems to know how. The solution is to not use connection tracking. You don't want to break the end-to-end connection model that founded the Internet. Jeff From Info@quantum-sci.com Sun Feb 27 12:10:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 12:10:52 -0800 (PST) Received: from xeonone.bizarre-host.com (bizarre-host.com [70.84.110.116] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RKAmOQ023104 for ; Sun, 27 Feb 2005 12:10:48 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D5UkY-0000Jr-QP for netdev@oss.sgi.com; Sun, 27 Feb 2005 20:10:46 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Sun, 27 Feb 2005 14:10:39 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <200502271310.59682.Info@quantum-sci.com> <42222670.3090002@pobox.com> In-Reply-To: <42222670.3090002@pobox.com> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502271410.39611.Info@quantum-sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2098 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev Content-Length: 1258 Lines: 37 Are you not understanding that I need to receive packets back? I am not going to open incoming firewall ports to do this. If you have a way to receive IPV6 response packets back without opening up your firewall, please enlighten us. This is a problem everyone else has too, if they are using the standard kernel 2.6 IPV6 stack. I am skeptical about this assertion that the whole internet needs to be hashed if connection tracking. This does not seem to be true on its face. Only those nodes which are in active virtual circuits would need to be hashed. This is well within most machines' capability. So barring some inherent IPV6 way of doing this, connection tracking is on. Carl Cook On Sunday 27 February 2005 13:58, Jeff Garzik wrote: > Quantum Scientific wrote: > > On Sunday 27 February 2005 12:59, Jeff Garzik wrote: > > > >>Connection tracking doesn't scale. It's impossible to hash the entire > >>Internet. > > > > > > I have read this. > > > > And I've seen inferences that IPV6 takes care of this problem somehow > > automatically. But no one seems to know how. > > The solution is to not use connection tracking. > > You don't want to break the end-to-end connection model that founded the > Internet. > > Jeff From davem@davemloft.net Sun Feb 27 13:36:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 13:36:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RLaiMt028524 for ; Sun, 27 Feb 2005 13:36:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D5W4M-0001py-00; Sun, 27 Feb 2005 13:35:18 -0800 Date: Sun, 27 Feb 2005 13:35:17 -0800 From: "David S. Miller" To: Quantum Scientific Cc: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Message-Id: <20050227133517.578884df.davem@davemloft.net> In-Reply-To: <200502271410.39611.Info@quantum-sci.com> References: <200502270928.44402.Info@Quantum-Sci.com> <200502271310.59682.Info@quantum-sci.com> <42222670.3090002@pobox.com> <200502271410.39611.Info@quantum-sci.com> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2099 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 418 Lines: 11 On Sun, 27 Feb 2005 14:10:39 -0600 Quantum Scientific wrote: > I am skeptical about this assertion that the whole internet needs to be hashed > if connection tracking. Connection tracking and NAT broke entirely the end-to-end host assumption that used to be valid on the internet. There are many very important optimizations we've had to disable by default just in TCP alone because of NAT. From rich@phekda.gotadsl.co.uk Sun Feb 27 14:41:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 14:41:22 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RMfFJZ030470 for ; Sun, 27 Feb 2005 14:41:16 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-115-184.dyn.gotadsl.co.uk [82.133.115.184]) by smtp.nildram.co.uk (Postfix) with ESMTP id 879412BCD75; Sun, 27 Feb 2005 22:41:10 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id D8912381DC; Sun, 27 Feb 2005 22:43:21 +0000 (GMT) Message-ID: <42224CF5.5090601@phekda.gotadsl.co.uk> Date: Sun, 27 Feb 2005 22:43:01 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH]: r8169: Message level support References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> In-Reply-To: <20050226203518.GA14688@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2100 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 5201 Lines: 180 Hello. Thanks for reviewing the patch, Francois and Jeff. I'll send an updated version sometime in the next week. Francois Romieu wrote: > Jeff, can you send a ack/nack if you disagree with the remarks below ? > > Richard Dawe : > [...] > >>There seems to be a mixture of drivers using a bitfield and a level. >>Which is the currently preferred mechanism? > > > They do not offer exactly the same range. I prefer to keep both as the > module option is not that expensive. OK. [snip] > 1 - I am not fond of shouting macro. Everything starts turnings caps. > Any reason to not use "dprintk" ? (dprintk vs. DPRINTK) I prefer macros to be uppercase, to make it obvious that they're macros. But this isn't a strong preference. I'll make it lowercase. > 2 - Imho the driver should not poke its nose into the guts of netif_msg_xxx(). > It defeats its whole purpose. Any objection to not use it explicitely ? No objection at all. In my first patch I did exactly that. But then I used the e100 driver as a model, which sticks its nose into the guts. I'll use the netif_msg_xxx() macros. > 3 - If PFX is included, we'll have a mix of printk and dprintk. My personal > taste would be to not include it in the definition of the macro. I'll go with Jeff here, which is that "PFX should only be used in probe paths". [snip] > It's up to you but I'd rather see: > #define RTL8169_DEF_MSG_ENABLE \ > (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) I'll use that. > [...] > @@ -433,10 +443,10 @@ static void rtl8169_hw_start(struct net_ > static int rtl8169_close(struct net_device *dev); > static void rtl8169_set_rx_mode(struct net_device *dev); > static void rtl8169_tx_timeout(struct net_device *dev); > -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); > +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev); > static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, > void __iomem *); > -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); > +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu); > static void rtl8169_down(struct net_device *dev); > > #ifdef CONFIG_R8169_NAPI > > Separate patch please. OK, will do. [snip] > -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) > +static void rtl8169_link_option(struct net_device *dev, int idx, u8 *autoneg, u16 *speed, u8 *duplex) > { > + struct rtl8169_private *tp = netdev_priv(dev); > struct { > u16 speed; > u8 duplex; > > Why not give a struct rtl8169_private * as argument to this function ? Er, no idea why I didn't. I'll do that. ;) > [...] > >>@@ -871,6 +881,18 @@ static void rtl8169_get_regs(struct net_ >> spin_unlock_irqrestore(&tp->lock, flags); >> } >> >>+static u32 r8169_get_msglevel(struct net_device *dev) >>+{ >>+ struct rtl8169_private *tp = netdev_priv(dev); >>+ return tp->msg_enable; >>+} > > > > Variable declaration and code are always separated by an empty > line in the current driver. Please keep it this way. Will do. >> >> for (p = mac_print; p->msg; p++) { >> if (tp->mac_version == p->version) { >>- dprintk("mac_version == %s (%04d)\n", p->msg, >>- p->version); >>+ if (netif_msg_hw(tp)) >>+ printk(KERN_DEBUG >>+ "mac_version == %s (%04d)\n", > > > No need to add a line: you are allowed to use the whole 80 cols range. I think I did that for consistency with another printk that was split across lines. I'll fix the case above as you'd like. [snip] >>@@ -1169,7 +1200,8 @@ rtl8169_init_board(struct pci_dev *pdev, >> /* dev zeroed in alloc_etherdev */ >> dev = alloc_etherdev(sizeof (*tp)); >> if (dev == NULL) { >>- printk(KERN_ERR PFX "unable to alloc new ethernet\n"); >>+ if (debug & NETIF_MSG_PROBE) >>+ printk(KERN_ERR PFX "unable to alloc new ethernet\n"); >> goto err_out; >> } >> > > > Can you do something like: > > struct { > u32 msg_enable; > } debug; > > This way it will be possible to issue netif_msg_probe(&debug). Yes, good idea! >>@@ -1177,10 +1209,15 @@ rtl8169_init_board(struct pci_dev *pdev, >> SET_NETDEV_DEV(dev, &pdev->dev); >> tp = netdev_priv(dev); >> >>+ tp->msg_enable = debug; >>+ >> /* enable device (incl. PCI PM wakeup and hotplug setup) */ >> rc = pci_enable_device(pdev); >> if (rc) { >>- printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); >>+ if (netif_msg_probe(tp)) >>+ printk(KERN_ERR PFX >>+ "%s: enable failure\n", >>+ pdev->slot_name); > > > Use dprintk ? Original dprintk or the DPRINTK used in my patch? If you mean DPRINTK, then it wouldn't work, because DPRINTK includes dev->name. At this point in the code, dev->name is not defined. Perhaps I could modifying DPRINTK (*) to use dev->name if defined, otherwise fall back on PFX. (*) I'm not ignoring the future renaming of DPRINTK to dprintk. I'm just trying to avoid confusion when talking about this patch. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From rich@phekda.gotadsl.co.uk Sun Feb 27 14:42:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 14:42:27 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RMgMuN030740 for ; Sun, 27 Feb 2005 14:42:23 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-115-184.dyn.gotadsl.co.uk [82.133.115.184]) by smtp.nildram.co.uk (Postfix) with ESMTP id A0BC12BCE3A; Sun, 27 Feb 2005 22:42:18 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id B60B6381DC; Sun, 27 Feb 2005 22:44:30 +0000 (GMT) Message-ID: <42224D44.6080904@phekda.gotadsl.co.uk> Date: Sun, 27 Feb 2005 22:44:20 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Jon Mason , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <20050226182658.GB13230@electric-eye.fr.zoreil.com> In-Reply-To: <20050226182658.GB13230@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2101 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1020 Lines: 42 Hello. Francois Romieu wrote: > Richard Dawe : > [...] > >>@@ -1531,6 +1620,11 @@ static int rtl8169_open(struct net_devic >> if (retval < 0) >> goto err_free_rx; >> >>+ tp->nic_stats = pci_alloc_consistent(pdev, R8169_STATS_BYTES, >>+ &tp->nic_stats_addr); >>+ if (!tp->nic_stats) >>+ goto err_free_nic_stats; >>+ >> INIT_WORK(&tp->task, NULL, dev); >> >> rtl8169_hw_start(dev); >>@@ -1541,6 +1635,10 @@ static int rtl8169_open(struct net_devic >> out: >> return retval; >> >>+err_free_nic_stats: >>+ pci_free_consistent(pdev, R8169_STATS_BYTES, tp->nic_stats, >>+ tp->nic_stats_addr); >>+ > > > You don't want to free it it was not allocated. Please undo the previous > step (init_ring probably) and: [snip] Oops, thanks for spotting that. I'll fix it for the next revision of the patch. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From rich@phekda.gotadsl.co.uk Sun Feb 27 14:45:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 14:45:07 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RMj3XN031502 for ; Sun, 27 Feb 2005 14:45:03 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-115-184.dyn.gotadsl.co.uk [82.133.115.184]) by smtp.nildram.co.uk (Postfix) with ESMTP id B22AE2BB5A9; Sun, 27 Feb 2005 22:44:58 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 538E9381DC; Sun, 27 Feb 2005 22:47:10 +0000 (GMT) Message-ID: <42224DDA.1010907@phekda.gotadsl.co.uk> Date: Sun, 27 Feb 2005 22:46:50 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Jeff Garzik Cc: Francois Romieu , Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <42209C4E.6000800@pobox.com> In-Reply-To: <42209C4E.6000800@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2102 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1271 Lines: 46 Hello. Jeff Garzik wrote: > Richard Dawe wrote: [snip] >> +static const char rtl8169_gstrings_stats[][ETH_GSTRING_LEN] = { >> + "tx_ok", "rx_ok", "tx_err", "rx_err", >> + "rx_fifo", "frame_align", "tx_ok_1col", "tx_ok_mcol", >> + "rx_ok_phys", "rx_ok_bcast", "rx_ok_mcast", "tx_abort", >> + "tx_underrun", >> +}; > > > Don't needlessly reformat copied code. It's one-string-per-line > intentionally, for ease of maintenance and ease of adding new strings. OK, I'll fix that. > Also, I don't see why you renamed this from ethtool_stats_keys[]. I didn't copy it directly. I started off with something that looked like the ethtool stats code from the e100 driver. Then I noticed that 8139cp did the right thing for r8169. I'll rename it. >> + /* begin NIC statistics dump */ >> + RTL_W32(StatsAddrHigh, tp->nic_stats_addr >> 32); >> + RTL_W32(StatsAddrLow, (tp->nic_stats_addr & 0xffffffff) | >> DumpStats); >> + RTL_R32(StatsAddrLow); > > > This last RTL_R32() can be removed [from 8139cp too], because a flush > immediately follows anyway: [snip] OK, will do. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From rich@phekda.gotadsl.co.uk Sun Feb 27 14:51:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 14:52:10 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RMptYI032085 for ; Sun, 27 Feb 2005 14:51:56 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [84.12.62.215]) by smtp.nildram.co.uk (Postfix) with ESMTP id 5EE9F2BC967; Sun, 27 Feb 2005 22:51:51 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id DCE82381DC; Sun, 27 Feb 2005 22:54:02 +0000 (GMT) Message-ID: <42224F76.9000602@phekda.gotadsl.co.uk> Date: Sun, 27 Feb 2005 22:53:42 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Jeff Garzik , Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> <4220B9C6.1010106@pobox.com> <20050226181213.GA13230@electric-eye.fr.zoreil.com> In-Reply-To: <20050226181213.GA13230@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2103 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 769 Lines: 27 Hello. Thanks for reviewing, Francois, Jon & Jeff! Francois Romieu wrote: [snip] > Btw I'd simply remove the 'work' variable and schedule in an interruptible > way until the dump is done. OK, that will take me a bit longer to code. ;) > BUG() is a bit exagerated imho. It seems like a pretty good way of avoiding a buffer overrun to me. E.g.: you copy an extra statistic in rtl8169_get_ethtool_stats(), but forget to update the stats length. Is it not better to crash early, than encounter random behaviour later? I can put an #ifdef RTL8169_DEBUG / #endif around it, if you'd be happier. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From jgarzik@pobox.com Sun Feb 27 15:00:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 15:00:23 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RN0HER000362 for ; Sun, 27 Feb 2005 15:00:18 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5XOV-0006Lq-7q; Sun, 27 Feb 2005 23:00:12 +0000 Message-ID: <422250E1.6000307@pobox.com> Date: Sun, 27 Feb 2005 17:59:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Dawe CC: Francois Romieu , Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <200502261132.29261.jdmason@us.ibm.com> <4220B9C6.1010106@pobox.com> <20050226181213.GA13230@electric-eye.fr.zoreil.com> <42224F76.9000602@phekda.gotadsl.co.uk> In-Reply-To: <42224F76.9000602@phekda.gotadsl.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2104 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: 466 Lines: 16 Richard Dawe wrote: >> BUG() is a bit exagerated imho. > > > It seems like a pretty good way of avoiding a buffer overrun to me. > E.g.: you copy an extra statistic in rtl8169_get_ethtool_stats(), but > forget to update the stats length. Is it not better to crash early, than > encounter random behaviour later? Yeah, that's why the BUG() is present in 8139cp: force an oops rather than continue corrupting memory, if the programmer made an error. Jeff From romieu@fr.zoreil.com Sun Feb 27 15:56:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 15:56:10 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1RNu3qU001735 for ; Sun, 27 Feb 2005 15:56:04 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1RNqGsZ028166; Mon, 28 Feb 2005 00:52:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1RNqAU9028165; Mon, 28 Feb 2005 00:52:10 +0100 Date: Mon, 28 Feb 2005 00:52:10 +0100 From: Francois Romieu To: Richard Dawe Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH]: r8169: Message level support Message-ID: <20050227235210.GA27271@electric-eye.fr.zoreil.com> References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> <42224CF5.5090601@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42224CF5.5090601@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2105 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: 996 Lines: 37 Richard Dawe : [...] > >3 - If PFX is included, we'll have a mix of printk and dprintk. My personal > > taste would be to not include it in the definition of the macro. > > I'll go with Jeff here, which is that "PFX should only be used in probe > paths". Fine. [...] > I think I did that for consistency with another printk that was split > across lines. They were split when they could not fit on a single line. OTOH I did not hunt them when they were already there. [...] > >Use dprintk ? > > Original dprintk or the DPRINTK used in my patch? If you mean DPRINTK, Your. > then it wouldn't work, because DPRINTK includes dev->name. At this point > in the code, dev->name is not defined. > > Perhaps I could modifying DPRINTK (*) to use dev->name if defined, > otherwise fall back on PFX. I would put the smallest amount of things behind dprintk() so it can be used anywhere (for consistency): no PFX, no dev->name. Thanks for your work. -- Ueimor From kaigai@ak.jp.nec.com Sun Feb 27 17:58:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 17:58:27 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S1wJMq007388 for ; Sun, 27 Feb 2005 17:58:20 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j1S1wF724479; Mon, 28 Feb 2005 10:58:15 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j1S1wFE06798; Mon, 28 Feb 2005 10:58:15 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id j1S1wF904209; Mon, 28 Feb 2005 10:58:15 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j1S1m8IK026007; Mon, 28 Feb 2005 10:48:09 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 8BFB630806; Mon, 28 Feb 2005 10:58:13 +0900 (JST) Message-ID: <42227AEA.6050002@ak.jp.nec.com> Date: Mon, 28 Feb 2005 10:59:06 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Marcelo Tosatti Cc: Andrew Morton , davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [Lse-tech] Re: A common layer for Accounting packages References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> In-Reply-To: <20050227140355.GA23055@logos.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2106 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: netdev Content-Length: 3499 Lines: 90 Hello, Marcelo Tosatti wrote: > Yep, the netlink people should be able to help - they known what would be > required for not sending messages in case there is no listener registered. > > Maybe its already possible? I have never used netlink myself. If we notify the fork/exec/exit-events to user-space directly as you said, I don't think some hackings on netlink is necessary. For example, such packets is sent only when /proc/sys/.../process_grouping is set, and user-side daemon set this value, and unset when daemon will exit. It's not necessary to take too seriously. >>And, why can't netlink packets send always? >>If there are fork/exec/exit hooks, and they call CSA or other >>process-grouping modules, >>then those modules will decide whether packets for interaction with the >>daemon should be >>sent or not. > > > The netlink data will be sent to userspace at fork/exec/exit hooks - one wants > to avoid that if there are no listeners, so setups which dont want to run the > accounting daemon dont pay the cost of building and sending the information > through netlink. > > Thats what Andrew asked for if I understand correctly. Does it mean "netlink packets shouled be sent to userspace unconditionally." ? I have advocated steadfastly that fork/exec/exit hooks is necessary to support process-grouping and to account per process-grouping. It intend to be decided whether packets should be sent or not by hooked functions, in my understanding. Is it also one of the implementations whether using netlink-socket or not ? >>In most considerable case, CSA's kernel-loadable-module using such hooks >>will not be loaded >>when no accounting daemon is running. Adversely, this module must be loaded >>when accounting >>daemon needs CSA's netlink packets. >>Thus, it is only necessary to refer flag valiable and to execute >>conditional-jump >>when no-accounting daemon is running. > > > That would be one hack, although it is uglier than the pure netlink > selection. No, I can't agree this opinion. It means netlink-packets will be sent unconditionally when fork/exec/exit occur. Nobady can decide which packet is sent user-space, I think. In addition, the definition of process grouping is lightweight in many cases. For example, CpuSet can define own process-group by one increment-operation. I think it's not impossible to implement it in userspace, but it's not reasonable. An implementation as a kernel loadable module is reasonable and enough tiny. >>In my estimation, we must pay additional cost for an increment-operation, >>an decrement-op, >>an comparison-op and an conditional jump-op. It's enough lightweight, I >>think. >> >>For example: >>If CSA's module isn't loaded, 'privates_for_grouping' will be empty. >> >>inline int on_fork_hook(task_struct *parent, task_struct *newtask){ >> rcu_read_lock(); >> if( !list_empty(&parent->privates_for_grouping) ){ >> ....; >> } >> rcu_read_unlock(); >>} > > > Andrew has been talking about sending data over netlink to implement the > accounting at userspace, so this piece of code is out of the game, no? Indeed, I'm not opposed to implement the accounting in userspace and using netlink-socket for kernel-daemon communication. But definition of process-grouping based on any grouping policy should be done in kernel space at reasonability viewpoint. Thanks. -- Linux Promotion Center, NEC KaiGai Kohei From jdmason@us.ibm.com Sun Feb 27 18:31:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 18:31:35 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S2VLKl008405 for ; Sun, 27 Feb 2005 18:31:27 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1S2VELg408324 for ; Sun, 27 Feb 2005 21:31:14 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1S2VE9k120308 for ; Sun, 27 Feb 2005 19:31:14 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1S2VD28008489 for ; Sun, 27 Feb 2005 19:31:14 -0700 Received: from sig-9-65-48-170.mts.ibm.com (sig-9-65-48-170.mts.ibm.com [9.65.48.170]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1S2VD3A008482; Sun, 27 Feb 2005 19:31:13 -0700 From: Jon Mason Organization: IBM To: Richard Dawe Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool Date: Sun, 27 Feb 2005 20:31:12 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <42208D83.80803@phekda.gotadsl.co.uk> <20050226181213.GA13230@electric-eye.fr.zoreil.com> <42224F76.9000602@phekda.gotadsl.co.uk> In-Reply-To: <42224F76.9000602@phekda.gotadsl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502272031.12291.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2107 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 735 Lines: 21 I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. --- drivers/net/r8169.c 2005-02-27 20:27:48.000000000 -0600 +++ drivers/net/r8169.c.new 2005-02-27 20:29:29.000000000 -0600 @@ -929,8 +929,13 @@ static void rtl8169_get_ethtool_stats(st cpu_relax(); } - if (RTL_R32(StatsAddrLow) & DumpStats) + if (RTL_R32(StatsAddrLow) & DumpStats) { + if (!netif_running(netdev)) { + for (i = 0; i < 14; i++) + data[i] = 0; + } return; /* no stats - took too long */ + } i = 0; data[i++] = le64_to_cpu(tp->nic_stats->tx_ok); From tgraf@suug.ch Sun Feb 27 18:31:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 18:32:02 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S2Vv8d008550 for ; Sun, 27 Feb 2005 18:31:57 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id A97DD87; Mon, 28 Feb 2005 03:31:28 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id F01F11C0EA; Mon, 28 Feb 2005 03:32:06 +0100 (CET) Date: Mon, 28 Feb 2005 03:32:06 +0100 From: Thomas Graf To: Kaigai Kohei Cc: Marcelo Tosatti , Andrew Morton , davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228023206.GN31837@postel.suug.ch> References: <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42227AEA.6050002@ak.jp.nec.com> X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2108 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1107 Lines: 22 First of all, I'm not aware of the whole discussion, ignore this if it has been brought to attention already. > > Yep, the netlink people should be able to help - they known what would be > > required for not sending messages in case there is no listener registered. > > > > Maybe its already possible? I have never used netlink myself. The easiest way is to use netlink_broadcast() and have userspace register to a netlink multicast group (set .nl_groups before connecting the socket). The netlink message will be sent to only those netlink sockets assigned to the group, no message will be send out if no userspace listeners has registered. Did you have a look at the syscall enter/exit audit netlink hooks before trying to invent your own thing? I can also give you some code if you want, I use it to track the path of skbs in the net stack. It puts events into a preallocated ring buffer and a separate kernel thread broadcasts them over netlink. The events can be enqueued in any context at the cost of a possible ring buffer overrun resulting in loss of events. It's just a debugging hack though. From jgarzik@pobox.com Sun Feb 27 18:59:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 18:59:22 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S2xChL010056 for ; Sun, 27 Feb 2005 18:59:13 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5b7m-00046d-Nd; Mon, 28 Feb 2005 02:59:10 +0000 Message-ID: <422288EC.9010502@pobox.com> Date: Sun, 27 Feb 2005 21:58:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: Richard Dawe , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <20050226181213.GA13230@electric-eye.fr.zoreil.com> <42224F76.9000602@phekda.gotadsl.co.uk> <200502272031.12291.jdmason@us.ibm.com> In-Reply-To: <200502272031.12291.jdmason@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2109 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: 247 Lines: 12 Jon Mason wrote: > I think I've found a (very hackish) way around the bad stats error. > > Tested on amd64, and "solves" the problem. Seems to me, we should instead find a way to avoid calling the stats function if !netif_running() Jeff From d.willmann@tu-bs.de Sun Feb 27 19:00:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 19:00:32 -0800 (PST) Received: from thebe.orbit.homelinux.net (c120.apm.etc.tu-bs.de [134.169.174.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S30Phe010441 for ; Sun, 27 Feb 2005 19:00:26 -0800 Received: from elara.orbit.homelinux.net (unknown [10.1.5.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thebe.orbit.homelinux.net (Postfix) with ESMTP id 28BCE8F2CC; Mon, 28 Feb 2005 04:00:58 +0100 (CET) Date: Mon, 28 Feb 2005 03:59:00 +0100 From: Daniel Willmann To: netdev@oss.sgi.com Cc: jluebbe@lasnet.de, davem@redhat.com Subject: tg3 kernel oops when setting flow control while interface is down (2.6.10) Message-ID: <20050228035900.416f633c@elara.orbit.homelinux.net> X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Signature_Mon__28_Feb_2005_03_59_00_+0100_jjta_L.DSeb85H7p; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: d.willmann@tu-bs.de Precedence: bulk X-list: netdev Content-Length: 4295 Lines: 108 --Signature_Mon__28_Feb_2005_03_59_00_+0100_jjta_L.DSeb85H7p Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear netdevs, a colleague and I discovered a bug in the Tigon3 driver. tg3_set_pauseparams should check if the interface is down. Right now it doesn't and ends up in tg3_free_rings where it assumes that tp->rx_std_buffers[i] does point to a sane address. This is not the case and "if (rxp->skb =3D=3D NULL)" breaks. (drivers/net/tg3.c line 3299). Steps to reproduce: * ip link set eth0 down * ethtool -A eth0 autoneg off We have added the check from tg3_set_settings to tg3_set_pauseparam to return -EAGAIN when the interface is down which works for us. ethtool then returns "Resource temporarily unavailable" if you try to set flowcontrol with -A. The patch and the kernel oops follows. Sincerely, Jan Luebbe and Daniel Willmann --- drivers/net/tg3.c.old 2005-02-27 23:26:48.000000000 +0100 +++ drivers/net/tg3.c 2005-02-28 02:01:11.000000000 +0100 @@ -6155,6 +6155,10 @@ { struct tg3 *tp =3D netdev_priv(dev); =20 + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || + tp->link_config.phy_is_low_power) + return -EAGAIN; + tg3_netif_stop(tp); spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); -------- Feb 27 23:55:24 hiro kernel: Unable to handle kernel NULL pointer dereferen= ce at virtual address 00000000 Feb 27 23:55:24 hiro kernel: printing eip: Feb 27 23:55:24 hiro kernel: c0325114 Feb 27 23:55:24 hiro kernel: *pde =3D 36c10001 Feb 27 23:55:24 hiro kernel: *pte =3D 00000000 Feb 27 23:55:24 hiro kernel: Oops: 0000 [#1] Feb 27 23:55:24 hiro kernel: PREEMPT SMP=20 Feb 27 23:55:24 hiro kernel: Modules linked in: 8021q piix hw_random shpchp= pci_hotplug evdev ide_cd ide_core cdrom unix Feb 27 23:55:24 hiro kernel: CPU: 0 Feb 27 23:55:24 hiro kernel: EIP: 0060:[tg3_free_rings+100/704] Not t= ainted VLI Feb 27 23:55:24 hiro kernel: EFLAGS: 00010082 (2.6.10-hiro)=20 Feb 27 23:55:24 hiro kernel: EIP is at tg3_free_rings+0x64/0x2c0 Feb 27 23:55:24 hiro kernel: eax: 00000021 ebx: 00000000 ecx: c04cc890 = edx: 00000092 Feb 27 23:55:24 hiro kernel: esi: 00000000 edi: 00000000 ebp: f6d9fef0 = esp: f6d9fe30 Feb 27 23:55:24 hiro kernel: ds: 007b es: 007b ss: 0068 Feb 27 23:55:24 hiro kernel: Process ethtool (pid: 3601, threadinfo=3Df6d9e= 000 task=3Df71b1020) Feb 27 23:55:24 hiro kernel: Stack: c0497f00 00000000 00000000 f7e59220 000= 00000 f7e59220 f7e59220 f6d9fef0=20 Feb 27 23:55:24 hiro kernel: c0325393 f7e59220 f7e59220 f6d9fe80 000= 00000 f7e59220 00000000 f7e59220=20 Feb 27 23:55:24 hiro kernel: f7e59220 f6d9fef0 c0327314 f7e59220 f7e= 59220 00000000 c0498700 f6d9feb0=20 Feb 27 23:55:24 hiro kernel: Call Trace: Feb 27 23:55:24 hiro kernel: [tg3_init_rings+35/368] tg3_init_rings+0x23/0= x170 Feb 27 23:55:24 hiro kernel: [tg3_reset_hw+260/5360] tg3_reset_hw+0x104/0x= 14f0 Feb 27 23:55:24 hiro kernel: [tg3_init_hw+138/192] tg3_init_hw+0x8a/0xc0 Feb 27 23:55:24 hiro kernel: [tg3_set_pauseparam+267/464] tg3_set_pausepar= am+0x10b/0x1d0 Feb 27 23:55:24 hiro kernel: [ethtool_set_pauseparam+81/112] ethtool_set_p= auseparam+0x51/0x70 Feb 27 23:55:24 hiro kernel: [dev_ethtool+511/800] dev_ethtool+0x1ff/0x320 Feb 27 23:55:24 hiro kernel: [dev_ioctl+308/624] dev_ioctl+0x134/0x270 Feb 27 23:55:24 hiro kernel: [inet_ioctl+156/176] inet_ioctl+0x9c/0xb0 Feb 27 23:55:24 hiro kernel: [sock_ioctl+201/592] sock_ioctl+0xc9/0x250 Feb 27 23:55:24 hiro kernel: [sys_ioctl+202/560] sys_ioctl+0xca/0x230 Feb 27 23:55:24 hiro kernel: [syscall_call+7/11] syscall_call+0x7/0xb Feb 27 23:55:24 hiro kernel: Code: c0 8d 04 b8 89 44 24 08 e8 3a 8a df ff 8= b 4c 24 24 8b 41 60 89 7c 24 04 c7 04 24 00 7f 49 c0 8d 34 b8 89 74 24 08 e= 8 1c 8a df ff <8b> 0e 85 c9 0f 85 c4 01 00 00 47 81 ff ff 01 00 00 7e a9 31= ff=20 Feb 27 23:55:24 hiro kernel: <6>note: ethtool[3601] exited with preempt_co= unt 2 --Signature_Mon__28_Feb_2005_03_59_00_+0100_jjta_L.DSeb85H7p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCIoj3Z2fhlIqbZ1gRAj8mAKCu1gYpAvb6dLflG4ZWKPCCG5LCeACfVMiL vTRdciQerViGrmumxMCwhz4= =Kcuz -----END PGP SIGNATURE----- --Signature_Mon__28_Feb_2005_03_59_00_+0100_jjta_L.DSeb85H7p-- From greearb@candelatech.com Sun Feb 27 20:16:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 20:16:45 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S4GX1J012893 for ; Sun, 27 Feb 2005 20:16:33 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1S4cYLH011759; Sun, 27 Feb 2005 20:38:34 -0800 Message-ID: <42229B16.6000006@candelatech.com> Date: Sun, 27 Feb 2005 20:16:22 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Jon Mason , Richard Dawe , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <20050226181213.GA13230@electric-eye.fr.zoreil.com> <42224F76.9000602@phekda.gotadsl.co.uk> <200502272031.12291.jdmason@us.ibm.com> <422288EC.9010502@pobox.com> In-Reply-To: <422288EC.9010502@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2111 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: 452 Lines: 18 Jeff Garzik wrote: > Jon Mason wrote: > >> I think I've found a (very hackish) way around the bad stats error. >> Tested on amd64, and "solves" the problem. > > > Seems to me, we should instead find a way to avoid calling the stats > function if !netif_running() Are the stats valid in the hardware if you start it, stop it, and then read them? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Sun Feb 27 20:22:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 20:22:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S4M2Hv016861 for ; Sun, 27 Feb 2005 20:22:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D5cOB-0003gb-00; Sun, 27 Feb 2005 20:20:11 -0800 Date: Sun, 27 Feb 2005 20:20:11 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mostrows@speakeasy.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-Id: <20050227202011.5ccefb22.davem@davemloft.net> In-Reply-To: <20050224155906.73890361@dxpl.pdx.osdl.net> References: <20050224155906.73890361@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 523 Lines: 12 On Thu, 24 Feb 2005 15:59:06 -0800 Stephen Hemminger wrote: > Someone reported a problem with skge hardware receive checksumming and PPPOE > but it looks like a generic problem. Since PPPOE adds additional header > bytes the hardware computed checksum will be wrong. > > Not sure if this is correct, but shouldn't pppoe be doing the following: Changing or expanding the link level headers should only mess up the hw checksum if you are using CHECKSUM_HW, is that what your skge driver is using? From johnpol@2ka.mipt.ru Sun Feb 27 21:11:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 21:11:49 -0800 (PST) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S5BhNF018309 for ; Sun, 27 Feb 2005 21:11:44 -0800 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j1S5BCjB022156; Mon, 28 Feb 2005 08:11:12 +0300 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Kaigai Kohei Cc: Marcelo Tosatti , Andrew Morton , davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <42227AEA.6050002@ak.jp.nec.com> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pCaTatLiGl3pT+YdyW8k" Organization: MIPT Date: Mon, 28 Feb 2005 08:17:31 +0300 Message-Id: <1109567851.28266.5.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 15:09:45 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Mon, 28 Feb 2005 08:11:14 +0300 (MSK) X-archive-position: 2113 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1480 Lines: 51 --=-pCaTatLiGl3pT+YdyW8k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-28 at 10:59 +0900, Kaigai Kohei wrote: > Hello, >=20 > Marcelo Tosatti wrote: > > Yep, the netlink people should be able to help - they known what would= be > > required for not sending messages in case there is no listener registe= red. > > > > Maybe its already possible? I have never used netlink myself. >=20 > If we notify the fork/exec/exit-events to user-space directly as you said= , > I don't think some hackings on netlink is necessary. > For example, such packets is sent only when /proc/sys/.../process_groupin= g is set, > and user-side daemon set this value, and unset when daemon will exit. > It's not necessary to take too seriously. Kernel accounting already was discussed in lkml week ago - I'm quite=20 sure Guillaume Thouvenin created exactly that. His module creates do_fork() hook and broadcasts various process' states over netlink. Discussion at http://lkml.org/lkml/2005/2/17/87 --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-pCaTatLiGl3pT+YdyW8k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCIqlrIKTPhE+8wY0RAthtAJ0RD3Cp+M7g8KRNKmsk3aDKkssYwgCfaXXF hDb9HN70L6Uio6XFUIDg+3Y= =ZWTO -----END PGP SIGNATURE----- --=-pCaTatLiGl3pT+YdyW8k-- From greearb@candelatech.com Sun Feb 27 21:15:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 21:15:36 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S5FVUS018829 for ; Sun, 27 Feb 2005 21:15:31 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1S5bbLH012443 for ; Sun, 27 Feb 2005 21:37:37 -0800 Message-ID: <4222A8F2.6080004@candelatech.com> Date: Sun, 27 Feb 2005 21:15:30 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: Interconnect virtual device? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2114 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: 766 Lines: 25 Hello! I am considering writing a kernel module to provide a very simple virtual interface. This interface would be attached to another interface, and would not be directly associated with hardware. It can have IP addresses & routing tables, and in almost every way appear to be a regular ethernet interface. The idea is that when you tx on this virtual interface, it will cause a packet to be received on another interface. And, when a packet is received on the interface, it will tx on the other interface. I believe I can use this to create some interesting effects with routing and bridging on a limitted number of physical interfaces. Comments? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From rddunlap@osdl.org Sun Feb 27 22:25:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 22:25:46 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S6PeiQ020591 for ; Sun, 27 Feb 2005 22:25:40 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1S6PXqi013237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 27 Feb 2005 22:25:34 -0800 Received: from midway.verizon.net (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1S6PWJw008032; Sun, 27 Feb 2005 22:25:32 -0800 Date: Sun, 27 Feb 2005 22:13:11 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, perex@suse.cz, torvalds Subject: [PATCH] hp100: fix section references Message-Id: <20050227221311.4a163e80.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2115 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: 1167 Lines: 36 hp100: references __init code that should be marked as __devinit; Error: ./drivers/net/hp100.o .text refers to 0000000000000f7f R_X86_64_PC32 .init.text+0x00000000000000b8 Signed-off-by: Randy Dunlap diffstat:= drivers/net/hp100.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff -Naurp ./drivers/net/hp100.c~hp100_sections ./drivers/net/hp100.c --- ./drivers/net/hp100.c~hp100_sections 2005-02-27 12:54:05.731052192 -0800 +++ ./drivers/net/hp100.c 2005-02-27 22:07:52.561806128 -0800 @@ -306,7 +306,7 @@ static void wait(void) * Read board id and convert to string. * Effectively same code as decode_eisa_sig */ -static __init const char *hp100_read_id(int ioaddr) +static __devinit const char *hp100_read_id(int ioaddr) { int i; static char str[HP100_SIG_LEN]; @@ -429,8 +429,8 @@ struct net_device * __init hp100_probe(i } #endif -static int __init hp100_probe1(struct net_device *dev, int ioaddr, - u_char bus, struct pci_dev *pci_dev) +static int __devinit hp100_probe1(struct net_device *dev, int ioaddr, + u_char bus, struct pci_dev *pci_dev) { int i; int err = -ENODEV; --- From rddunlap@osdl.org Sun Feb 27 22:25:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 22:25:47 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S6PeVU020590 for ; Sun, 27 Feb 2005 22:25:40 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1S6PYqi013240 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 27 Feb 2005 22:25:34 -0800 Received: from midway.verizon.net (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1S6PXQ5008035; Sun, 27 Feb 2005 22:25:33 -0800 Date: Sun, 27 Feb 2005 22:14:25 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com, jgarzik Cc: jes@wildopensource.com, torvalds Subject: [PATCH] rrunner: fix section references Message-Id: <20050227221425.38a12015.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2116 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: 948 Lines: 27 rrunner: references __initdata in a __devinit function; data should be __devinitdata; Error: ./drivers/net/rrunner.o .text refers to 00000000000002b2 R_X86_64_32S .init.data Signed-off-by: Randy Dunlap diffstat:= drivers/net/rrunner.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/net/rrunner.c~rrunner_sections ./drivers/net/rrunner.c --- ./drivers/net/rrunner.c~rrunner_sections 2004-12-24 13:34:26.000000000 -0800 +++ ./drivers/net/rrunner.c 2005-02-27 22:14:12.303076680 -0800 @@ -62,7 +62,7 @@ MODULE_AUTHOR("Jes Sorensen ; Sun, 27 Feb 2005 23:20:41 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 3D4E319D911; Mon, 28 Feb 2005 08:20:39 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19269-05; Mon, 28 Feb 2005 08:20:36 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id A4A1519D90F; Mon, 28 Feb 2005 08:20:35 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005022808293537:88 ; Mon, 28 Feb 2005 08:29:35 +0100 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Guillaume Thouvenin To: Kaigai Kohei Cc: Marcelo Tosatti , Andrew Morton , davem@redhat.com, jlan@sgi.com, LSE-Tech , lkml , netdev@oss.sgi.com, elsa-devel In-Reply-To: <42227AEA.6050002@ak.jp.nec.com> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> Date: Mon, 28 Feb 2005 08:20:36 +0100 Message-Id: <1109575236.8549.14.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 28/02/2005 08:29:35, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 28/02/2005 08:29:38, Serialize complete at 28/02/2005 08:29:38 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev Content-Length: 1802 Lines: 50 On Mon, 2005-02-28 at 10:59 +0900, Kaigai Kohei wrote: > Marcelo Tosatti wrote: > > Yep, the netlink people should be able to help - they known what would be > > required for not sending messages in case there is no listener registered. > > > > Maybe its already possible? I have never used netlink myself. > > If we notify the fork/exec/exit-events to user-space directly as you said, > I don't think some hackings on netlink is necessary. > For example, such packets is sent only when /proc/sys/.../process_grouping is set, > and user-side daemon set this value, and unset when daemon will exit. > It's not necessary to take too seriously. I wrote a new fork connector patch with a callback to enable/disable messages in case there is or isn't listener. I will post it this week. Basically there is a global variable that is manipulated with a connector callback so a user space daemon can manipulate the variable. In the fork_connector() function you have: static inline void fork_connector(pid_t parent, pid_t child) { static DEFINE_SPINLOCK(cn_fork_lock); static __u32 seq; /* used to test if message is lost */ if (cn_fork_enable) { [...] cn_netlink_send(msg, CN_IDX_FORK); } } and in the cn_fork module (drivers/connector/cn_fork.c) the callback is defined as: static void cn_fork_callback(void *data) { if (cn_already_initialized) cn_fork_enable = cn_fork_enable ? 0 : 1; } Ok the protocol is maybe too "basic" but with this mechanism the user space application that uses the fork connector can start and stop the send of messages. This implementation needs somme improvements because currently, if two application are using the fork connector one can enable it and the other don't know if it is enable or not, but the idea is here I think. Regards, Guillaume From akpm@osdl.org Sun Feb 27 23:40:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 23:41:04 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S7evMe023527 for ; Sun, 27 Feb 2005 23:40:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1S7e4qi017957 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 27 Feb 2005 23:40:05 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j1S7dxOR010249; Sun, 27 Feb 2005 23:40:00 -0800 Date: Sun, 27 Feb 2005 23:39:43 -0800 From: Andrew Morton To: Guillaume Thouvenin Cc: kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-Id: <20050227233943.6cb89226.akpm@osdl.org> In-Reply-To: <1109575236.8549.14.camel@frecb000711.frec.bull.fr> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> 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 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2118 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: 988 Lines: 20 Guillaume Thouvenin wrote: > > Ok the protocol is maybe too "basic" but with this mechanism the user > space application that uses the fork connector can start and stop the > send of messages. This implementation needs somme improvements because > currently, if two application are using the fork connector one can > enable it and the other don't know if it is enable or not, but the idea > is here I think. Yes. But this problem can be solved in userspace, with a little library function and a bit of locking. IOW: use the library to enable/disable the fork connector rather than directly doing syscalls. It has the problem that if a client of that library crashes, the counter gets out of whack, but really, it's not all _that_ important, and to handle this properly in-kernel each client would need an open fd against some object so we can do the close-on-exit thing properly. You'd need to create a separate netlink socket for the purpose. From jes@trained-monkey.org Sun Feb 27 23:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 23:51:10 -0800 (PST) Received: from jaguar.mkp.net (vanessarodrigues.com [192.139.46.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S7p3Ft025667 for ; Sun, 27 Feb 2005 23:51:04 -0800 Received: by jaguar.mkp.net (Postfix, from userid 1655) id 7AAC8286D1A; Mon, 28 Feb 2005 02:51:01 -0500 (EST) To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, jgarzik , torvalds Subject: Re: [PATCH] rrunner: fix section references References: <20050227221425.38a12015.rddunlap@osdl.org> From: Jes Sorensen Date: 28 Feb 2005 02:51:01 -0500 In-Reply-To: <20050227221425.38a12015.rddunlap@osdl.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jes@wildopensource.com Precedence: bulk X-list: netdev Content-Length: 390 Lines: 15 >>>>> "Randy" == Randy Dunlap writes: Randy> rrunner: references __initdata in a __devinit function; data Randy> should be __devinitdata; Randy> Error: ./drivers/net/rrunner.o .text refers to 00000000000002b2 Randy> R_X86_64_32S .init.data Randy> Signed-off-by: Randy Dunlap Looks good! Signed-off-by: Jes Sorensen Jes From devesh.agrawal@gmail.com Sun Feb 27 23:55:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 23:55:41 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S7tZfP026536 for ; Sun, 27 Feb 2005 23:55:35 -0800 Received: by wproxy.gmail.com with SMTP id 68so922483wra for ; Sun, 27 Feb 2005 23:55:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=gdfyq3NUAgWtFq7h3raTJN9Lc2ODBVe3BlYFb8HUm2b/9ZMtYf9WJvKNigU90vNEWHFUZwGICAx6X5jJhro7dMmvHlsxco+TSAFmCgV+W2a05tfzcb7PaYtdtqpLO6hsYGB08KdRXVh2+Y76uPv4nv3w83iaP28WsPb/0POV9ZY= Received: by 10.54.43.77 with SMTP id q77mr68880wrq; Sun, 27 Feb 2005 23:55:27 -0800 (PST) Received: by 10.54.28.49 with HTTP; Sun, 27 Feb 2005 23:55:27 -0800 (PST) Message-ID: Date: Mon, 28 Feb 2005 13:25:27 +0530 From: Devesh Agrawal Reply-To: Devesh Agrawal To: netdev@oss.sgi.com Subject: NF_IP_LOCAL_OUT handler being called again with corrupted icmp packets, resulting in kernel panic Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devesh.agrawal@gmail.com Precedence: bulk X-list: netdev Content-Length: 5478 Lines: 109 Hi, I am writing an implementation of a source routing protocol as a loadable module. I am using netfilter, I am not using the IP SSR option, I am using kernel 2.6.5, without smp and preemption support. My design is based on the DSR protocol. I have a header after the IP header, describing the source route and the route error. If 's' is the src, 'd' is the dst, and x1,x2 ... are the hops, the source route is : x1-x2...d. However unlike SSR I don't change the dst field of the ip header, which is set to d. Also every src routed packet carries with it an ack request for the next hop, to which the next hop is supposed to reply to. The jist of my code is as follows: pre_route_handler: For all source routed packets: ackReply to previous hop nxtHop = getNextHop(packet); if(ip_route_input(myaddr,nxtHop)!=0){ drop packet; } awaitAck(nxtHop); return NF_ACCEPT. In local_out_handler: cruft a packet with the source route. route it to the first hop, using ip_route_output_key(flowi,skb). I then do an awaitAck(firstHop). I intend to use this protocol in wireless networks. And hence I have implemented an ack based design, where every node is responsible for ensuring that the packet makes it to the next hop. For this the function awaitAck does the following: awaitAck(skb): add an ackRequest header. add a timer(a pointer to it) in the skb->cb. put this skb to a queue. When this timer fires: if rtxCount for the skb less than a MAX_RXMT, retransmit, else send a route error on the reverse route to the source. This scheme is working fine when there are no errors. I am testing it across an ethernet lan by pinging. However when there are link breaks, weird things happen. Specifically I am encountering the following problems. I am testing it with the following topology: A-B. Where A is the src, C is some fictional destination not connected to B. The src route at A is B-C. At B, I think that the dst->input points to ip_error instead of ip_forward. Note that B knows of a route to C (all A,B,C are in the same subnet). However I think that in rt_intern_hash function called by ip_route_input, the dst->neighbour is filled by the arp_bind_neighbour, which I expect to fail, as B doesn't know of the mac address of C, and arp obviously will fail as C and B are not connected. Surprisingly, ip_route_input succeeds, and an icmp dest unreachable packet is generated by ip_error (I think), which is passed on to the local_out_handler. Also as I have done an awaitAck on this skb, eventually it will time out and rxmit (using code similar to ip_finish_output2), and when the MAX_RXMIT limit is reached, I send a route error back (not using netfilter, basically calling dst->neighbour->output) Even more weird things happen at the src A if I use the topology A - - - B. Where again B is some fictional node not connected to A, but in the same subnet (the routing table so configured to put such packets to eth0). In the local out handler, I do a ip_route_output to B, which succeeds! .I call the output function okfn, given to me by netfilter directly and return NF_STOLEN. The next packet to come to me in local_out is an icmp dest unreach. It is destined to me, so I accept it. The next packet is again an icmp dest unreach, and after that somehow my local_out_handler is called again, while the first call of it hasn't finished. (My kernel is not smp and not preemptible). At times this happens over and over. My kernel then panics, either due to a stack overflow, or some bad eip value, or something else (with eip value not decoded, and nowhere in the /proc/kallsyms). I detect this double calling of my local_out_handler by using an atomic_t variable. The same effect is seen if I return an NF_DROP or NF_ACCEPT on the skb in the reentrant call. I have also used spinlocks but the kernel always crashes. To summarize: i) Why do ip_route_input and ip_route_output succeed, if they do, and arp obviously has to fail, will the dst->neighbour be null? ii) Since my kernel is not smp and not preemptible, the only way my local out can be called again is : either I call it myself, by calling the okfn, however okfn is always (quite rightly dst_output) and dst->output is always ip_output. Or since they are icmp dest unreach packets, they could have been called only when the prerouting returns with NF_ACCEPT, but my printk statements show no trace of pre_route_handler being called in the second test case. iii) How are icmp dest unreach packets sent while calling ip_route_output, the only place icmp_send(DEST_UNREACH) is called is in ip_error, which is assigned in the no_route part of ip_route_input, and nowhere in the ip_route_outpout. iv) Is it possible that icmp dest unreach is generated when the arp fails to get a reply, I have gone thru the arp.c file, but wasn't able to find such code. This way my local out handler could get called again from the timer softirq context. I am quite helpless, I have posted on several mailing lists(kernelnewbies, etc), but haven't received any replies, Also I couldn't find any decent material on the web related to my problem. I would be obliged if someone could please help me with this. And please forgive me for posting such a trivial problem on linux-netdev, but I am kind of desperate for help. What am I doing wrong, where can I find information on this? My code is completely based on Alex Song's DSR implementation for linux 2.4, available online at http://piconet.sf.net. Regards, Devesh Agrawal From ecalicchio@yahoo.it Sun Feb 27 23:55:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 23:55:55 -0800 (PST) Received: from web26804.mail.ukl.yahoo.com (web26804.mail.ukl.yahoo.com [217.146.176.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1S7tnrg026603 for ; Sun, 27 Feb 2005 23:55:49 -0800 Received: (qmail 18187 invoked by uid 60001); 28 Feb 2005 07:55:43 -0000 Message-ID: <20050228075543.18185.qmail@web26804.mail.ukl.yahoo.com> Received: from [151.41.218.61] by web26804.mail.ukl.yahoo.com via HTTP; Mon, 28 Feb 2005 08:55:43 CET Date: Mon, 28 Feb 2005 08:55:43 +0100 (CET) From: Emilio Calicchio Subject: questions about ipsec-tools-0.4 and linux kernel 2.6 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-429138855-1109577343=:17771" Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ecalicchio@yahoo.it Precedence: bulk X-list: netdev Content-Length: 2372 Lines: 20 --0-429138855-1109577343=:17771 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am a student of engineering in first university of Rome (“La Sapienza”) and I’m working to my degree thesis whose title is: “End-to-end real-time applications performance measurements on VPN network (both terrestrial and satellite), blocks encryption algorithms vs stream cipher ones.” Since I have to use a Linux based test bed, I must integrate the stream cipher algorithms (like Scream and Seal cipher algorithm)in the Linux ipsec implementation; at aim I wonder whether you can help me by providing the following information: Architectural description of the ipsec Linux implementation (both tools and kernel modules) the files of kernel version 2.6 and ipsec-tools-0.4 that I should modify in order to add chiper stream algorithm if someone else is facing the same topic. Thanks for your help Best regards CALICCHIO EMILIO rogaway@cs.ucdavis.edu --------------------------------- Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-429138855-1109577343=:17771 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I am a student of engineering in first university of Rome (“La Sapienza”) and I’m working to my degree thesis whose title is: “End-to-end real-time applications performance measurements on VPN network (both terrestrial and satellite), blocks encryption algorithms vs stream cipher ones.” Since I have to use a Linux based test bed, I must integrate the stream cipher algorithms (like Scream and Seal cipher algorithm)in the Linux ipsec implementation; at aim I wonder whether you can help me by providing the following information: Architectural description of the ipsec Linux implementation (both tools and kernel modules) the files of kernel version 2.6 and ipsec-tools-0.4 that I should modify in order to add chiper stream algorithm if someone else is facing the same topic. Thanks for your help Best regards CALICCHIO EMILIO rogaway@cs.ucdavis.edu

Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-429138855-1109577343=:17771-- From johnpol@2ka.mipt.ru Sun Feb 27 23:58:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Feb 2005 23:58:55 -0800 (PST) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S7wndc027690 for ; Sun, 27 Feb 2005 23:58:50 -0800 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j1S7wGRd027154; Mon, 28 Feb 2005 10:58:16 +0300 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Andrew Morton Cc: Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net In-Reply-To: <20050227233943.6cb89226.akpm@osdl.org> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FTo98wD54o5/gw974zAM" Organization: MIPT Date: Mon, 28 Feb 2005 11:04:36 +0300 Message-Id: <1109577876.28266.9.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 15:09:45 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Mon, 28 Feb 2005 10:58:19 +0300 (MSK) X-archive-position: 2122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1817 Lines: 54 --=-FTo98wD54o5/gw974zAM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-02-27 at 23:39 -0800, Andrew Morton wrote: > Guillaume Thouvenin wrote: > > > > Ok the protocol is maybe too "basic" but with this mechanism the use= r > > space application that uses the fork connector can start and stop the > > send of messages. This implementation needs somme improvements because > > currently, if two application are using the fork connector one can > > enable it and the other don't know if it is enable or not, but the ide= a > > is here I think. >=20 > Yes. But this problem can be solved in userspace, with a little library > function and a bit of locking. >=20 > IOW: use the library to enable/disable the fork connector rather than > directly doing syscalls. >=20 > It has the problem that if a client of that library crashes, the counter > gets out of whack, but really, it's not all _that_ important, and to hand= le > this properly in-kernel each client would need an open fd against some > object so we can do the close-on-exit thing properly. You'd need to crea= te > a separate netlink socket for the purpose. Why dont just extend protocol a bit? Add header after cn_msg, which will have get/set field and that is all. Properly using seq/ack fields userspace can avoid locks. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-FTo98wD54o5/gw974zAM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCItCUIKTPhE+8wY0RAjszAJ9EWkRLT5e/B2IsghRvFg/dWsYbMwCdGmoi Gl6xamHltDiX087q/rr05hw= =g7P/ -----END PGP SIGNATURE----- --=-FTo98wD54o5/gw974zAM-- From kuznet@yakov.inr.ac.ru Mon Feb 28 01:21:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 01:21:54 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1S9Lm4t004490 for ; Mon, 28 Feb 2005 01:21:49 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=biskZGh9mOI+TBrQzdPpH2/xgc1sYHS8mrmtyUJmS6jIOOk2zft9pMDJgshVL4RZRv1ZsfzL7dyfxird4NJJQcr5sXBJMlAV9ZIfPLqbf5JMZFMhMvTs0/XkrySck+6eMiAAtp3YtBoMikPZOTbTyUZ3C7Mf8BvQHHgUrOcUd3w=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id MAA26233; Mon, 28 Feb 2005 12:21:30 +0300 Date: Mon, 28 Feb 2005 12:21:30 +0300 From: Alexey Kuznetsov To: "David S. Miller" Cc: Stephen Hemminger , mostrows@speakeasy.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-ID: <20050228092130.GA26076@yakov.inr.ac.ru> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050227202011.5ccefb22.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050227202011.5ccefb22.davem@davemloft.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2123 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: 632 Lines: 17 Hello! > Changing or expanding the link level headers should only mess > up the hw checksum if you are using CHECKSUM_HW, is that what > your skge driver is using? Well, even if this driver uses CHECKSUM_UNNECESSARY, the bug is still apparently present for another devices which use CHECKSUM_HW. Actually, the bug is in ppp_input(). It is responsible for setting correct ip_summed before doing netif_rx(). It could even optimize subtracting checksum of stripped ppp header from ip_summed (f.e. ipgre_rcv() do this) But suggested fix is still correct. Unless there are another users of ppp_input() with the same problem. Alexey From herbert@gondor.apana.org.au Mon Feb 28 03:33:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 03:33:28 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SBXJup010105 for ; Mon, 28 Feb 2005 03:33:20 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D5j7y-0000dG-00; Mon, 28 Feb 2005 22:31:54 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D5j7C-0000r5-00; Mon, 28 Feb 2005 22:31:06 +1100 Date: Mon, 28 Feb 2005 22:31:06 +1100 To: Stephen Hemminger Cc: "David S. Miller" , mostrows@speakeasy.net, Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-ID: <20050228113106.GA3268@gondor.apana.org.au> References: <20050224155906.73890361@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224155906.73890361@dxpl.pdx.osdl.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 988 Lines: 28 On Thu, Feb 24, 2005 at 11:59:06PM +0000, Stephen Hemminger wrote: > > Not sure if this is correct, but shouldn't pppoe be doing the following: > ----- > diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c > --- a/drivers/net/pppoe.c 2005-02-24 15:40:10 -08:00 > +++ b/drivers/net/pppoe.c 2005-02-24 15:40:10 -08:00 > @@ -339,6 +339,7 @@ > int len = ntohs(ph->length); > skb_pull(skb, sizeof(struct pppoe_hdr)); > skb_trim(skb, len); > + skb->ip_summed = CHECKSUM_NONE; This penalises CHECKSUM_HW. We should have a generic helper function that does the checksum folding for CHECKSUM_HW and if otherwise set ip_summed to CHECKSUM_NONE. In fact it looks like the current code in ip_gre is broken in this respect as well. Let me whip up a patch tomorrow. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Feb 28 03:40:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 03:40:39 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SBeVVp010788 for ; Mon, 28 Feb 2005 03:40:31 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D5jFi-0000jO-00; Mon, 28 Feb 2005 22:39:54 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D5jFS-0000t9-00; Mon, 28 Feb 2005 22:39:38 +1100 Date: Mon, 28 Feb 2005 22:39:38 +1100 To: Stephen Hemminger Cc: "David S. Miller" , mostrows@speakeasy.net, Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-ID: <20050228113938.GA3393@gondor.apana.org.au> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050228113106.GA3268@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228113106.GA3268@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 644 Lines: 19 On Mon, Feb 28, 2005 at 10:31:06PM +1100, herbert wrote: > > In fact it looks like the current code in ip_gre is broken > in this respect as well. Actually ip_gre is probably right. It seems that CHECKSUM_UNNECESSARY should not be set for PPPOE/GRE packets at all. So it would be a bug in the sk* driver. Alexey/Dave, is this interpretation of ip_summed correct? Of course we still need to fix up CHECKSUM_HW in pppoe. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Feb 28 04:06:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 04:06:26 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SC6IMC012466 for ; Mon, 28 Feb 2005 04:06:19 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5jfB-0001E7-Ux for netdev@oss.sgi.com; Mon, 28 Feb 2005 07:06:13 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5jfB-000728-GD; Mon, 28 Feb 2005 07:06:13 -0500 Subject: Re: Interconnect virtual device? From: jamal Reply-To: hadi@cyberus.ca To: Ben Greear Cc: "'netdev@oss.sgi.com'" In-Reply-To: <4222A8F2.6080004@candelatech.com> References: <4222A8F2.6080004@candelatech.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109592365.2188.914.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 07:06:06 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2126 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: 938 Lines: 28 On Mon, 2005-02-28 at 00:15, Ben Greear wrote: > Hello! > > I am considering writing a kernel module to provide a very > simple virtual interface. This interface would be attached > to another interface, and would not be directly associated with > hardware. It can have IP addresses & routing tables, and in > almost every way appear to be a regular ethernet interface. > > The idea is that when you tx on this virtual interface, it > will cause a packet to be received on another interface. And, > when a packet is received on the interface, it will tx on the > other interface. > In other words, it redirects to another device - I take it based on some rules. Sounds to me like the mirred action already does this (and in addition can mirror). > I believe I can use this to create some interesting effects with > routing and bridging on a limitted number of physical interfaces. > What "interesting effects" ? cheers, jamal From hadi@cyberus.ca Mon Feb 28 04:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 04:11:20 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SCB7da013120 for ; Mon, 28 Feb 2005 04:11:07 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5jjp-0007CL-32 for netdev@oss.sgi.com; Mon, 28 Feb 2005 05:11:01 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5jjo-0007XI-Q0; Mon, 28 Feb 2005 07:11:01 -0500 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: jamal Reply-To: hadi@cyberus.ca To: Andrew Morton Cc: Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net In-Reply-To: <20050227233943.6cb89226.akpm@osdl.org> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109592658.2188.924.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 07:10:58 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2127 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: 1887 Lines: 44 Havent seen the beginnings of this thread. But whatever you are trying to do seems to suggest some complexity that you are trying to workaround. What was wrong with just going ahead and just always invoking your netlink_send()? If there are nobody in user space (or kernel) listening, it wont go anywhere. cheers, jamal On Mon, 2005-02-28 at 02:39, Andrew Morton wrote: > Guillaume Thouvenin wrote: > > > > Ok the protocol is maybe too "basic" but with this mechanism the user > > space application that uses the fork connector can start and stop the > > send of messages. This implementation needs somme improvements because > > currently, if two application are using the fork connector one can > > enable it and the other don't know if it is enable or not, but the idea > > is here I think. > > Yes. But this problem can be solved in userspace, with a little library > function and a bit of locking. > > IOW: use the library to enable/disable the fork connector rather than > directly doing syscalls. > > It has the problem that if a client of that library crashes, the counter > gets out of whack, but really, it's not all _that_ important, and to handle > this properly in-kernel each client would need an open fd against some > object so we can do the close-on-exit thing properly. You'd need to create > a separate netlink socket for the purpose. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lse-tech mailing list > Lse-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lse-tech > From tgraf@suug.ch Mon Feb 28 05:20:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 05:20:39 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SDKXYI018694 for ; Mon, 28 Feb 2005 05:20:34 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id EC98F89; Mon, 28 Feb 2005 14:20:09 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id DA8F61C0EA; Mon, 28 Feb 2005 14:20:51 +0100 (CET) Date: Mon, 28 Feb 2005 14:20:51 +0100 From: Thomas Graf To: jamal Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228132051.GO31837@postel.suug.ch> References: <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109592658.2188.924.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2128 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1345 Lines: 33 > Havent seen the beginnings of this thread. But whatever you are trying > to do seems to suggest some complexity that you are trying to > workaround. What was wrong with just going ahead and just always > invoking your netlink_send()? I guess parts of the wheel are broken and need to be reinvented ;-> > If there are nobody in user space (or kernel) listening, it wont go anywhere. Additional you may want to extend netlink a bit to check whether there is a listener before creating the messages. The method to do so depends on whether you use netlink_send() or netlink_brodacast(). The latter is more flexiable because you can add more groups later on and the userspace applications can decicde which ones they want to listen to. Both methods handle dying clients perfectly fine, the association to the netlink socket gets destroyed as soon as the socket is closed. Therefore you can simply check mc_list of the netlink protocol you use to see if there are any listeners registered: static inline int netlink_has_listeners(struct sock *sk) { int ret; read_lock(&nl_table_lock); ret = list_empty(&nl_table[sk->sk_protocol].mc_list) read_unlock(&nl_table_lock); return !ret; } This is simplified and ignores the actual group assignments, i.e. you might want to extend it to have it check if there are listeners for a certain group. From hadi@cyberus.ca Mon Feb 28 05:40:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 05:40:25 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SDeKYD019580 for ; Mon, 28 Feb 2005 05:40:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5l89-0003eK-I9 for netdev@oss.sgi.com; Mon, 28 Feb 2005 06:40:13 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5l89-0002w3-HT; Mon, 28 Feb 2005 08:40:13 -0500 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net In-Reply-To: <20050228132051.GO31837@postel.suug.ch> References: <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109598010.2188.994.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 08:40:10 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2129 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: 1584 Lines: 43 netlink broadcast or a wrapper around it. Why even bother doing the check with netlink_has_listeners()? cheers, jamal On Mon, 2005-02-28 at 08:20, Thomas Graf wrote: > > Havent seen the beginnings of this thread. But whatever you are trying > > to do seems to suggest some complexity that you are trying to > > workaround. What was wrong with just going ahead and just always > > invoking your netlink_send()? > > I guess parts of the wheel are broken and need to be reinvented ;-> > > > If there are nobody in user space (or kernel) listening, it wont go anywhere. > > Additional you may want to extend netlink a bit to check whether > there is a listener before creating the messages. The method to do so > depends on whether you use netlink_send() or netlink_brodacast(). The > latter is more flexiable because you can add more groups later on > and the userspace applications can decicde which ones they want to > listen to. Both methods handle dying clients perfectly fine, the > association to the netlink socket gets destroyed as soon as the socket > is closed. Therefore you can simply check mc_list of the netlink > protocol you use to see if there are any listeners registered: > > static inline int netlink_has_listeners(struct sock *sk) > { > int ret; > > read_lock(&nl_table_lock); > ret = list_empty(&nl_table[sk->sk_protocol].mc_list) > read_unlock(&nl_table_lock); > > return !ret; > } > > This is simplified and ignores the actual group assignments, i.e. you > might want to extend it to have it check if there are listeners for > a certain group. > From tgraf@suug.ch Mon Feb 28 05:52:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 05:52:51 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SDqlWZ020867 for ; Mon, 28 Feb 2005 05:52:48 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3BBA489; Mon, 28 Feb 2005 14:52:24 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 9666E1C0EA; Mon, 28 Feb 2005 14:53:07 +0100 (CET) Date: Mon, 28 Feb 2005 14:53:07 +0100 From: Thomas Graf To: jamal Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228135307.GP31837@postel.suug.ch> References: <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109598010.2188.994.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2130 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 581 Lines: 11 * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > netlink broadcast or a wrapper around it. > Why even bother doing the check with netlink_has_listeners()? To implement the master enable/disable switch they want. The messages don't get send out anyway but why bother doing all the work if nothing will get send out in the end? It implements a well defined flag controlled by open/close on fds (thus handles dying applications) stating whether the whole code should be enabled or disabled. It is of course not needed to avoid sending unnecessary messages. From marcelo.tosatti@cyclades.com Mon Feb 28 05:53:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 05:53:52 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SDriqV021196 for ; Mon, 28 Feb 2005 05:53:44 -0800 Received: from [127.0.0.1] (helo=logos.cnet) by parcelfarce.linux.theplanet.co.uk with esmtp (Exim 4.33) id 1D5lL9-00038y-Gu; Mon, 28 Feb 2005 13:53:40 +0000 Received: by logos.cnet (Postfix, from userid 500) id 13F64122EBB; Mon, 28 Feb 2005 06:29:01 -0300 (BRT) Date: Mon, 28 Feb 2005 06:29:01 -0300 From: Marcelo Tosatti To: jamal Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228092901.GE23606@logos.cnet> References: <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109592658.2188.924.camel@jzny.localdomain> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: netdev Content-Length: 2244 Lines: 56 I'm net ignorant, so just hit me with a cluebat if thats appropriate. On Mon, Feb 28, 2005 at 07:10:58AM -0500, jamal wrote: > > Havent seen the beginnings of this thread. But whatever you are trying > to do seems to suggest some complexity that you are trying to > workaround. What was wrong with just going ahead and just always > invoking your netlink_send()? What overhead does the netlink_send() impose if there are no listeners? Sure, it wont go anywhere, but the message will have to be assembled and sent anyway. Correct? The way things are now, its necessary to make the decision to invoke or not netlink_send() due to the supposed overhead. Thats what Guillaume is doing, and thats what will have to be done whenever one wants to send information through netlink from performance critical paths. Can't the assembly/etc overhead associated with netlink_send() be avoided earlier, approaching zero-cost ? Being able to get rid of the decision to invoke or not the sendmsg would be nice. TIA > If there are nobody in user space (or > kernel) listening, it wont go anywhere. > > cheers, > jamal > > On Mon, 2005-02-28 at 02:39, Andrew Morton wrote: > > Guillaume Thouvenin wrote: > > > > > > Ok the protocol is maybe too "basic" but with this mechanism the user > > > space application that uses the fork connector can start and stop the > > > send of messages. This implementation needs somme improvements because > > > currently, if two application are using the fork connector one can > > > enable it and the other don't know if it is enable or not, but the idea > > > is here I think. > > > > Yes. But this problem can be solved in userspace, with a little library > > function and a bit of locking. > > > > IOW: use the library to enable/disable the fork connector rather than > > directly doing syscalls. > > > > It has the problem that if a client of that library crashes, the counter > > gets out of whack, but really, it's not all _that_ important, and to handle > > this properly in-kernel each client would need an open fd against some > > object so we can do the close-on-exit thing properly. You'd need to create > > a separate netlink socket for the purpose. From kuznet@yakov.inr.ac.ru Mon Feb 28 06:05:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 06:05:13 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1SE58dP022230 for ; Mon, 28 Feb 2005 06:05:09 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=VgYN1eISPKq08gHHZpJRjm7hXFTCuuj1VqgsheI1BiN+5ddldfY6o5JtXPjht/YatDWI1rLelAmVw8UbAl27iQD/gnhaFvMqVnrrbuTNO15RqIo3621/WrH3vRdGhWTvDhMNiSGdC/4zIRpFGkoECEOATLxpIApN037yZ3OQqyc=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id RAA28043; Mon, 28 Feb 2005 17:04:01 +0300 Date: Mon, 28 Feb 2005 17:04:01 +0300 From: Alexey Kuznetsov To: Herbert Xu Cc: Stephen Hemminger , "David S. Miller" , mostrows@speakeasy.net, Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-ID: <20050228140401.GA27937@yakov.inr.ac.ru> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050228113106.GA3268@gondor.apana.org.au> <20050228113938.GA3393@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228113938.GA3393@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2132 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: 611 Lines: 17 Hello! > Actually ip_gre is probably right. It seems that CHECKSUM_UNNECESSARY > should not be set for PPPOE/GRE packets at all. So it would be a bug in > the sk* driver. > > Alexey/Dave, is this interpretation of ip_summed correct? What's about CHECKSUM_UNNECESSARY, yes, it is set only for TCP/UDP packets, when device verifies the checksum itself. It is not the case for PPOE frames. CHECKSUM_HW is more flxible, ipip/gre tunnels use this adjusting skb->csum by checksum of stripped headers. ppp_input() could do the same thing. It does not, hence suggested patch is corrrect minimal solution. Alexey From hadi@cyberus.ca Mon Feb 28 06:10:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 06:10:18 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SEACuN022819 for ; Mon, 28 Feb 2005 06:10:14 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5lb4-0007rL-1Z for netdev@oss.sgi.com; Mon, 28 Feb 2005 07:10:06 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5lb5-0007Ij-0x; Mon, 28 Feb 2005 09:10:07 -0500 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net In-Reply-To: <20050228135307.GP31837@postel.suug.ch> References: <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109599803.2188.1014.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 09:10:03 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2133 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: 1671 Lines: 36 On Mon, 2005-02-28 at 08:53, Thomas Graf wrote: > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > netlink broadcast or a wrapper around it. > > Why even bother doing the check with netlink_has_listeners()? > > To implement the master enable/disable switch they want. The messages > don't get send out anyway but why bother doing all the work if nothing > will get send out in the end? It implements a well defined flag > controlled by open/close on fds (thus handles dying applications) > stating whether the whole code should be enabled or disabled. It is of > course not needed to avoid sending unnecessary messages. To justify writting the new code, I am assuming someone has actually sat down and in the minimal stuck their finger in the air and said "yes, there is definetely wind there". Which leadsto Marcello's question in other email: Theres some overhead. - Message needs to be built with skbs allocated (not the cn_xxx thing that seems to be invoked - I suspect that thing will build the skbs); - the netlink table needs to be locked -and searched and only then do you find theres nothing to send to. The point i was making is if you actually had to post this question, then you must be running into some problems of complexity ;-> which implies to me that the delta overhead maybe worth it compared to introducing the complexity or any new code. I wasnt involved in the discussion - I just woke up and saw the posting and was bored. So the justification for the optimization has probably been explained and it may be worth doing the check (but probably such check should go into whatever that cn_xxx is). cheers, jamal From marcelo.tosatti@cyclades.com Mon Feb 28 06:17:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 06:17:13 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SEH9ro023484 for ; Mon, 28 Feb 2005 06:17:10 -0800 Received: from [127.0.0.1] (helo=logos.cnet) by parcelfarce.linux.theplanet.co.uk with esmtp (Exim 4.33) id 1D5lhl-0003er-Hl; Mon, 28 Feb 2005 14:17:02 +0000 Received: by logos.cnet (Postfix, from userid 500) id 0626E122EBB; Mon, 28 Feb 2005 06:52:04 -0300 (BRT) Date: Mon, 28 Feb 2005 06:52:04 -0300 From: Marcelo Tosatti To: Thomas Graf Cc: jamal , Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228095204.GH23606@logos.cnet> References: <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228135307.GP31837@postel.suug.ch> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2134 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: netdev Content-Length: 739 Lines: 17 On Mon, Feb 28, 2005 at 02:53:07PM +0100, Thomas Graf wrote: > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > netlink broadcast or a wrapper around it. > > Why even bother doing the check with netlink_has_listeners()? > > To implement the master enable/disable switch they want. The messages > don't get send out anyway but why bother doing all the work if nothing > will get send out in the end? It implements a well defined flag > controlled by open/close on fds (thus handles dying applications) > stating whether the whole code should be enabled or disabled. Yep - this far from "reinventing the wheel". ;) > It is of course not needed to avoid sending unnecessary messages. Thats the goal, thanks. From tgraf@suug.ch Mon Feb 28 06:25:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 06:25:37 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SEPXSF024267 for ; Mon, 28 Feb 2005 06:25:33 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id EC46F89; Mon, 28 Feb 2005 15:25:09 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id EDF4C1C0EA; Mon, 28 Feb 2005 15:25:51 +0100 (CET) Date: Mon, 28 Feb 2005 15:25:51 +0100 From: Thomas Graf To: jamal Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228142551.GQ31837@postel.suug.ch> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109599803.2188.1014.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2542 Lines: 48 * jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 > On Mon, 2005-02-28 at 08:53, Thomas Graf wrote: > > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > > > netlink broadcast or a wrapper around it. > > > Why even bother doing the check with netlink_has_listeners()? > > > > To implement the master enable/disable switch they want. The messages > > don't get send out anyway but why bother doing all the work if nothing > > will get send out in the end? It implements a well defined flag > > controlled by open/close on fds (thus handles dying applications) > > stating whether the whole code should be enabled or disabled. It is of > > course not needed to avoid sending unnecessary messages. > > To justify writting the new code, I am assuming someone has actually sat > down and in the minimal stuck their finger in the air > and said "yes, there is definetely wind there". I did, not for this problem though. The code this idea comes from sends batched events of skb passing points to userspace. Not every call invokes has_listeneres() but rather the kernel thread processing the ring buffer sending the events to userspaces does. The result is globally cached in a atomic_t making it possible to check for it at zero-cost and really saving time and effort. I have no clue wether it does make sense in this case I just pointed out how to do it properly at my point of view. > Which leadsto Marcello's question in other email: > Theres some overhead. > - Message needs to be built with skbs allocated (not the cn_xxx thing > that seems to be invoked - I suspect that thing will build the skbs); > - the netlink table needs to be locked > -and searched and only then do you find theres nothing to send to. > > The point i was making is if you actually had to post this question, > then you must be running into some problems of complexity ;-> > which implies to me that the delta overhead maybe worth it compared to > introducing the complexity or any new code. > I wasnt involved in the discussion - I just woke up and saw the posting > and was bored. So the justification for the optimization has probably > been explained and it may be worth doing the check (but probably such > check should go into whatever that cn_xxx is). I wasn't involved in the discussion either. Using rtmsg_ifinfo as example, the check should probably go in straight at the beginning _IFF_ rtmsg_ifinfo was subject to performance overhead which obviously isn't the case but just served as an example. From hadi@cyberus.ca Mon Feb 28 07:31:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 07:31:54 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SFVnZo026413 for ; Mon, 28 Feb 2005 07:31:50 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5ms5-0007LM-O4 for netdev@oss.sgi.com; Mon, 28 Feb 2005 10:31:45 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5mrx-0004vq-LG; Mon, 28 Feb 2005 10:31:37 -0500 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net In-Reply-To: <20050228142551.GQ31837@postel.suug.ch> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109604693.1072.8.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 10:31:33 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2136 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: 994 Lines: 24 On Mon, 2005-02-28 at 09:25, Thomas Graf wrote: > * jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 [..] > > To justify writting the new code, I am assuming someone has actually sat > > down and in the minimal stuck their finger in the air > > and said "yes, there is definetely wind there". > > I did, not for this problem though. The code this idea comes from sends > batched events I would bet the benefit you are seeing has to do with batching rather than such an optimization flag. Different ballgame. I relooked at their code snippet, they dont even have skbs built nor even figured out what sock or PID. That work still needs to be done it seems in cn_netlink_send(). So probably all they need to do is move the check in cn_netlink_send() instead. This is assuming they are not scratching their heads with some realted complexities. I am gonna disapear for a while; hopefully the original posters have gathered some ideas from what we discussed. cheers, jamal From johnpol@2ka.mipt.ru Mon Feb 28 07:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 07:54:21 -0800 (PST) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SFsEIK027441 for ; Mon, 28 Feb 2005 07:54:14 -0800 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j1SFqZ9C005361; Mon, 28 Feb 2005 18:52:38 +0300 Date: Mon, 28 Feb 2005 19:17:59 +0300 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: Thomas Graf , Andrew Morton , Guillaume Thouvenin , kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-ID: <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> In-Reply-To: <1109604693.1072.8.camel@jzny.localdomain> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Mon, 28 Feb 2005 18:52:38 +0300 (MSK) X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1786 Lines: 43 On 28 Feb 2005 10:31:33 -0500 jamal wrote: > On Mon, 2005-02-28 at 09:25, Thomas Graf wrote: > > * jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 > [..] > > > To justify writting the new code, I am assuming someone has actually sat > > > down and in the minimal stuck their finger in the air > > > and said "yes, there is definetely wind there". > > > > I did, not for this problem though. The code this idea comes from sends > > batched events > > I would bet the benefit you are seeing has to do with batching rather > than such an optimization flag. Different ballgame. > I relooked at their code snippet, they dont even have skbs built nor > even figured out what sock or PID. That work still needs to be done it > seems in cn_netlink_send(). So probably all they need to do is move the > check in cn_netlink_send() instead. This is assuming they are not > scratching their heads with some realted complexities. > > I am gonna disapear for a while; hopefully the original posters have > gathered some ideas from what we discussed. As connector author, I still doubt it worth copying several lines from netlink_broadcast() before skb allocation in cn_netlink_send(). Of course it is easy and can be done, but I do not see any profit here. Atomic allocation is fast, if it succeds, but there are no groups/socket to send, skb will be freed, if allocation fails, then group check is useless. I would prefer Guillaume Thouvenin as fork connector author to test his current implementation and show that connector's cost is negligible both with and without userspace listeners. As far as I remember it is first entry in fork connector's TODO list. > cheers, > jamal > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From weber@faps.uni-erlangen.de Mon Feb 28 08:17:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 08:17:11 -0800 (PST) Received: from moritz.faps.uni-erlangen.de (moritz.faps.uni-erlangen.de [131.188.113.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SGH4bs028742 for ; Mon, 28 Feb 2005 08:17:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: filtering packtes before OS takes care about them Date: Mon, 28 Feb 2005 17:16:57 +0100 Message-ID: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: filtering packtes before OS takes care about them thread-index: AcUdsO0OF+qdfvzERdq/zulJHtwZdQ== From: "Weber Matthias" To: X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1SGH4bs028742 X-archive-position: 2138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weber@faps.uni-erlangen.de Precedence: bulk X-list: netdev Content-Length: 755 Lines: 24 Hi, i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and * to delete them from input buffer such that OS' netmodules can't receive them * to modify packet headers and move packets to interface related output buffers * to keep them in input buffers such that OS' netmodules can take care about them. I would be thankfull for any hint, link or code example. Bye Matthias -- Dipl.-Inf. Matthias Weber Universität Erlangen-Nürnberg Lehrstuhl für Fertigungsautomatisierung und Produktionssystematik Egerlandstraße 7-9 91058 Erlangen Tel. :*49 9131/85-27702 Fax. :*49 9131/302528 www :www.faps.uni-erlangen.de mailto:weber@faps.uni-erlangen.de From shemminger@osdl.org Mon Feb 28 09:13:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 09:13:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SHDTGt002348 for ; Mon, 28 Feb 2005 09:13:29 -0800 Received: from [192.168.0.106] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j1SHCvqi029738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 28 Feb 2005 09:12:59 -0800 Message-ID: <42235114.3070109@osdl.org> Date: Mon, 28 Feb 2005 09:12:52 -0800 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: mostrows@speakeasy.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050227202011.5ccefb22.davem@davemloft.net> In-Reply-To: <20050227202011.5ccefb22.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2139 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: 777 Lines: 18 >>Someone reported a problem with skge hardware receive checksumming and PPPOE >>> but it looks like a generic problem. Since PPPOE adds additional header >>> bytes the hardware computed checksum will be wrong. >>> >>> Not sure if this is correct, but shouldn't pppoe be doing the following: > > > Changing or expanding the link level headers should only mess > up the hw checksum if you are using CHECKSUM_HW, is that what > your skge driver is using? The hardware doesn't appear to actually decode the packet, it just has the ability to compute data sum of packet starting at an arbitrary byte offset. This matched the description of CHECKSUM_HW so that is what I used. The original sk98lin attempted to receive hardware checksumming but never actually turned it on. From greearb@candelatech.com Mon Feb 28 09:24:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 09:24:32 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SHOQWk003110 for ; Mon, 28 Feb 2005 09:24:27 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j1SHkZLH021481; Mon, 28 Feb 2005 09:46:35 -0800 Message-ID: <422353C9.6050001@candelatech.com> Date: Mon, 28 Feb 2005 09:24:25 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "'netdev@oss.sgi.com'" Subject: Re: Interconnect virtual device? References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> In-Reply-To: <1109592365.2188.914.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2140 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: 1771 Lines: 47 jamal wrote: > On Mon, 2005-02-28 at 00:15, Ben Greear wrote: > >>Hello! >> >>I am considering writing a kernel module to provide a very >>simple virtual interface. This interface would be attached >>to another interface, and would not be directly associated with >>hardware. It can have IP addresses & routing tables, and in >>almost every way appear to be a regular ethernet interface. >> >>The idea is that when you tx on this virtual interface, it >>will cause a packet to be received on another interface. And, >>when a packet is received on the interface, it will tx on the >>other interface. >> > > > In other words, it redirects to another device - I take it based on some > rules. Sounds to me like the mirred action already does this (and in > addition can mirror). Actually, I was thinking that either user-space or perhaps a kernel module could use the standard methods of receiving all pkts in promisc mode to do the bridging portion. If I force the real ethernet interface to have no IP address, and put it into promisc mode, then I can effectively bridge in user-space. When I re-insert the pkts into the stack by writing to the virtual device, the (potentially modified) packet can be routed and firewalled, etc just like a normal packet received from the network. I may need to have two virtual inter-connects, one w/out an IP that does the bridging portion, and one with an IP that actually communicates with the rest of the kernel. In this case, the two virtuals would be connected to each other. I think this could provide a way to do very customized actions on raw packets without having to hack the kernel on an ongoing basis. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From mchan@broadcom.com Mon Feb 28 09:26:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 09:26:47 -0800 (PST) Received: from MMS3.broadcom.com (mms-nat.broadcom.com [63.70.210.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SHQhXr003641 for ; Mon, 28 Feb 2005 09:26:43 -0800 Received: from 63.70.210.1 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 28 Feb 2005 09:26:42 -0800 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 28 Feb 2005 09:26:29 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AMT20818; Mon, 28 Feb 2005 09:26:26 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA27539; Mon, 28 Feb 2005 09:26:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: tg3 kernel oops when setting flow control while interface is down (2.6.10) Date: Mon, 28 Feb 2005 09:26:25 -0800 Message-ID: Thread-Topic: tg3 kernel oops when setting flow control while interface is down (2.6.10) Thread-Index: AcUdQbo1knAA0OAjRVOnkMkTkmDJBAAeDANQ From: "Michael Chan" To: "Daniel Willmann" , netdev@oss.sgi.com cc: jluebbe@lasnet.de, davem@redhat.com X-WSS-ID: 6E3D8BD82WC6591614-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1SHQhXr003641 X-archive-position: 2141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 599 Lines: 25 > > --- drivers/net/tg3.c.old 2005-02-27 23:26:48.000000000 +0100 > +++ drivers/net/tg3.c 2005-02-28 02:01:11.000000000 +0100 > @@ -6155,6 +6155,10 @@ > { > struct tg3 *tp = netdev_priv(dev); > > + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || > + tp->link_config.phy_is_low_power) > + return -EAGAIN; > + > tg3_netif_stop(tp); > spin_lock_irq(&tp->lock); > spin_lock(&tp->tx_lock); > > -------- I think it is better to just set the PAUSE flags and return 0 if !netif_running(). This way, the settings will take effect when the device is subsequently brought up. Michael From jdmason@us.ibm.com Mon Feb 28 09:34:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 09:34:47 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SHYfR5004323 for ; Mon, 28 Feb 2005 09:34:42 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1SHY0Lg583140 for ; Mon, 28 Feb 2005 12:34:05 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SHY0e1153560 for ; Mon, 28 Feb 2005 10:34:00 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SHXxIG018205 for ; Mon, 28 Feb 2005 10:33:59 -0700 Received: from dreadnought (dreadnought.austin.ibm.com [9.41.94.123]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j1SHXxXO018175; Mon, 28 Feb 2005 10:33:59 -0700 Received: by dreadnought (sSMTP sendmail emulation); Mon, 28 Feb 2005 11:27:53 -0600 Date: Mon, 28 Feb 2005 11:27:53 -0600 From: Jon Mason To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] r8169: Jumbo Frames mini-increase Message-ID: <20050228172753.GA13280@us.ibm.com> References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> <42224CF5.5090601@phekda.gotadsl.co.uk> <20050227235210.GA27271@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050227235210.GA27271@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1324 Lines: 34 This patch increases the maximum MTU from ~7k to 8169 (the maximum MTU that will fit into a single descriptor). Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 Signed-off-by: Jon Mason --- drivers/net/r8169.c.orig 2005-02-26 12:38:54.000000000 -0600 +++ drivers/net/r8169.c 2005-02-27 11:10:19.000000000 -0600 @@ -117,8 +117,9 @@ static int multicast_filter_limit = 32; #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ +#define LargeSendETT 0x35 #define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */ -#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */ +#define SafeMtu 0x1FE9 /* Largest MTU that can fit in a single desc */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define R8169_REGS_SIZE 256 @@ -1576,8 +1577,12 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(Cfg9346, Cfg9346_Unlock); RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); - RTL_W8(EarlyTxThres, EarlyTxThld); + if (dev->mtu < 7400) + RTL_W8(EarlyTxThres, EarlyTxThld); + else + RTL_W8(EarlyTxThres, LargeSendETT); + /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); From ahu@outpost.ds9a.nl Mon Feb 28 09:38:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 09:38:10 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SHc3M4004902 for ; Mon, 28 Feb 2005 09:38:04 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6545D3FCE; Mon, 28 Feb 2005 18:38:00 +0100 (CET) Date: Mon, 28 Feb 2005 18:38:00 +0100 From: bert hubert To: Weber Matthias Cc: netdev@oss.sgi.com Subject: Re: filtering packtes before OS takes care about them Message-ID: <20050228173800.GA16865@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Weber Matthias , netdev@oss.sgi.com References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 804 Lines: 25 On Mon, Feb 28, 2005 at 05:16:57PM +0100, Weber Matthias wrote: > i need a possibility to catch IP4 packets (from ethernet devices) before > OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care > about them and Why? It helps if you tell us what you really want, or is this a research project? The earliest place I know of is with tc filter, but that is a netfilter hook. So part of netfilter will "see" your code. What you appear to be asking for is a packet filtering network adaptor? These exist. > * to modify packet headers and move packets to interface related output > * buffers Sure you want an operating system? Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From weber@faps.uni-erlangen.de Mon Feb 28 10:59:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 10:59:59 -0800 (PST) Received: from moritz.faps.uni-erlangen.de (moritz.faps.uni-erlangen.de [131.188.113.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SIxqf1008419 for ; Mon, 28 Feb 2005 10:59:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: filtering packtes before OS takes care about them Date: Mon, 28 Feb 2005 19:59:46 +0100 Message-ID: <09766A6E64A068419B362367800D50C0B58A18@moritz.faps.uni-erlangen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: filtering packtes before OS takes care about them thread-index: AcUdvIdj7X55Wuv/SFm7ruX7R33TfQAAA+aQ From: "Weber Matthias" To: "bert hubert" Cc: X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1SIxqf1008419 X-archive-position: 2144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weber@faps.uni-erlangen.de Precedence: bulk X-list: netdev Content-Length: 1813 Lines: 43 I need to develop a special gateway. It shall map exernal ips to internal ports and external ports to internal ips (kind of NAT but connections have to be established from external to internal network and vice versa!), so the sender,receveiver addresses and ports have to be changed off each package received. Afterwards these packets shall be resent via one (out of more) interfaces. Therefore kernel's IP stuff disturbs me, but because i want to use TCP/IP at the gateway itself too (the computer runs applications using IP), i still need it. Thus the most easiest way should be to be the first one dealing those packets when they arrive. AFAIK before netfilter gets the packets the kernel's router already got them... Hope i made may needs clear? Thanks for help, Matthias -----Ursprüngliche Nachricht----- Von: bert hubert [mailto:ahu@ds9a.nl] Gesendet: Montag, 28. Februar 2005 18:38 An: Weber Matthias Cc: netdev@oss.sgi.com Betreff: Re: filtering packtes before OS takes care about them On Mon, Feb 28, 2005 at 05:16:57PM +0100, Weber Matthias wrote: > i need a possibility to catch IP4 packets (from ethernet devices) > before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) > takes care about them and Why? It helps if you tell us what you really want, or is this a research project? The earliest place I know of is with tc filter, but that is a netfilter hook. So part of netfilter will "see" your code. What you appear to be asking for is a packet filtering network adaptor? These exist. > * to modify packet headers and move packets to interface related > output > * buffers Sure you want an operating system? Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From jdmason@us.ibm.com Mon Feb 28 11:11:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 11:11:07 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SJAtVG009135 for ; Mon, 28 Feb 2005 11:11:02 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1SJAk5j666638 for ; Mon, 28 Feb 2005 14:10:46 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SJAke1158272 for ; Mon, 28 Feb 2005 12:10:46 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SJAkDs022117 for ; Mon, 28 Feb 2005 12:10:46 -0700 Received: from dreadnought (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j1SJAjrT022110; Mon, 28 Feb 2005 12:10:46 -0700 Received: by dreadnought (sSMTP sendmail emulation); Mon, 28 Feb 2005 13:04:44 -0600 Date: Mon, 28 Feb 2005 13:04:44 -0600 From: Jon Mason To: romieu@fr.zoreil.com Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] r8169: RTL8169_registers clean-up Message-ID: <20050228190444.GA13415@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5065 Lines: 229 An attempt to clean-up RTL8169_registers and RTL8169_register_content. Adjusted tab alignment and converted decimal values to hex. Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 Signed-off-by: Jon Mason --- drivers/net/r8169.c 2005-02-27 11:45:27.000000000 -0600 +++ drivers/net/r8169.c.new 2005-02-27 11:44:44.000000000 -0600 @@ -186,91 +186,91 @@ static int rx_copybreak = 200; static int use_dac; enum RTL8169_registers { - MAC0 = 0, /* Ethernet hardware address. */ - MAR0 = 8, /* Multicast filter. */ + MAC0 = 0x00, /* Ethernet hardware address. */ + MAR0 = 0x08, /* Multicast filter. */ TxDescStartAddrLow = 0x20, TxDescStartAddrHigh = 0x24, TxHDescStartAddrLow = 0x28, TxHDescStartAddrHigh = 0x2c, - FLASH = 0x30, - ERSR = 0x36, - ChipCmd = 0x37, - TxPoll = 0x38, - IntrMask = 0x3C, - IntrStatus = 0x3E, - TxConfig = 0x40, - RxConfig = 0x44, - RxMissed = 0x4C, - Cfg9346 = 0x50, - Config0 = 0x51, - Config1 = 0x52, - Config2 = 0x53, - Config3 = 0x54, - Config4 = 0x55, - Config5 = 0x56, - MultiIntr = 0x5C, - PHYAR = 0x60, - TBICSR = 0x64, - TBI_ANAR = 0x68, - TBI_LPAR = 0x6A, - PHYstatus = 0x6C, - RxMaxSize = 0xDA, - CPlusCmd = 0xE0, - IntrMitigate = 0xE2, - RxDescAddrLow = 0xE4, - RxDescAddrHigh = 0xE8, - EarlyTxThres = 0xEC, - FuncEvent = 0xF0, - FuncEventMask = 0xF4, + FLASH = 0x30, + ERSR = 0x36, + ChipCmd = 0x37, + TxPoll = 0x38, + IntrMask = 0x3C, + IntrStatus = 0x3E, + TxConfig = 0x40, + RxConfig = 0x44, + RxMissed = 0x4C, + Cfg9346 = 0x50, + Config0 = 0x51, + Config1 = 0x52, + Config2 = 0x53, + Config3 = 0x54, + Config4 = 0x55, + Config5 = 0x56, + MultiIntr = 0x5C, + PHYAR = 0x60, + TBICSR = 0x64, + TBI_ANAR = 0x68, + TBI_LPAR = 0x6A, + PHYstatus = 0x6C, + RxMaxSize = 0xDA, + CPlusCmd = 0xE0, + IntrMitigate = 0xE2, + RxDescAddrLow = 0xE4, + RxDescAddrHigh = 0xE8, + EarlyTxThres = 0xEC, + FuncEvent = 0xF0, + FuncEventMask = 0xF4, FuncPresetState = 0xF8, - FuncForceEvent = 0xFC, + FuncForceEvent = 0xFC, }; enum RTL8169_register_content { /* InterruptStatusBits */ - SYSErr = 0x8000, - PCSTimeout = 0x4000, - SWInt = 0x0100, - TxDescUnavail = 0x80, - RxFIFOOver = 0x40, - LinkChg = 0x20, - RxOverflow = 0x10, - TxErr = 0x08, - TxOK = 0x04, - RxErr = 0x02, - RxOK = 0x01, + SYSErr = 0x8000, + PCSTimeout = 0x4000, + SWInt = 0x0100, + TxDescUnavail = 0x80, + RxFIFOOver = 0x40, + LinkChg = 0x20, + RxOverflow = 0x10, + TxErr = 0x08, + TxOK = 0x04, + RxErr = 0x02, + RxOK = 0x01, /* RxStatusDesc */ - RxRES = 0x00200000, - RxCRC = 0x00080000, - RxRUNT = 0x00100000, - RxRWT = 0x00400000, + RxRES = 0x00200000, + RxCRC = 0x00080000, + RxRUNT = 0x00100000, + RxRWT = 0x00400000, /* ChipCmdBits */ - CmdReset = 0x10, - CmdRxEnb = 0x08, - CmdTxEnb = 0x04, - RxBufEmpty = 0x01, + CmdReset = 0x10, + CmdRxEnb = 0x08, + CmdTxEnb = 0x04, + RxBufEmpty = 0x01, /* Cfg9346Bits */ - Cfg9346_Lock = 0x00, - Cfg9346_Unlock = 0xC0, + Cfg9346_Lock = 0x00, + Cfg9346_Unlock = 0xC0, /* rx_mode_bits */ - AcceptErr = 0x20, - AcceptRunt = 0x10, + AcceptErr = 0x20, + AcceptRunt = 0x10, AcceptBroadcast = 0x08, AcceptMulticast = 0x04, - AcceptMyPhys = 0x02, - AcceptAllPhys = 0x01, + AcceptMyPhys = 0x02, + AcceptAllPhys = 0x01, /* RxConfigBits */ - RxCfgFIFOShift = 13, - RxCfgDMAShift = 8, + RxCfgFIFOShift = 0x0D, + RxCfgDMAShift = 0x08, /* TxConfigBits */ - TxInterFrameGapShift = 24, - TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ + TxInterFrameGapShift = 0x18, + TxDMAShift = 0x08, /* DMA burst value (0-7) is shiftied this many bits */ /* TBICSR p.28 */ TBIReset = 0x80000000, @@ -287,20 +287,20 @@ enum RTL8169_register_content { PCIMulRW = (1 << 3), /* rtl8169_PHYstatus */ - TBI_Enable = 0x80, - TxFlowCtrl = 0x40, - RxFlowCtrl = 0x20, - _1000bpsF = 0x10, - _100bps = 0x08, - _10bps = 0x04, - LinkStatus = 0x02, - FullDup = 0x01, + TBI_Enable = 0x80, + TxFlowCtrl = 0x40, + RxFlowCtrl = 0x20, + _1000bpsF = 0x10, + _100bps = 0x08, + _10bps = 0x04, + LinkStatus = 0x02, + FullDup = 0x01, /* GIGABIT_PHY_registers */ - PHY_CTRL_REG = 0, - PHY_STAT_REG = 1, - PHY_AUTO_NEGO_REG = 4, - PHY_1000_CTRL_REG = 9, + PHY_CTRL_REG = 0x00, + PHY_STAT_REG = 0x01, + PHY_AUTO_NEGO_REG = 0x04, + PHY_1000_CTRL_REG = 0x09, /* GIGABIT_PHY_REG_BIT */ PHY_Restart_Auto_Nego = 0x0200, @@ -311,24 +311,24 @@ enum RTL8169_register_content { /* PHY_AUTO_NEGO_REG = 4 */ PHY_Cap_10_Half = 0x0020, - PHY_Cap_10_Full = 0x0040, + PHY_Cap_10_Full = 0x0040, PHY_Cap_100_Half = 0x0080, PHY_Cap_100_Full = 0x0100, /* PHY_1000_CTRL_REG = 9 */ PHY_Cap_1000_Full = 0x0200, - PHY_Cap_Null = 0x0, + PHY_Cap_Null = 0x00, /* _MediaType */ - _10_Half = 0x01, - _10_Full = 0x02, - _100_Half = 0x04, - _100_Full = 0x08, - _1000_Full = 0x10, + _10_Half = 0x01, + _10_Full = 0x02, + _100_Half = 0x04, + _100_Full = 0x08, + _1000_Full = 0x10, /* _TBICSRBit */ - TBILinkOK = 0x02000000, + TBILinkOK = 0x02000000, }; enum _DescStatusBit { From romieu@fr.zoreil.com Mon Feb 28 11:36:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 11:36:21 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SJa8lU010190 for ; Mon, 28 Feb 2005 11:36:09 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1SJWAgg008378; Mon, 28 Feb 2005 20:32:10 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1SJW4Ps008377; Mon, 28 Feb 2005 20:32:04 +0100 Date: Mon, 28 Feb 2005 20:32:04 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] r8169: Jumbo Frames mini-increase Message-ID: <20050228193204.GA8186@electric-eye.fr.zoreil.com> References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> <42224CF5.5090601@phekda.gotadsl.co.uk> <20050227235210.GA27271@electric-eye.fr.zoreil.com> <20050228172753.GA13280@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228172753.GA13280@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2146 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: 660 Lines: 27 Jon Mason : [...] > Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 Thanks, I will test it on x86/sparc64. [...] > @@ -1576,8 +1577,12 @@ rtl8169_hw_start(struct net_device *dev) > > RTL_W8(Cfg9346, Cfg9346_Unlock); > RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); > - RTL_W8(EarlyTxThres, EarlyTxThld); > > + if (dev->mtu < 7400) > + RTL_W8(EarlyTxThres, EarlyTxThld); > + else > + RTL_W8(EarlyTxThres, LargeSendETT); > + 1 - Any objection against ternary operator, say: RTL_W8(EarlyTxThres, (dev->mtu < 7400) ? EarlyTxThld : LargeSendETT); 2 - patch includes uneeded tabs on the last added (empty) line. -- Ueimor From jdmason@us.ibm.com Mon Feb 28 11:47:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 11:47:27 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SJlGDP010820 for ; Mon, 28 Feb 2005 11:47:23 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1SJlBua086378 for ; Mon, 28 Feb 2005 14:47:11 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SJlAe1153260 for ; Mon, 28 Feb 2005 12:47:11 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SJlAQi015135 for ; Mon, 28 Feb 2005 12:47:10 -0700 Received: from dreadnought (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j1SJlAEl015123; Mon, 28 Feb 2005 12:47:10 -0700 Received: by dreadnought (sSMTP sendmail emulation); Mon, 28 Feb 2005 13:41:07 -0600 Date: Mon, 28 Feb 2005 13:41:07 -0600 From: Jon Mason To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] r8169: Jumbo Frames mini-increase Message-ID: <20050228194107.GA13533@us.ibm.com> References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> <42224CF5.5090601@phekda.gotadsl.co.uk> <20050227235210.GA27271@electric-eye.fr.zoreil.com> <20050228172753.GA13280@us.ibm.com> <20050228193204.GA8186@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228193204.GA8186@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1391 Lines: 34 On Mon, Feb 28, 2005 at 08:32:04PM +0100, Francois Romieu wrote: [...] > 1 - Any objection against ternary operator, say: > > RTL_W8(EarlyTxThres, (dev->mtu < 7400) ? EarlyTxThld : LargeSendETT); Sorry, one of these days I'll learn. > 2 - patch includes uneeded tabs on the last added (empty) line. Removed. See rediff below. --- drivers/net/r8169.c.orig 2005-02-27 20:26:22.000000000 -0600 +++ drivers/net/r8169.c 2005-02-28 13:40:29.000000000 -0600 @@ -117,8 +117,9 @@ static int multicast_filter_limit = 32; #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ +#define LargeSendETT 0x35 #define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */ -#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */ +#define SafeMtu 0x1FE9 /* Largest MTU that can fit in a single desc */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define R8169_REGS_SIZE 256 @@ -1576,7 +1577,7 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(Cfg9346, Cfg9346_Unlock); RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); - RTL_W8(EarlyTxThres, EarlyTxThld); + RTL_W8(EarlyTxThres, (dev->mtu < 7400) ? EarlyTxThld : LargeSendETT); /* For gigabit rtl8169, MTU + header + CRC + VLAN */ RTL_W16(RxMaxSize, tp->rx_buf_sz); From romieu@fr.zoreil.com Mon Feb 28 12:04:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 12:04:18 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SK47Vq011690 for ; Mon, 28 Feb 2005 12:04:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1SK05Uk008713; Mon, 28 Feb 2005 21:00:05 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1SJxwFx008712; Mon, 28 Feb 2005 20:59:58 +0100 Date: Mon, 28 Feb 2005 20:59:58 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2/2] r8169: RTL8169_registers clean-up Message-ID: <20050228195958.GB8186@electric-eye.fr.zoreil.com> References: <20050228190444.GA13415@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228190444.GA13415@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2148 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: 603 Lines: 16 Jon Mason : > An attempt to clean-up RTL8169_registers and RTL8169_register_content. > Adjusted tab alignment and converted decimal values to hex. > > Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 1 - It does not use bitwise shifts where possible (suggested by Jeff); 2 - It is not consistent (see TxDesc...); 3 - Please write a script to reduce the patch and prove that a typo does not hide somewhere (yep, I'm lazy). It would take too much testing to get a complete coverage. Jeff, how am I supposed to handle cleanups now ? Just say no ? :o) -- Ueimor From asimshankar@gmail.com Mon Feb 28 12:10:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 12:10:09 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SKA2Oi012330 for ; Mon, 28 Feb 2005 12:10:03 -0800 Received: by wproxy.gmail.com with SMTP id 68so1008944wri for ; Mon, 28 Feb 2005 12:09:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WKTIBHeLkq+mIIiq8OcOxh3Ni2k6eaZvsz7BLjOTWNk+Cc2MnFWHyPOhKNrFkG//ioaTkTRSRjlH0Oxc4mzlgbGgtTEWaNVjcpXHixipD5zGSG/x6asH/BEhYCUqvcLicc8ES8ciSoj+CbpwdIQRdMHF05y/j3Ssmo6yUROjre0= Received: by 10.54.52.30 with SMTP id z30mr45202wrz; Mon, 28 Feb 2005 12:09:56 -0800 (PST) Received: by 10.54.24.42 with HTTP; Mon, 28 Feb 2005 12:09:56 -0800 (PST) Message-ID: <7bca1cb50502281209798e8a00@mail.gmail.com> Date: Mon, 28 Feb 2005 14:09:56 -0600 From: Asim Shankar Reply-To: Asim Shankar To: Weber Matthias Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 797 Lines: 15 > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and > * to delete them from input buffer such that OS' netmodules can't receive them > * to modify packet headers and move packets to interface related output buffers > * to keep them in input buffers such that OS' netmodules can take care about them. You can process packets even before ip_rcv() gets them by registering your own packet handler (struct packet_type) using dev_add_pack(). I have a small sample at: http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c This may not be the cleanest way, but it isn't that dirty either. Also see: http://www.phrack.org/show.php?p=55&a=12 -- Asim From jgarzik@pobox.com Mon Feb 28 12:20:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 12:20:53 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SKKhSn016484 for ; Mon, 28 Feb 2005 12:20:43 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5rNg-0007aY-HX; Mon, 28 Feb 2005 20:20:40 +0000 Message-ID: <42237CDC.4060408@pobox.com> Date: Mon, 28 Feb 2005 15:19:40 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH 1/2] r8169: Jumbo Frames mini-increase References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050226203518.GA14688@electric-eye.fr.zoreil.com> <42224CF5.5090601@phekda.gotadsl.co.uk> <20050227235210.GA27271@electric-eye.fr.zoreil.com> <20050228172753.GA13280@us.ibm.com> <20050228193204.GA8186@electric-eye.fr.zoreil.com> In-Reply-To: <20050228193204.GA8186@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2150 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: 153 Lines: 10 Random comment. I think it's terribly cute that the max packet size is 8169. Why not represent that in decimal, as opposed to hexidecimal? Jeff From jdmason@us.ibm.com Mon Feb 28 13:02:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 13:02:44 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SL2X31018095 for ; Mon, 28 Feb 2005 13:02:40 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1SL2SLg642856 for ; Mon, 28 Feb 2005 16:02:28 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SL2ROi197100 for ; Mon, 28 Feb 2005 14:02:27 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SL2RoJ017946 for ; Mon, 28 Feb 2005 14:02:27 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SL2Rrs017920; Mon, 28 Feb 2005 14:02:27 -0700 From: Jon Mason Organization: IBM To: Jeff Garzik Subject: Re: [PATCH 1/2] r8169: Jumbo Frames mini-increase Date: Mon, 28 Feb 2005 14:56:24 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <4220ADA6.2040506@phekda.gotadsl.co.uk> <20050228193204.GA8186@electric-eye.fr.zoreil.com> <42237CDC.4060408@pobox.com> In-Reply-To: <42237CDC.4060408@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502281456.24200.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 524 Lines: 16 On Monday 28 February 2005 02:19 pm, Jeff Garzik wrote: > Random comment. > > I think it's terribly cute that the max packet size is 8169. Why not > represent that in decimal, as opposed to hexidecimal? > > Jeff It actually random that it is 8169. Jumbo Frames MTU in r8169 is dependent on the rx_buf_sz. In the 8169 case, the rx_buf_sz is actually 8191 - (ETH_HDR + VLAN_HDR + CRC). Any rx_buf_sz > 8191 is split up into multiple descriptors, which is proving to be a bit tricky. -- Jon Mason jdmason@us.ibm.com From jdmason@us.ibm.com Mon Feb 28 13:14:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 13:14:16 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SLE6jG018818 for ; Mon, 28 Feb 2005 13:14:12 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1SLDf0D723398 for ; Mon, 28 Feb 2005 16:13:41 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SLDfe1157058 for ; Mon, 28 Feb 2005 14:13:41 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SLDfAb017800 for ; Mon, 28 Feb 2005 14:13:41 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1SLDeA8017797; Mon, 28 Feb 2005 14:13:40 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 2/2] r8169: RTL8169_registers clean-up Date: Mon, 28 Feb 2005 15:07:37 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, jgarzik@pobox.com References: <20050228190444.GA13415@us.ibm.com> <20050228195958.GB8186@electric-eye.fr.zoreil.com> In-Reply-To: <20050228195958.GB8186@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: <200502281507.37909.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 935 Lines: 27 On Monday 28 February 2005 01:59 pm, Francois Romieu wrote: > Jon Mason : > > An attempt to clean-up RTL8169_registers and RTL8169_register_content. > > Adjusted tab alignment and converted decimal values to hex. > > > > Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 Ya, I've already gotten some private e-mail grief. > 1 - It does not use bitwise shifts where possible (suggested by Jeff); I never heard from you that this was the way to go. I can do this, if you still want this patch. > 2 - It is not consistent (see TxDesc...); Not seeing where you are refering to, can you give me a line #? > 3 - Please write a script to reduce the patch and prove that a typo does > not hide somewhere (yep, I'm lazy). It would take too much testing > to get a complete coverage. If you are that worried, it probably isn't worth it. Its just clean-up ;-) -- Jon Mason jdmason@us.ibm.com From mchan@broadcom.com Mon Feb 28 13:34:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 13:34:21 -0800 (PST) Received: from MMS1.broadcom.com (mms-nat.broadcom.com [63.70.210.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SLYFr1019678 for ; Mon, 28 Feb 2005 13:34:17 -0800 Received: from 63.70.210.1 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 28 Feb 2005 13:34:40 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 28 Feb 2005 13:33:59 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AMU15456; Mon, 28 Feb 2005 13:33:39 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA03143; Mon, 28 Feb 2005 13:33:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: tg3 access hangs on system shutdown with 2.6.11-rc5, tg3_stop_block timed out Date: Mon, 28 Feb 2005 13:33:38 -0800 Message-ID: Thread-Topic: tg3 access hangs on system shutdown with 2.6.11-rc5, tg3_stop_block timed out Thread-Index: AcUcHx9HcO6MYrY2SKqov26LRDl5qABuvc0Q From: "Michael Chan" To: "Olaf Hering" , netdev@oss.sgi.com X-WSS-ID: 6E3D51FA1JG7252969-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1SLYFr1019678 X-archive-position: 2153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 861 Lines: 25 > > my JS20 blades hang on system reboot with current Linus tree. > I think it started after rc3. Maybe this line in dmesg gives a hint: > > tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 > Olaf, This error message means that the memory arbiter cannot be disabled for some reason. Looking at the code, tg3_abort_hw() will return -ENODEV and skip the 2 memset calls to zero out the hw_status and hw_stats memory. I don't believe skipping the memset calls can cause a hang. After tg3_abort_hw(), the chip should then be reset to a known state. The 5704S changes in 2.6.11-rc4 are mainly related to serdes link-up and tx signal. I don't see how those changes can cause a hang or the tg3_stop_block error. The stack trace did not show any tg3 function calls. Can you narrow it down further to a specific patch that is causing the problem? Michael From olh@suse.de Mon Feb 28 13:39:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 13:39:16 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SLdBJx020433 for ; Mon, 28 Feb 2005 13:39:11 -0800 Received: from hermes.suse.de (hermes-ext.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 5B92C1531628; Mon, 28 Feb 2005 22:39:05 +0100 (CET) Date: Mon, 28 Feb 2005 22:39:05 +0100 From: Olaf Hering To: Michael Chan Cc: netdev@oss.sgi.com Subject: Re: tg3 access hangs on system shutdown with 2.6.11-rc5, tg3_stop_block timed out Message-ID: <20050228213905.GA20109@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 496 Lines: 10 On Mon, Feb 28, Michael Chan wrote: > The 5704S changes in 2.6.11-rc4 are mainly related to serdes link-up and tx > signal. I don't see how those changes can cause a hang or the tg3_stop_block > error. The stack trace did not show any tg3 function calls. Can you narrow it > down further to a specific patch that is causing the problem? The blades are currently busy with other testing for the rest of the week. I ran 2.6.11-rc kernels since a while and it did not happen until very recently. From romieu@fr.zoreil.com Mon Feb 28 14:04:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 14:04:18 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SM47C2021979 for ; Mon, 28 Feb 2005 14:04:07 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j1SM3EfM011152; Mon, 28 Feb 2005 23:03:14 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j1SM32nc011151; Mon, 28 Feb 2005 23:03:02 +0100 Date: Mon, 28 Feb 2005 23:03:02 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2/2] r8169: RTL8169_registers clean-up Message-ID: <20050228220302.GC8186@electric-eye.fr.zoreil.com> References: <20050228190444.GA13415@us.ibm.com> <20050228195958.GB8186@electric-eye.fr.zoreil.com> <200502281507.37909.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502281507.37909.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2155 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: 1795 Lines: 49 Jon Mason : [...] > > 1 - It does not use bitwise shifts where possible (suggested by Jeff); > > I never heard from you that this was the way to go. I can do this, if you > still want this patch. This was not from me but from Jeff Garzik on 26/02/2005: - Message-ID: <4220B9C6.1010106@pobox.com> - Subject: [PATCH]: r8169: Expose hardware stats via ethtool Said mail contained "Cleanup patches accepted.", so I did not question the sanity of the patch. :o) [lack of consistency] > Not seeing where you are refering to, can you give me a line #? --- drivers/net/r8169.c 2005-02-27 11:45:27.000000000 -0600 +++ drivers/net/r8169.c.new 2005-02-27 11:44:44.000000000 -0600 @@ -186,91 +186,91 @@ static int rx_copybreak = 200; static int use_dac; enum RTL8169_registers { - MAC0 = 0, /* Ethernet hardware address. */ - MAR0 = 8, /* Multicast filter. */ + MAC0 = 0x00, /* Ethernet hardware address. */ + MAR0 = 0x08, /* Multicast filter. */ TxDescStartAddrLow = 0x20, TxDescStartAddrHigh = 0x24, TxHDescStartAddrLow = 0x28, TxHDescStartAddrHigh = 0x2c, [...] > > 3 - Please write a script to reduce the patch and prove that a typo does > > not hide somewhere (yep, I'm lazy). It would take too much testing > > to get a complete coverage. > > If you are that worried, it probably isn't worth it. Its just clean-up ;-) I just want a cleanup patch to be easy to review: either #1 simple rules allow to check it or #2 it can be proven that it is right. The r8169 driver already went through misc cleanups lately. We can surely spend some time hacking it again before it hurts the good taste (TM). Back to the update/merge/compile fest... -- Ueimor From AndyLiebman@aol.com Mon Feb 28 14:26:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 14:26:27 -0800 (PST) Received: from imo-m25.mx.aol.com (imo-m25.mx.aol.com [64.12.137.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SMQKRm022982 for ; Mon, 28 Feb 2005 14:26:20 -0800 Received: from AndyLiebman@aol.com by imo-m25.mx.aol.com (mail_out_v37_r3.8.) id m.147.4096aff0 (16633); Mon, 28 Feb 2005 17:25:18 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <147.4096aff0.2f54f44d@aol.com> Date: Mon, 28 Feb 2005 17:25:17 EST Subject: Re: Frequent Oops on Shutdown 2.6.10 To: yoshfuji@linux-ipv6.org CC: herbert@gondor.apana.org.au, terryg@axian.com, netdev@oss.sgi.com, davem@davemloft.net, akpm@osdl.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: netdev Content-Length: 1179 Lines: 36 In a message dated 2/23/2005 11:42:42 A.M. Eastern Standard Time, yoshfuji@linux-ipv6.org writes: In article (at Wed, 23 Feb 2005 09:51:44 EST), AndyLiebman@aol.com says: > Should I bother to apply this patch, or should I wait for you to make this > last change? What did you think about my comment that the Oops only occurred > when the Ethernet cable had been unplugged during operation? Well, not sure, but I think it is worth trying. Thanks. --yoshfuji Hi Yoshi, I just thought I would let you know that I applied the patch to the 2.6.10 kernel and recompiled. It seems to have made the Oops go away. At least, I can't make the Oops happen any more by unplugging the Ethernet cables during operation and then shutting down. I might add that when I tried to apply the patch with: patch --dry-run -p1 -d dir < patchfile I got all kinds of errors about this line or that line. I can't remember what they were. In the end, I VERY CAREFULLY cut and pasted your patch, and removed the lines the patch was supposed to remove. Did you attempt to apply the patch? Anyway, looks good. Regards, Andy Liebman From davem@davemloft.net Mon Feb 28 15:34:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 15:34:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SNYcqI027093 for ; Mon, 28 Feb 2005 15:34:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D5uNJ-0000f2-00; Mon, 28 Feb 2005 15:32:29 -0800 Date: Mon, 28 Feb 2005 15:32:28 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mostrows@speakeasy.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-Id: <20050228153228.0c5cb46d.davem@davemloft.net> In-Reply-To: <42235114.3070109@osdl.org> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050227202011.5ccefb22.davem@davemloft.net> <42235114.3070109@osdl.org> X-Mailer: Sylpheed version 1.0.1 (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-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 613 Lines: 17 On Mon, 28 Feb 2005 09:12:52 -0800 Stephen Hemminger wrote: > The original sk98lin attempted to receive hardware checksumming > but never actually turned it on. Because there is a bug in the chip wherein checksums can be miscalculated. I forget the details, but I do remember that you can't enable checksumming safely because of this. In drivers/net/sk98lin/skcsum.c it mentions this: * Note: * There is a bug in the GENESIS ASIC which may lead to wrong checksums. I know this comment is above the send checksum routine, but I am pretty sure the bug applies to both directions. From shemminger@osdl.org Mon Feb 28 16:01:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 16:02:02 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2101vth028330 for ; Mon, 28 Feb 2005 16:01:57 -0800 Received: from www.osdl.org (fire.osdl.org [65.172.181.4]) by smtp.osdl.org (8.12.8/8.12.8) with SMTP id j2101Xqh000783; Mon, 28 Feb 2005 16:01:33 -0800 Received: from 63.170.215.71 (SquirrelMail authenticated user shemminger) by www.osdl.org with HTTP; Mon, 28 Feb 2005 16:01:33 -0800 (PST) Message-ID: <61814.63.170.215.71.1109635293.squirrel@www.osdl.org> In-Reply-To: <20050228153228.0c5cb46d.davem@davemloft.net> References: <20050224155906.73890361@dxpl.pdx.osdl.net><20050227202011.5ccefb22.davem@davemloft.net><42235114.3070109@osdl.org> <20050228153228.0c5cb46d.davem@davemloft.net> Date: Mon, 28 Feb 2005 16:01:33 -0800 (PST) Subject: Re: pppoe and receive checksum offload From: shemminger@osdl.org To: "David S. Miller" Cc: "Stephen Hemminger" , mostrows@speakeasy.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com User-Agent: SquirrelMail/1.4.2-1_osdl_00 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.4 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2158 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: 921 Lines: 24 > On Mon, 28 Feb 2005 09:12:52 -0800 > Stephen Hemminger wrote: > >> The original sk98lin attempted to receive hardware checksumming >> but never actually turned it on. > > Because there is a bug in the chip wherein checksums can be > miscalculated. I forget the details, but I do remember that > you can't enable checksumming safely because of this. > > In drivers/net/sk98lin/skcsum.c it mentions this: > > * Note: > * There is a bug in the GENESIS ASIC which may lead to wrong > checksums. > > I know this comment is above the send checksum routine, but I > am pretty sure the bug applies to both directions. The driver covers two types of chips (Genesis and Yukon). The new driver only allows receive checksum on Yukon chipset. Almost all current hardware uses Yukon and it has been pretty well tested. The issues the sk98lin had were sloppy coding and handling of unsigned arithmetic. From dale@farnsworth.org Mon Feb 28 16:07:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 16:07:48 -0800 (PST) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2107h7o028946 for ; Mon, 28 Feb 2005 16:07:43 -0800 Received: (qmail 3975 invoked by uid 1000); 1 Mar 2005 00:07:42 -0000 From: "Dale Farnsworth" Date: Mon, 28 Feb 2005 17:07:42 -0700 To: netdev@oss.sgi.com, Jeff Garzik Cc: Ralf Baechle , Manish Lachwani , Brian Waite , "Steven J. Hill" , Benjamin Herrenschmidt , James Chapman Subject: [PATCH] mv643xx: permit VLAN tagged rx packets + minor cleanup Message-ID: <20050301000742.GA3163@xyzzy> References: <20050217224239.GA16609@xyzzy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050217224239.GA16609@xyzzy> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 11115 Lines: 295 I've added two changesets (1.2078 and 1.2079) to my mv643xx-enet tree. A combined diff for the two changesets is included at the end of this message. The other changesets below have already been pulled into netdev-2.6. Thanks, -Dale Please do a bk pull bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet This will update the following files: drivers/net/Kconfig | 5 drivers/net/mv643xx_eth.c | 2687 ++++++++++++++++++++++++++-------------------- drivers/net/mv643xx_eth.h | 641 ++++------ include/linux/mv643xx.h | 448 +++++-- 4 files changed, 2114 insertions(+), 1667 deletions(-) through these ChangeSets: (05/02/28 1.2079) mv643xx: remove superfluous function, mv643xx_set_ethtool_ops Signed-off-by: Dale Farnsworth (05/02/28 1.2078) mv643xx: raise size of receive skbs to allow for an optional VLAN tag VLAN tag needs an extra 4 bytes in receive skb Signed-off-by: Dale Farnsworth (05/02/22 1.2077) Remove call to msleep() while locks are held. We don't really need to wait for the link to come up. It was a workaround to avoid a transient error message, "Virtual device %s asks to queue packet!\n", in dev_queue_xmit() when called by ic_bootp_send_if(). This happens because right after opening the network device, there is a pending PHY status change interrupt causing the driver to call netif_stop_queue(). A half second later, the link comes up and all is well. We could have moved the call to msleep() to mv643xx_eth_open() to perpetuate the workaround, but I think it's best to remove it entirely. Signed-off-by: Dale Farnsworth (05/02/22 1.2076) Ensure that we only change the Port Serial Control Reg while the port is disabled. Signed-off-by: Dale Farnsworth (05/02/17 1.2075) Add ethtool support to the mv643xx ethernet driver. Initially, we add statistics and link status reporting. Signed-off-by: Dale Farnsworth (05/02/17 1.2074) Enable the mv643xx ethernet support on platforms using the MV64360 chip. Signed-off-by: Dale Farnsworth (05/02/17 1.2073) Disable tcp/udp checksum offload to hardware. It generally works, but the hardware appears to generate the wrong checksum if the hw checksum generation wasn't used in the previous packet sent. I'm increasingly confident this is a hardware error. We'll disable hw tcp/udp checksum generation until we have a fix or workaround. Signed-off-by: Dale Farnsworth (05/02/17 1.2072) We already set ETH_TX_ENABLE_INTERRUPT whenever we set ETH_TX_LAST_DESC. Signed-off-by: Dale Farnsworth (05/02/17 1.2071) Update tx_bytes statistic when using hw tcp/udp checksum generation. Signed-off-by: Dale Farnsworth (05/02/17 1.2070) Call netif_carrier_off when closing the driver. Signed-off-by: Dale Farnsworth (05/02/17 1.2069) Trivial. Remove repeated comment. Signed-off-by: Dale Farnsworth (05/02/17 1.2068) Clear transmit l4i_chk even when the hardware ignores it. Not absolutely necessary, but makes debugging easier. Signed-off-by: Dale Farnsworth (05/02/17 1.2067) Increment tx_ring_skbs before calling eth_port_send, since otherwise the irq handler may check and decrement it before we increment it. Signed-off-by: Dale Farnsworth (05/02/17 1.2066) Fix handling of unaligned tiny fragments not handled by hardware Check all fragments instead of just the last. Signed-off-by: Dale Farnsworth (05/02/17 1.2065) Fix a few places I missed in the previous rename patch. Rename: mv64x60 => mv643xx Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.17) Big rename. Change MV64340 => MV643XX and mv64340 => mv643xx Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.16) Rename MV_READ => mv_read and MV_WRITE => mv_write Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.15) Additional whitespace cleanups, mostly changing spaces to tabs in comments (05/01/27 1.1966.60.14) Run mv643xx_eth.[ch] through scripts/Lindent Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.13) Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.12) This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case (05/01/27 1.1966.60.11) Add support for PHYs/boards that don't support autonegotiation. Signed-off-by: Brian Waite Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.10) With this patch, the driver now calls netif_carrier_off/netif_carrier_on on a link down/up condition. Signed-off-by: Dale Farnsworth (05/01/27 1.1966.60.9) This patch cleans up the handling of receive skb sizing. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.8) This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.7) This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. Signed-off-by: Steven J. Hill Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.6) This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: size of RX and TX descriptor rings port_config value port_config_extend value port_sdma_config value port_serial_control value PHY address Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.5) This patch adds device driver model support to the mv643xx_eth driver. This is a change to the driver's programming interface. Platform code must now pass in the address of the MV643xx ethernet registers and IRQ. If firmware doesn't set the MAC address, platform code must also pass in the MAC address. Also, note that local MV_READ/MV_WRITE macros are used rather than using global macros. Keeping the macro names minimizes the patch size. The names will be changed to mv_read/mv_write in a later cosmetic cleanup patch. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.4) This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.3) This patch fixes the code that enables hardware checksum generation. The previous code has so many problems that it appears to never have worked 2.6. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.2) This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. It also adds a spinlock to protect access to the MV64340_ETH_SMI_REG, which is shared across ports. Signed-off-by: Dale Farnsworth (05/01/14 1.1966.60.1) This patch removes code that is redundant or useless. The biggest area is in pre-initializing the RX and TX descriptor rings, which only obfuscates the driver since the ring data is overwritten without being used. Signed-off-by: Dale Farnsworth Combined diff for changesets 1.2078 and 1.2079: diff -u b/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c --- b/drivers/net/mv643xx_eth.c 2005-02-28 16:12:26 -07:00 +++ b/drivers/net/mv643xx_eth.c 2005-02-28 16:50:38 -07:00 @@ -51,8 +51,11 @@ */ /* Constants */ -#define WRAP ETH_HLEN + 2 + 4 -#define RX_SKB_SIZE ((dev->mtu + WRAP + 7) & ~0x7) +#define VLAN_HLEN 4 +#define FCS_LEN 4 +#define WRAP NET_IP_ALIGN + ETH_HLEN + VLAN_HLEN + FCS_LEN +#define RX_SKB_SIZE ((dev->mtu + WRAP + 7) & ~0x7) + #define INT_CAUSE_UNMASK_ALL 0x0007ffff #define INT_CAUSE_UNMASK_ALL_EXT 0x0011ffff #ifdef MV643XX_RX_QUEUE_FILL_ON_TASK @@ -60,6 +63,7 @@ #define INT_CAUSE_CHECK_BITS INT_CAUSE_UNMASK_ALL #define INT_CAUSE_CHECK_BITS_EXT INT_CAUSE_UNMASK_ALL_EXT #endif + #ifdef MV643XX_CHECKSUM_OFFLOAD_TX #define MAX_DESCS_PER_SKB (MAX_SKB_FRAGS + 1) #else @@ -83,7 +87,7 @@ #endif static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); static int ethernet_phy_detect(unsigned int eth_port_num); -void mv643xx_set_ethtool_ops(struct net_device *netdev); +static struct ethtool_ops mv643xx_ethtool_ops; static char mv643xx_driver_name[] = "mv643xx_eth"; static char mv643xx_driver_version[] = "1.0"; @@ -1399,7 +1403,7 @@ dev->tx_queue_len = mp->tx_ring_size; dev->base_addr = 0; dev->change_mtu = mv643xx_eth_change_mtu; - mv643xx_set_ethtool_ops(dev); + SET_ETHTOOL_OPS(dev, &mv643xx_ethtool_ops); #ifdef MV643XX_CHECKSUM_OFFLOAD_TX #ifdef MAX_SKB_FRAGS @@ -3017,7 +3021,7 @@ } } -struct ethtool_ops mv643xx_ethtool_ops = { +static struct ethtool_ops mv643xx_ethtool_ops = { .get_settings = mv643xx_get_settings, .get_drvinfo = mv643xx_get_drvinfo, .get_link = ethtool_op_get_link, @@ -3030,7 +3034,2 @@ -void mv643xx_set_ethtool_ops(struct net_device *netdev) -{ - SET_ETHTOOL_OPS(netdev, &mv643xx_ethtool_ops); -} - /************* End ethtool support *************************/ From tgraf@suug.ch Mon Feb 28 16:26:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 16:26:13 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j210Q9r1000767 for ; Mon, 28 Feb 2005 16:26:09 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id D866B85; Tue, 1 Mar 2005 01:25:44 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id DFDE31C0EA; Tue, 1 Mar 2005 01:26:26 +0100 (CET) Date: Tue, 1 Mar 2005 01:26:26 +0100 From: Thomas Graf To: Weber Matthias Cc: bert hubert , netdev@oss.sgi.com Subject: Re: filtering packtes before OS takes care about them Message-ID: <20050301002626.GR31837@postel.suug.ch> References: <09766A6E64A068419B362367800D50C0B58A18@moritz.faps.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09766A6E64A068419B362367800D50C0B58A18@moritz.faps.uni-erlangen.de> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1162 Lines: 12 > I need to develop a special gateway. It shall map exernal ips to internal ports and external ports to internal ips (kind of NAT but connections have to be established from external to internal network and vice versa!), so the sender,receveiver addresses and ports have to be changed off each package received. Afterwards these packets shall be resent via one (out of more) interfaces. Therefore kernel's IP stuff disturbs me, but because i want to use TCP/IP at the gateway itself too (the computer runs applications using IP), i still need it. I won't comment on the way you are about to solve your problem even if I do think that it could be solved in a simpler way. In recent 2.6 kernels the earliest filtering possibility is via the ingress qdisc right after the skb has been received, see the ing_filter() call in netif_receive_skb(), given you enable tc actions. Earlier kernels or if tc actions is not enabled, the netfilter prerouting hook is used which gets invoked in the ip code after some very basic sanity checks. You can use the pedit action to modify the packet although the checksum correction action is still missing which might bother you. From pedro.fortuna@gmail.com Mon Feb 28 16:30:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 16:31:00 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j210Ureq001445 for ; Mon, 28 Feb 2005 16:30:54 -0800 Received: by rproxy.gmail.com with SMTP id a36so604444rnf for ; Mon, 28 Feb 2005 16:30:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=TuisdDOy/9YcyQPNhlXt+ZfJ9t/LULTk7wxYVXkB3+hVd5i5Su9KEliMoA3ouOYKL1OQn7C+xCAbWHgginx2g3afWkuGjQHOmA01GDibxTVmYSEWaPCKZIcXzKWBXZvRLPKYW65ZiNz7xhy1SoMY1UTEBxF5DLUJ/cZlVgQ/sEA= Received: by 10.11.118.73 with SMTP id q73mr212989cwc; Mon, 28 Feb 2005 16:30:51 -0800 (PST) Received: by 10.11.99.66 with HTTP; Mon, 28 Feb 2005 16:30:51 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 00:30:51 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: netdev@oss.sgi.com Subject: Re: filtering packtes before OS takes care about them In-Reply-To: <7bca1cb50502281209798e8a00@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev Content-Length: 1587 Lines: 38 Hello, I was searching for something like this also. In my case, I'll need to intercept all outgoing IP packets and change them (including L2 frame) before they are passed to the network interface driver. The changes are: -modify the ethertype number in the L2 frame (e.g. DIX frames) to a private not used one -complety modify the IP packet header and payload After this, the packets are sent on their way (passed to the network driver) The reverse operation is applied to incoming IP Packets in the destination host. I didnt investigate the packet_type example you provided but I hope I will be able to used for the purposes I explained. Best Regards, Pedro Fortuna On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar wrote: > > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and > > * to delete them from input buffer such that OS' netmodules can't receive them > > * to modify packet headers and move packets to interface related output buffers > > * to keep them in input buffers such that OS' netmodules can take care about them. > > You can process packets even before ip_rcv() gets them by registering > your own packet handler (struct packet_type) using dev_add_pack(). I > have a small sample at: > http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c > This may not be the cleanest way, but it isn't that dirty either. > > Also see: > http://www.phrack.org/show.php?p=55&a=12 > > -- Asim > > From storri@torri.org Mon Feb 28 16:51:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 16:51:29 -0800 (PST) Received: from europa.lunarpages.com (europa.lunarpages.com [64.235.234.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j210pPcM002445 for ; Mon, 28 Feb 2005 16:51:25 -0800 Received: from d233-64-63-249.clv.wideopenwest.com ([64.233.249.63] helo=base.torri.org) by europa.lunarpages.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1D5vbd-00018L-QF for netdev@oss.sgi.com; Mon, 28 Feb 2005 16:51:22 -0800 Subject: Understanding the reason for placing a tcp_sock on stack in tcp network functions From: Stephen Torri To: netdev Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ij0+5vErWNLcZQY+QzRI" Date: Mon, 28 Feb 2005 19:51:17 -0500 Message-Id: <1109638277.9693.15.camel@base.torri.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - europa.lunarpages.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - torri.org X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: storri@torri.org Precedence: bulk X-list: netdev Content-Length: 2790 Lines: 69 --=-ij0+5vErWNLcZQY+QzRI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I am trying to help out reducing the stack size of functions in the kernel. The function names and values below, with comments and questions, was obtained of the linux-2.6 kernel kept at bkbits.net when I did 'make checkstack'. I have one main question: must the variable 'sk' remained unchanged in all these functions? If so then copying the user_mss variable from that input struct 'sk' to the tcp_sock created on the stack is ok. Otherwise why do we not use the socket pointer 'sk'given as an argument via tcp_sk to cast the pointer type to a tcp_sock pointer? Stephen --- Notes --- # Status: Puts a tcp_sock on the stack each time the function # is executed. I don't know if the cost of a kmalloc # and free of a tcp_sock is more expensive in time # than creating a tcp_sock on the stack. The requirements # memory is most likely to the same for each (guess). 0xc025ac5c tcp_check_req: 1208 # Status: Same report as tcp_check_req. Only question I have is # the tcp_sock contained in the struct sock* pointer 'sk' # need to be unmodified in this call? The reason I ask # is that there is supposedly a struct sock* pointer sent # to this function is a tcp_sock pointer. Calling tcp_sk(sk) # will cast the tcp_sock pointer. If its not required to # maintain 'sk' unchanged through this function then we # can skip adding one to the stack for the sole purpose of # copying the use_mms to it. 0xc02573da tcp_v4_conn_request: 1192 # Status: Same report as tcp_check_req. Only comment here is that the # struct sk_buff contains a reference to the socket that it is owned # by. Again as with the comments with tcp_v4_conn_request, can we use # the socket 'sk' contained in the sk_buff with tcp_sk(sk) to get a # pointer to a tcp_sock? If we can then we are reusing a socket rather # than creating one on the stack. 0xc02599c3 tcp_timewait_state_process: 1176 0xc0259c9f tcp_timewait_state_process: 1176 # Status: As the comments say in tcp_ipv6.c, this function is # incredibly similar to the version in tcp_ipv4.c. Again why do have # to create a tcp_sock header on the stack. 0x0001c713 tcp_v6_conn_request: 1176 --=-ij0+5vErWNLcZQY+QzRI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCI7yFHN3s7YbuClYRAvN8AKCV7nX9zdrN7ij45+UOL27DaJ3u0gCgw4s4 HUuP7V90G7eG2KzyE1S3Llw= =x0yq -----END PGP SIGNATURE----- --=-ij0+5vErWNLcZQY+QzRI-- From herbert@gondor.apana.org.au Mon Feb 28 17:06:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 17:06:16 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21166Ot003860 for ; Mon, 28 Feb 2005 17:06:07 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1D5vos-0008MP-00; Tue, 01 Mar 2005 12:05:02 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D5voG-0003rr-00; Tue, 01 Mar 2005 12:04:24 +1100 Date: Tue, 1 Mar 2005 12:04:24 +1100 To: Alexey Kuznetsov Cc: Stephen Hemminger , "David S. Miller" , mostrows@speakeasy.net, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-ID: <20050301010424.GA14851@gondor.apana.org.au> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050228113106.GA3268@gondor.apana.org.au> <20050228113938.GA3393@gondor.apana.org.au> <20050228140401.GA27937@yakov.inr.ac.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <20050228140401.GA27937@yakov.inr.ac.ru> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2163 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5233 Lines: 165 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 28, 2005 at 05:04:01PM +0300, Alexey Kuznetsov wrote: > > ppp_input() could do the same thing. It does not, hence suggested patch > is corrrect minimal solution. Agreed. We should use Stephen's patch for 2.6.11. For 2.6.12, does this patch look sane? As usual, I'd love to get some better names for the new helper functions. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/pppoe.c 1.48 vs edited ===== --- 1.48/drivers/net/pppoe.c 2005-01-21 16:02:12 +11:00 +++ edited/drivers/net/pppoe.c 2005-03-01 11:20:44 +11:00 @@ -338,7 +338,9 @@ struct pppoe_hdr *ph = (struct pppoe_hdr *) skb->nh.raw; int len = ntohs(ph->length); skb_pull(skb, sizeof(struct pppoe_hdr)); - skb_trim(skb, len); + skb_postpull_rcsum(skb, ph, sizeof(*ph)); + if (pskb_trim_rcsum(skb, len)) + goto abort_kfree; ppp_input(&po->chan, skb); } else if (sk->sk_state & PPPOX_RELAY) { ===== include/linux/skbuff.h 1.60 vs edited ===== --- 1.60/include/linux/skbuff.h 2005-02-06 14:23:06 +11:00 +++ edited/include/linux/skbuff.h 2005-03-01 11:15:43 +11:00 @@ -1054,6 +1054,42 @@ return __skb_linearize(skb, gfp); } +/** + * skb_postpull_rcsum - update checksum for received skb after pull + * @skb: buffer to update + * @start: start of data before pull + * @len: length of data pulled + * + * After doing a pull on a received packet, you need to call this to + * update the CHECKSUM_HW checksum, or set ip_summed to CHECKSUM_NONE + * so that it can be recomputed from scratch. + */ + +static inline void skb_postpull_rcsum(struct sk_buff *skb, + const void *start, int len) +{ + if (skb->ip_summed == CHECKSUM_HW) + skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0)); +} + +/** + * pskb_trim_rcsum - trim received skb and update checksum + * @skb: buffer to trim + * @len: new length + * + * This is exactly the same as pskb_trim except that it ensures the + * checksum of received packets are still valid after the operation. + */ + +static inline int pskb_trim_rcsum(struct sk_buff *skb, unsigned int len) +{ + if (len >= skb->len) + return 0; + if (skb->ip_summed == CHECKSUM_HW) + skb->ip_summed = CHECKSUM_NONE; + return __pskb_trim(skb, len); +} + static inline void *kmap_skb_frag(const skb_frag_t *frag) { #ifdef CONFIG_HIGHMEM ===== net/ipv4/ip_gre.c 1.46 vs edited ===== --- 1.46/net/ipv4/ip_gre.c 2005-01-14 15:41:05 +11:00 +++ edited/net/ipv4/ip_gre.c 2005-03-01 11:17:35 +11:00 @@ -618,10 +618,8 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = __pskb_pull(skb, offset); + skb_postpull_rcsum(skb, skb->mac.raw, offset); memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - if (skb->ip_summed == CHECKSUM_HW) - skb->csum = csum_sub(skb->csum, - csum_partial(skb->mac.raw, skb->nh.raw-skb->mac.raw, 0)); skb->pkt_type = PACKET_HOST; #ifdef CONFIG_NET_IPGRE_BROADCAST if (MULTICAST(iph->daddr)) { ===== net/ipv4/ip_input.c 1.27 vs edited ===== --- 1.27/net/ipv4/ip_input.c 2005-01-27 17:03:17 +11:00 +++ edited/net/ipv4/ip_input.c 2005-03-01 11:21:19 +11:00 @@ -410,10 +410,9 @@ * is IP we can trim to the true length of the frame. * Note this now means skb->len holds ntohs(iph->tot_len). */ - if (skb->len > len) { - __pskb_trim(skb, len); - if (skb->ip_summed == CHECKSUM_HW) - skb->ip_summed = CHECKSUM_NONE; + if (pskb_trim_rcsum(skb, len)) { + IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS); + goto drop; } } ===== net/ipv6/ip6_input.c 1.22 vs edited ===== --- 1.22/net/ipv6/ip6_input.c 2004-08-23 18:15:14 +10:00 +++ edited/net/ipv6/ip6_input.c 2005-03-01 11:24:32 +11:00 @@ -95,15 +95,11 @@ if (pkt_len || hdr->nexthdr != NEXTHDR_HOP) { 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))){ - IP6_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS); - goto drop; - } - hdr = skb->nh.ipv6h; - if (skb->ip_summed == CHECKSUM_HW) - skb->ip_summed = CHECKSUM_NONE; + if (pskb_trim_rcsum(skb, pkt_len + sizeof(struct ipv6hdr))) { + IP6_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS); + goto drop; } + hdr = skb->nh.ipv6h; } if (hdr->nexthdr == NEXTHDR_HOP) { @@ -138,7 +134,6 @@ unsigned int nhoff; int nexthdr; u8 hash; - int cksum_sub = 0; skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); @@ -173,11 +168,8 @@ if (ipprot->flags & INET6_PROTO_FINAL) { struct ipv6hdr *hdr; - if (!cksum_sub && skb->ip_summed == CHECKSUM_HW) { - skb->csum = csum_sub(skb->csum, - csum_partial(skb->nh.raw, skb->h.raw-skb->nh.raw, 0)); - cksum_sub++; - } + skb_postpull_rcsum(skb, skb->nh.raw, + skb->h.raw - skb->nh.raw); hdr = skb->nh.ipv6h; if (ipv6_addr_is_multicast(&hdr->daddr) && !ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, --h31gzZEtNLTqOjlF-- From khc@pm.waw.pl Mon Feb 28 17:56:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 17:56:22 -0800 (PST) Received: from khc.piap.pl (khc.piap.pl [195.187.100.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j211uEBE006127 for ; Mon, 28 Feb 2005 17:56:15 -0800 Received: by khc.piap.pl (Postfix, from userid 500) id AC819107C9; Tue, 1 Mar 2005 02:54:25 +0100 (CET) To: Cc: Jeff Garzik Subject: [PATCH] WAN drivers fix: N2, C101, PCI200SYN - quite fatal From: Krzysztof Halasa Date: Tue, 01 Mar 2005 02:54:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 2952 Lines: 98 --=-=-= Hi, The last change to drivers/wan/hd6457x.c was a bit fatal to drivers using it - the attached patch fixes NULL pointer dereference on RX. I've updated URLs in MAINTAINERS and wan/Kconfig as well. Please apply to 2.6. It would be nice if it's included in 2.6.11. Thanks. Signed-off-by: Krzysztof Halasa -- Krzysztof Halasa --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hdlc-skb-dev.patch --- linux/drivers/net/wan/hd6457x.c 28 Oct 2004 06:16:08 -0000 1.15 +++ linux/drivers/net/wan/hd6457x.c 1 Mar 2005 00:58:08 -0000 @@ -315,7 +315,7 @@ #endif stats->rx_packets++; stats->rx_bytes += skb->len; - skb->dev->last_rx = jiffies; + dev->last_rx = jiffies; skb->protocol = hdlc_type_trans(skb, dev); netif_rx(skb); } --- linux/drivers/net/wan/Kconfig 15 Jan 2005 23:46:55 -0000 1.25 +++ linux/drivers/net/wan/Kconfig 1 Mar 2005 00:58:08 -0000 @@ -155,7 +155,8 @@ Network) card supported by this driver and you are planning to connect the box to a WAN. - You will need supporting software from . + You will need supporting software from + . Generic HDLC driver currently supports raw HDLC, Cisco HDLC, Frame Relay, synchronous Point-to-Point Protocol (PPP) and X.25. @@ -225,7 +226,7 @@ Driver for PCI200SYN cards by Goramo sp. j. If you have such a card, say Y here and see - . + . To compile this as a module, choose M here: the module will be called pci200syn. @@ -239,7 +240,7 @@ Driver for wanXL PCI cards by SBE Inc. If you have such a card, say Y here and see - . + . To compile this as a module, choose M here: the module will be called wanxl. @@ -292,7 +293,7 @@ SDL Communications Inc. If you have such a card, say Y here and see - . + . Note that N2csu and N2dds cards are not supported by this driver. @@ -308,7 +309,7 @@ Driver for C101 SuperSync ISA cards by Moxa Technologies Co., Ltd. If you have such a card, say Y here and see - + . To compile this driver as a module, choose M here: the module will be called c101. --- linux/MAINTAINERS 26 Jan 2005 16:47:14 -0000 1.332 +++ linux/MAINTAINERS 1 Mar 2005 00:58:08 -0000 @@ -910,10 +910,10 @@ W: http://www.icp-vortex.com/ S: Supported -GENERIC HDLC DRIVER, N2 AND C101 DRIVERS +GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS P: Krzysztof Halasa M: khc@pm.waw.pl -W: http://hq.pm.waw.pl/hdlc/ +W: http://www.kernel.org/pub/linux/utils/net/hdlc/ S: Maintained HAYES ESP SERIAL DRIVER --=-=-=-- From jgarzik@pobox.com Mon Feb 28 18:30:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 18:31:00 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j212UtAI008144 for ; Mon, 28 Feb 2005 18:30:55 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D5x9v-0008QX-1p; Tue, 01 Mar 2005 02:30:51 +0000 Message-ID: <4223D3B9.8010604@pobox.com> Date: Mon, 28 Feb 2005 21:30:17 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Jon Mason , netdev@oss.sgi.com Subject: Re: [PATCH 2/2] r8169: RTL8169_registers clean-up References: <20050228190444.GA13415@us.ibm.com> <20050228195958.GB8186@electric-eye.fr.zoreil.com> In-Reply-To: <20050228195958.GB8186@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2167 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: 827 Lines: 27 Francois Romieu wrote: > Jon Mason : > >>An attempt to clean-up RTL8169_registers and RTL8169_register_content. >>Adjusted tab alignment and converted decimal values to hex. >> >>Applies cleanly to linux-2.6.11-rc4-mm1 and tested on amd64 > > > 1 - It does not use bitwise shifts where possible (suggested by Jeff); > 2 - It is not consistent (see TxDesc...); > 3 - Please write a script to reduce the patch and prove that a typo does > not hide somewhere (yep, I'm lazy). It would take too much testing > to get a complete coverage. You can do a "diff -b" (ignore whitespaces changes) to check this sort of stuff. > Jeff, how am I supposed to handle cleanups now ? Just say no ? :o) Ideally keep a stack of patches such that, the fixes can be applied underneath the cleanups... Jeff From asimshankar@gmail.com Mon Feb 28 19:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 19:35:18 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j213ZE7d010098 for ; Mon, 28 Feb 2005 19:35:15 -0800 Received: by wproxy.gmail.com with SMTP id 68so1089338wri for ; Mon, 28 Feb 2005 19:35:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hbdK8xUSw5LGtosZzJrGX9c0kU8R0zqzSoC8/CeMuGcc0gdwWssAyiV91xw/jJWtFb0FwlWKBkLUw+WCcS3DqIegDR8qmXRuibGXF8LLM/LSmTDFrcAUNdLOC2W2bAiqS9GCKFeOrHbpxrhOEFF98TRCZVzMUp0edvZCUceet5s= Received: by 10.54.50.14 with SMTP id x14mr56878wrx; Mon, 28 Feb 2005 19:35:09 -0800 (PST) Received: by 10.54.24.42 with HTTP; Mon, 28 Feb 2005 19:35:09 -0800 (PST) Message-ID: <7bca1cb50502281935557b45cc@mail.gmail.com> Date: Mon, 28 Feb 2005 21:35:09 -0600 From: Asim Shankar Reply-To: Asim Shankar To: Pedro Fortuna Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 1065 Lines: 25 > In my case, I'll need to intercept all outgoing IP packets and change > them (including L2 frame) before they are passed to the network > interface driver. > The reverse operation is applied to incoming IP Packets in the destination host. > I didnt investigate the packet_type example you provided but I hope I > will be able to used for the purposes I explained. If the type field of the struct packet_type you register == htons(ETH_P_ALL), then your packet handling function will be added to the head of the ptype_all list. As a result, it will see all incoming and outgoing packets - incoming will be delivered to your function from netif_receive_skb() before the IP/other packet handlers get to see it and outgoing packets will be delivered from dev_queue_xmit() (which calls dev_queue_xmit_nit()) just before the packet is queued for sending by the NIC. This may work for you. I'm assuming all outgoing packets go through dev_queue_xmit(), though that may not always be the case (someone more knowledgeable would have to explain this). Regards, -- Asim From hadi@cyberus.ca Mon Feb 28 20:58:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Feb 2005 20:58:40 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j214wYfa016409 for ; Mon, 28 Feb 2005 20:58:35 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D5wZW-0001yu-A3 for netdev@oss.sgi.com; Mon, 28 Feb 2005 20:53:14 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D5wZU-0006e4-UN; Mon, 28 Feb 2005 20:53:13 -0500 Subject: Re: filtering packtes before OS takes care about them From: jamal Reply-To: hadi@cyberus.ca To: Pedro Fortuna Cc: netdev@oss.sgi.com In-Reply-To: References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109641987.1090.12.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Feb 2005 20:53:08 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2169 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: 1926 Lines: 51 As Thomas was mentioning in other email; write an action to do this. Attach on ingress qdisc filter/classifier like u32 to map the DIX and then tell it to pass the packets to the action. cheers, jamal On Mon, 2005-02-28 at 19:30, Pedro Fortuna wrote: > Hello, > I was searching for something like this also. > In my case, I'll need to intercept all outgoing IP packets and change > them (including L2 frame) before they are passed to the network > interface driver. > The changes are: > -modify the ethertype number in the L2 frame (e.g. DIX frames) to a > private not used one > -complety modify the IP packet header and payload > After this, the packets are sent on their way (passed to the network driver) > > The reverse operation is applied to incoming IP Packets in the destination host. > > I didnt investigate the packet_type example you provided but I hope I > will be able to used for the purposes I explained. > > Best Regards, > Pedro Fortuna > > > On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar wrote: > > > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and > > > * to delete them from input buffer such that OS' netmodules can't receive them > > > * to modify packet headers and move packets to interface related output buffers > > > * to keep them in input buffers such that OS' netmodules can take care about them. > > > > You can process packets even before ip_rcv() gets them by registering > > your own packet handler (struct packet_type) using dev_add_pack(). I > > have a small sample at: > > http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c > > This may not be the cleanest way, but it isn't that dirty either. > > > > Also see: > > http://www.phrack.org/show.php?p=55&a=12 > > > > -- Asim > > > > > >