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) wit