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_UPDAT